From xuyixian@huawei.com Tue Jul 5 23:59:13 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134D221F86A3 for ; Tue, 5 Jul 2011 23:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.025 X-Spam-Level: ** X-Spam-Status: No, score=2.025 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD4xOtmo0SXY for ; Tue, 5 Jul 2011 23:59:12 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD5421F86A0 for ; Tue, 5 Jul 2011 23:59:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNW004BAGMTDR@szxga03-in.huawei.com> for ipsec@ietf.org; Wed, 06 Jul 2011 14:56:53 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNW00GJXGIPPL@szxga03-in.huawei.com> for ipsec@ietf.org; Wed, 06 Jul 2011 14:56:53 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACH50552; Wed, 06 Jul 2011 14:56:52 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 06 Jul 2011 14:56:49 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.31]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Wed, 06 Jul 2011 14:56:52 +0800 Date: Wed, 06 Jul 2011 06:56:51 +0000 From: "Lydia Xu(yixian)" X-Originating-IP: [10.112.36.134] To: "ipsec@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/related; boundary="Boundary_(ID_C3YwAAM0dnPTTg2sqlWueg)"; type="multipart/alternative" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: A new draft submittted-draft-xu-tictoc-ipsec-security-for-synchronization-01 Thread-index: Acw7qVA5jRSlopgwSYC6y8NGveAAlAAAIAWg X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 06 Jul 2011 09:15:41 -0700 Subject: [IPsec] A new draft submittted-draft-xu-tictoc-ipsec-security-for-synchronization-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 07:00:57 -0000 --Boundary_(ID_C3YwAAM0dnPTTg2sqlWueg) Content-type: multipart/alternative; boundary="Boundary_(ID_f86DNO29hOQDazf/nRughQ)" --Boundary_(ID_f86DNO29hOQDazf/nRughQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 DQpIaSBhbGwsDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgRHJhZnQgaW4gVElDVE9DLiBUaGlz IGRvY3VtZW50IGlzIGEgV0VTUCBleHRlbnNpb24uIEFuZCB0aGlzIG1lY2hhbmlzbSBjYW5iZSB1 c2VkIHRvIHJlc292ZSB0aGUgdGltZSBzeW5jaHJvbml6YXRpb24gd2l0aCBJUHNlYyBlbmNyeXB0 aW9uLg0KDQpUaGlzIGRvY3VtZW50IGlzIGF2YWlsYWJsZSBhdCB0aGUgZm9sbG93aW5nIFVSTDoN Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC14dS10aWN0b2MtaXBzZWMtc2VjdXJpdHkt Zm9yLXN5bmNocm9uaXphdGlvbi0wMS50eHQNCg0KVGhlIGRvY3VtZW50IGlzIHN0aWxsIHVuZGVy Z29pbmcgcmV2aXNpb24sIGFueSBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KQmVzdCBSZWdhcmRz DQoNCiAgICAgICAgICAgICAgICAgICAgWW91cnMgc2luY2VyZWx5LA0KICAgICAgICAgICAgICAg ICAgICBMeWRpYSBYdSjQ7eL55rUpDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpIVUFXRUkgVEVDSE5PTE9HSUVTIENPLixMVEQuIFtodWF3ZWlfbG9nb10NCg0KDQpBZGRyZXNz OiBIdWF3ZWkgQnVpbGRpbmcNCkJlaWppbmcgMTAwMDg1LCBQLlIuQ2hpbmENClRlbDogKzg2IDEw IDgyODM2MzAwDQpGYXg6ICs4NiAxMCA4MjgzNjkyMA0KTW9iaWxlOiArODYgMTM0MjYyMTkzMTcN CkUtbWFpbDogeHV5aXhpYW5AaHVhd2VpLmNvbTxtYWlsdG86eHV5aXhpYW5AaHVhd2VpLmNvbT4N Cnd3dy5odWF3ZWkuY29tPGh0dHA6Ly93d3cuaHVhd2VpLmNvbT4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwg aW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUg cGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBv ZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5n LCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRl bmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1t YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkNCnBob25lIG9yIGVtYWls IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQuDQoNCg0K --Boundary_(ID_f86DNO29hOQDazf/nRughQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi all,

 

I have submitted a new Draft in TICT= OC. This document is a WESP extension. And this mechanism canbe used to resove the time synchronization with IPsec encryption.<= /span>

 

This document is available at the fo= llowing URL:

http://tools.ietf.org/id/draft-xu-ti= ctoc-ipsec-security-for-synchronization-01.txt

 

The document i= s still undergoing revision, any comments are welcome. = ;

 

Best Regards

 &n= bsp;            = ;    

 &n= bsp;            = ;      Yours sincerely,

 &n= bsp;            = ;      Lydia Xu= (=D0=ED=E2=F9=E6=B5)


HUAWEI TECHNOLOGIES CO.,LTD. 3D"huawei_logo"

 

 

Address: Huawei Building
Beijing 100085, P.R.China
Tel: +86 10 82836300
Fax: +86 10 82836920
Mobile: +86 13426219317
E-mail: xuyixian@huawei.com
www.huawei.com
---------------------------------------------------------------------------= ----------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWE= I, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it.

 

 

--Boundary_(ID_f86DNO29hOQDazf/nRughQ)-- --Boundary_(ID_C3YwAAM0dnPTTg2sqlWueg) Content-id: Content-type: image/gif; name=image001.gif Content-transfer-encoding: base64 Content-disposition: inline; filename=image001.gif; size=5665; creation-date="Wed, 06 Jul 2011 06:56:51 GMT"; modification-date="Wed, 06 Jul 2011 06:56:51 GMT" Content-description: image001.gif R0lGODlh/wNdAPf/AP///4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v 7/f3987GxtbOzt7W1r21ta2lpbWtrca9vZyUlKWcnMa9td7WztbOxr21rc7Gvefezt7Wxt7Wve/v 5/f37///987OxtbWzt7e1ufn3r29ta2tpbW1rcbGvZSUjJyclKWlnIyMhN7ezufn1u/v3tbWxr29 rcbGtc7OvbW1pf//562tnPf33qWllO/v1t7exufnztbWvc7Otb29pcbGrf//3vf31u/vzufnxt7e vdbWtc7Orf//1u/vxufnvff/zvf/1u/3zufvxt7nvff/3u/31ufvztbevc7WtcbOrd7nxr3Gpff/ 5+/33ufv1tbexs7WvcbOtbW9pa21nO//zt7vvdbntd7nzr3Gre//1uf3ztbnvd7vxufv3sbOvaWt nPf/79bezs7WxrW9ra21pe//3uf31s7evcbWtd7vztbnxr3Ord7n1r3Gtef33sbWvd7v1s7extbn zr3OtbXGrefv5+/378bOxs7Wztbe1t7n3rW9taWtpa21rb3GvYyUjJSclJylnISMhM7ezsbWxrXG tb3OvcbOzq21tZScnMbGzq2lrcDAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAJoALAAAAAD/A10A QAj/AGmYMUND4BcgVuxc2cMwkJk9NFAgQFCghQ0fT6BQUYMFS5cub94kIEASwYIGmlKqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKVUowzp44cWhgRaGoxQABYAMI 6NEDCZQoUWCs4cKjTBc4IBe5oNGlRxm4f+rAgRNpBpxDChY4eDC1sOHDiBMrXsy4sePHkCNLnky5 MlA5KGhARKGCBgEBYr1EwVKlx48jU7z48NLFRxcsM/T4wFIGBgy/Nmb8gFGmDAkXAw4oQGm5uPHj yJMrX868ufPn0KPbHGgGjBw5i1Sk2H5ATxnTXqr8/wBZhocWPTO8eJnh9sePHh/hrN/b5UsCBIOl 69/Pv7///wAGKOCAAgbwQgCY7FEDG/IF0kcNM9jWQxUiLLhCCSSQsAJooAUQACQE6AEDFx/N0IV7 cCSQAAP5EejiizDGKOOMNNZo42Qx+OADDjx44AEMJpjAAAMw6HECCV/UEMYNYIBhxhVmCAFRIioo UgABGKigggEUuFDAlwYskkAhCUTAAAkLEHbjmmy26eabcMYpZ2VTOEHFFDwUceIRpVUBRRV1ePFH aV3M8EUcTtbwBSM1oOAoCgeg8IUQVwiR5ENm1KCgAg+oOeenoIYq6qikllqjiD3wBoNdM7AxA3sx xP9QYkh7laAAko5qWsMKbKywhyAoMIICAV8NQNIBCAw3WKemNuvss9BGK+20RcH2BRWj+TVDHyEV kkIOZnzhhbgM9WpGIo8yMmVWKiRCwCVgJsuAp9TWa++9+OarL5twwIAFWVV0UQcbLuzgQg5MslFC CSbEICIMJXhhw2444DDHEE44MQUVHPtwh3d6rKGHCQ0Qt+/JKKes8sosJ1aAlSkkUogJM5BAQxhx uEBsIwas4N6/VJTRURVOSEEFGlPcAcgfMOAByBtdlAGIW288fYiQiNDb8tZcd+311y0TkAICAJgQ RpJJ1lBDhnr8UIIBBHg1QAF74GFEFUVA0UUVVeD/UaghZBYwwOAEfFkCHCWUAXVIJWgN9uOQRy75 5DYKYoYdA+Ux0B5CeGHHVXFomYgLixzASJB2lcFFRz/4JUEij8hhRm4wFDqDCS1SrvvuvPfue3NV gVGQlma40KEAA0x4xA91qJEGFGf9O4Wsb/haA1w9eARXJCG9lWEhCiBgrAEJnOT47+inr/767O8k Rw4uPJKCClelQGwLH6m3txFWeEEFD1ywjV9i4C+AvccvcIGDJBjxCAM04Hzti6AEJ0hB9mVKCANh AxCS8AWGfMEG3+kCHjxSBSqQpVAksAFcbMAF77AmVR+BQUhIcB8HVPCGOMyhDsHGIQscAF4pMAAC /xhhKCDIEAby8QsCUsCCFrDAESwYXCPAQkUBEGAFNHuDbeBQCAsIBoI7DKMYx0hGOXXkCdgCGhX4 9hG+1S5IXajUF7IwEAyaISsoWAENhAAEzqnNUSswX6cckLsyGvKQiExkgMRDhSIUwQh1mQEexgOf LnxgBn+Awx9YUwJDfMEOXxjIFfpghzyAUlFf2OShQreI+c0vEchKVgMKqcha2vKWuGRMXbLHt4Dp pmY2YEQFqOgIF7SBSQLZw0MiwoYvCAIrcWjUHlQApgMk4AS0zKU2t8nNbirFD1zAwxv00AUghWQF o5PDDaxghS984Qqh3EMiSGC6A1hCiGdaAQr2EP++Axjgn8gaDrO8SdCCGvSgNfGSAdgwzpqxYQAu kIMNCACcFHwhkl74gQ8C9gMcnEEKU9jCHbBABzrcgQ5U8IFGylCHGcwzTQiNqUxnys0CbMcAKagA ChBXAkWogAN5hMMbhNYRKnjkB2UoIRpGAwWP0KYOAesCa0zEBUBMrXvgmxdNt8rVrt6QBnQUSJSS 1K9LKeghjtJOAeCABY00FT548MEM3kACYxHAml/0ql73ytcICsKdX2gmG9QT2A4yBAU1SMQeUJCI FUCgBFPwwQ+40ANazcBWBnBBChiBoVkOtK+gDa1owSYIOuaBBpZTZiLk8IgWtIAAHhJLARLgIx3/ VKEMGPFBql4FhxTMJRAqRGBIJIGIB4JxtMhNrnJNJbys0CAIBYkDCtrQAg8J4BFA4NN7mNARI/SA DlzgwhuE6q0atC6jvNWWfAzBXgjcBwEMeOBy50vf+rYpK2YIQlb2ayCw2IAMfAtPFZZQBSz4gA49 8AIB9VADMwjKL1Z9QwtrI9XwAdSaCVBAfLNp3w57+MP6cYELblCQKX3mBQIwQhT49gMrPGEGNlij D47Qg9hwAbcU/kgI1WMDwuUVxEAOspClQxA5KCIFbXDUy7bDHthITDx22cIUZEgCOACCsv+qwqtM VCiQsGEiHB6ymMdM5sdY6p0D0QoNtEQDt1RB/z1DM7BRocCGH0gMPlgABBu6AIUY3AFqQv0yfo5b 5kIb+tBLIbEZgLCCGgAhXIP9AhxExBqPRA2Jb5jBBlYglgOUkwtCvQMcTACxINmghoRGtKpXzWqd WJciyHuEChjBCInZYM8nklgKSYACDoXF1wNQgYmqpsW90PAkrU62spdNEwxcaQEmOEABMnGAcb3z CmmY2cJKsAckywFRYBAEB+LQSmIZ60skKYABbKAHPZBgBvKyIbPnTe9WP6GEVOgCFXRTmjLEykha nIEQxJoFStVAMwdQwSL++QMbQAQMN0AWhhWgAEwkwBAa/my9N85xIWtECUNoAhurcAeOfSR7vf95 VSECC4S0EaQqujIDEoAghIIPfLEokG/Hd85zIHvkTj6wjaU/kOAZJBgOfikB0+BAgj6YwQpmsNyu 9oCACdSgD55zp68YIt3FMkLDs+y52McuWo1y4Q5luINU1VM1cgo1EnAJyWXlw5AVrIARvMJ7HRvM WIXj9J/qPoA1A2Ncshv+8DP9s9TKwKcud+EPIXGLekhQCEaMqRIkUIAh2KApNjDk8wpaLCwDfxJ5 I/70qI8pwOCTnkjOwBCUWAELGjGAFqRAeJr6vCCSyRAaJCkOES/clwIa5tQb//i2xAJc8KCHqs3n VSmQnR0896Cz3tFRCEhEArJSAzwe4ALCF2L/xpFP/vLbUnUnF1EJFpCAR+wgB3IQ3uxMAO2FIf2S PcgYxpxAhClsrDwt9AbsF2/mV4AGGEYDYAA/4AclADElUAiP4AJhYAYKE15Cs0ZaxhpSZSdPMAUd 2IEbgwYlhwVosAIGUADmc4AquIIS9CWLsAIkkGlM1wIjpjMCcCAFwBtRo1sbVQVS8AQdKIJeQIL/ Qhsg8RHjVAKH4Fks2IROuDteogg4lQIoYAgLwFgpkB0qgAAMo29thQXvwRocgwVjGBISlj35g4Th 1W4mABgs8oRwGIdc8yWZsAIgsBpIYAOaYnclEAE+4F1ogAQ1RhpHwCcm5zfjZWwL4xchAQNL/9MH egEIIGEI2JRqcniJmNgsVmADV6ApdWQFlZIFJAADOLclKVAAj1AANeADbjEHWJAGXcAGmwQX3mJX BWAJE7EA8fUAItCLg5SJwBiM0bIH1edO0+cFfeBObKAZXCd6CZAIXrAFFzgbvIUhJ2gAKLBhliiM 3NiNoeJ7fRAIg/UgeaAeTsd1WKECB5csvSE0d3AHeIBAJkACp/iC41UCs2R63riP/AgqvvcFDmFH HUQl2bEIcfMZtncCJ6ADWOBdZ8AF+RYShpBZ0WQHJWIiSjgI+tiPHNmRNTIQcWAGWQBNBOECjkAA jjAAYhEAB/ADVXBv+cYD/pdvhaIHqwUG4v+iZXBQB5u0HoZgA0NiMh45lEQZIDQABnEgCBAROhmA AinQAh3iISpwBCtmBIXoB2UAXgTEGm8QBzmwB3BRO2mAdLXjFyRQAhBQCbqoc0XZlm7pHOkYXdGl Ap+xknvDN1bQVGPQVFTABVsgXkiEAnGQG5bGF+P1B2+hSYWwmAnwTxpWfG8ZmZLZGGqGlFlwAyoQ B8ejCFbQS0eQBkRwBG1FBTDgBWsAJIwCIW8BCH7QfLUBAy1FeSNROP8kL4U3mbiZm4vRGQeHR3Fg AB2SAj2wYkhQBUBgBKShb1NQY28QJFVgA+rhBXUAEjPgA33pPTglHLoYX561jbr5neBpFKT/YxVa gRWwBRZVQGMuOYRU4AVl4AUAgwUmsAZBwxu9oWPxYQMHYEUr4p3h+Z8AWhSK0AaalQiJUBDAiTxY sGLrUWDPyTEpVQav8prZkx4mgkA2sAIHQAAO5J8B+qEgyhPWkQME4FPZpwiPQBIf8RF2hgUZ5QM8 4BqHA0Kz0QWAMCGF8gNwUQIzwAgFcABsGaJCOqRAASVemQNtEAcHcIpaMlelmVExVB5bEBIM8gau gaN+wRqZFGgJcAAbSaRgGqY2oR4HB5KCGTpxsCoJZgOrR4ZBYwNdAJ0BQxZwITRl8AcwJpv4IaZ8 2qcyIRBCwE4NRhARQQM2QGo/QxZYoAZU/3BJ5pVCrVEb+qM4taEHh0BDe+qnmrqpmnBmD1ED8GQH irIHo+hmM1YFRiChh8MgkcIG7Rgh9qmEh7AAGpIAX8qpuCqkA3BkGmJeNjApA1FZSSU0KyAxhrAX hZAIKskhB0ACXMAHMaAbLFoFKYIAYZer2CqkHUIRikADDBIIimIDJfAGWAAEbsBjulYAK8khYsEG JFAGa4RUWCCAG1A+QZqt+AqeK4kAmWBF6pYAdmcFQAA1t5FENLQIVYRiVSQWKsAgXDCuSJehlaBV +Vqxukk4GlAClvAlKnBrBwEEl6UHx1ozBNoG8YcdcpACVvIIg2NXhYMChZA4GFIIJgGZFv97s/0Y S/SXeYWwAoYiBIFqBaNGV4wAf0sSkgMnmAv3FbR5JSRBAAhQCM1pCCRgEkKJs1jbkUtgBEYQo2X5 BogQKwrZADPwcGAQBFlAA5UiEGu2JQXgAiqAAhkABr71TwaALAlgAV9nAlZ4q1n7t8I4nBmRPSnl ogHzLz3gMOjxA1dQKQwRJXiEAhxwAO1UppkBKSuSjyVTMh4KuJ6rgnsJhFHAJ1HAAyR0oVpUAmvA ozVgB0IAXVFCEIsFEZ+qKNLkKBSrCZ37ubxbgGrwBBnzBKTRS3hgVL1UYJeFJFcArgvyR4+yT51j KZmSZo2yAlfbu9grhzfWSGMIG5U0V+3/cVlewKPc5itfIFY4NwH71E6GZVgRARGBxITZO79N+B1l MAXfMa+Ztirp8QaQ9wc6+gYL8wZeUI4PsQcdZHeMYAGB0kziiFpnylgSUQiCRL8WXIAm0jH7ViJw waJS1S+F8ge24gULwgZ5xAZ6CEqBkAcfixWLcAPboQiKgC4TkXnye8E4nHowQEA7rCpJVE5loAd7 ATUfUQjHagihtwe0tja0hgKeFwctSzg/miwnkY8al8NYbHj5pqgrKlUwZlS9gUSJuRfHSgKToMR7 UAhs4HmgByk6c24ZxiK7m8V0zGymUYQlkqMTMx6LgiwroMbvZgg1EwjlYgaZIV0FkUfS/6Zu8HWv dfzIZHci32siXiBUXmB3XyEALBBRWKFYg8qMDAEsJaYCKRovmGCzkJzK9VYGeMAaMICneFrJXQBL tRdRz0QDffCrDJF7+6QriXADMDw3w1c+fqvKxlxvT2oXfvAWeHoiJKBO7zQufaBMipKUNIAAKGAB NHBwmaECBzAAF/AlFCAvc3zM5kxmWnSfUdN8bwA4BwMGntNyVyCqBEEljJAIFYCLJhAHjJCZFKFu tUnM5XzOBA1kPIAeb5CxJiDAlGdMwMxOQFAp4NorClAIEsyFDRACbSgkJmArCBBLmTvQBT3S9aVv 7xkwW/SUIqZOA3E7J5BFJVBj7zEEOP+QMWIgBmhkVHggNXrwNLYSXyQd1KrmAgwiiT69AjSYAlnB bjJwY6vDouPxA2iUMVTNf0eDBnSgEUFDArso1F5daIVTCOiBRDMYUV8AAzLAilhAYzNQB3YmHl4w BGhwBnfwBGhw12iwEVAwQncwLATQn18d2GKmbiqgAA0YMWxAgzcgB58BFgZwQj9QhHa2f3QwBVzw B/CKY1jgN1MDErZSzIId2soFJgZgAUJFedF3A8TCAqCBAnszIVSgYnwCvEiTNG4hNH3Tjj7dnPQH 1KL92/PlJTe1AoeAIQShCPFDABTAWYWCqlAASeLhBGj0BO94F4DgiP6rY+oMAycwq4T+BNzgPVpf sh0quwKGTY8GkJlx8G61MRsmpF0vaVSLqgYjpDgyxMGYTQdl4AeA0IZWeL3hHeBbZVPeDCEXqiGe pzA9UAQdAQV/SBqVxDF4MOGFcmsfDBJ/IImJOANPEwllYIVXLOAijlCFY1H/Mim70igokEImFAVI MAOOsAJH4AUjVEJrrWVlAHdsgHELsAIqwi0fTB+pAgOHANojfuTb5ChxQAhmsAgDYbukinSQcoIp Wjg1cJdo0BHhMYtcZAAtW+LkExgOsAaHEBKIgORoflBPMnCUsmju5AWGgAID90eM4E9v2wFadAer 0xHx0QWFADeFgywbNgJpXugzFRAAOw== --Boundary_(ID_C3YwAAM0dnPTTg2sqlWueg) Content-id: Content-type: image/jpeg; name=image003.jpg Content-transfer-encoding: base64 Content-disposition: inline; filename=image003.jpg; size=6737; creation-date="Wed, 06 Jul 2011 06:56:51 GMT"; modification-date="Wed, 06 Jul 2011 06:56:51 GMT" Content-description: image003.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_C3YwAAM0dnPTTg2sqlWueg)-- From ietf-ipr@ietf.org Tue Jul 12 11:49:15 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C4921F8EA1; Tue, 12 Jul 2011 11:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka+2f+l+Wzk8; Tue, 12 Jul 2011 11:49:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6EE21F8D34; Tue, 12 Jul 2011 11:49:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: rsj@cisco.com, kagarigi@cisco.com, ynir@checkpoint.com, yaronf.ietf@gmail.com, zhangdacheng@huawei.com, X-Test-IDTracker: no Message-ID: <20110712184914.6071.94029.idtracker@ietfa.amsl.com> Date: Tue, 12 Jul 2011 11:49:14 -0700 X-Mailman-Approved-At: Wed, 13 Jul 2011 08:23:10 -0700 Cc: paul.hoffman@vpnc.org, ipsec@ietf.org, turners@ieca.com, ipr-announce@ietf.org, stephen.farrell@cs.tcd.ie Subject: [IPsec] IPR Disclosure: Microsoft Corporation's Statement about IPR related to draft-ietf-ipsecme-ipsecha-protocol-06 (2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:49:15 -0000 Dear Rajeshwar Jenwar, Kalyani Garigipati, Yoav Nir, Yaron Sheffer, Dacheng= Zhang: An IPR disclosure that pertains to your Internet-Draft entitled "Protocol Support for High Availability of IKEv2/IPsec" (draft-ietf-ipsecme-ipsecha- protocol) was submitted to the IETF Secretariat on 2011-06-21 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1578/). The title of the IPR disclosure is "Microsoft Corporation's Statement about IPR related to draft-ietf-ipsecme- ipsecha-protocol-06 (2).""); The IETF Secretariat From wwwrun@rfc-editor.org Wed Jul 13 17:59:26 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15951F0C6F; Wed, 13 Jul 2011 17:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.024 X-Spam-Level: X-Spam-Status: No, score=-104.024 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXQzXQvtWYrU; Wed, 13 Jul 2011 17:59:25 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9451F0C6B; Wed, 13 Jul 2011 17:59:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 81DC998C55F; Wed, 13 Jul 2011 17:59:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110714005921.81DC998C55F@rfc-editor.org> Date: Wed, 13 Jul 2011 17:59:21 -0700 (PDT) Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 6311 on Protocol Support for High Availability of IKEv2/IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 00:59:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6311 Title: Protocol Support for High Availability of IKEv2/IPsec Author: R. Singh, Ed., G. Kalyani, Y. Nir, Y. Sheffer, D. Zhang Status: Standards Track Stream: IETF Date: July 2011 Mailbox: rsj@cisco.com, kagarigi@cisco.com, ynir@checkpoint.com, yaronf.ietf@gmail.com, zhangdacheng@huawei.com Pages: 26 Characters: 58672 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-ipsecha-protocol-06.txt URL: http://www.rfc-editor.org/rfc/rfc6311.txt The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However, there are many issues in IPsec HA clustering, and in particular in Internet Key Exchange Protocol version 2 (IKEv2) clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol. This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters. [STANDARDS-TRACK] This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From kivinen@iki.fi Thu Jul 21 16:53:41 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1539421F85D9 for ; Thu, 21 Jul 2011 16:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBBNP7xVpimb for ; Thu, 21 Jul 2011 16:53:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C2F21F85B8 for ; Thu, 21 Jul 2011 16:53:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p6LNrZio024042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Jul 2011 02:53:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p6LNrYMm008591; Fri, 22 Jul 2011 02:53:34 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20008.48126.941062.723271@fireball.kivinen.iki.fi> Date: Fri, 22 Jul 2011 02:53:34 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 55 min Subject: [IPsec] Raw ECDSA keys and IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 23:53:41 -0000 In the RFC5996 we have format for Raw RSA keys (using PKCS1 format). The current buzzword compatible mantra seems to be ECDSA or Elliptic Curve keys in general, so perhaps we should also allow Raw ECDSA keys to be used in the IKEv2? For the format we could either use one of the following: 1) RFC5480 2) Draft-hoffman-dnssec-ecdsa-04 3) Roll our own 4) Combination of few above The RFC5480 has the problem that it uses ASN.1, and many of the people want to use Raw Public Keys just because they do not want to use Self signed certificates because of ASN.1 requirement. Draft-hoffman-dnssec-ecdsa-04 uses DNSSec registries, do we want to reuse them? The case 4 would most likely be best, meaning we create own wrapper format where we have the curve information using our own registry (or reuse IKEv2 Authentication Method registry, as the key to be used will be used to create the Authentication Payload anyways), and then attach to that either the format from draft-hoffman-dnssec-ecdsa-04 section 4, or from RFC 5480 section 2.2. -- kivinen@iki.fi From B22344@freescale.com Fri Jul 22 05:05:32 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4995621F86C4 for ; Fri, 22 Jul 2011 05:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4ThpkYzBcMa for ; Fri, 22 Jul 2011 05:05:31 -0700 (PDT) Received: from DB3EHSOBE003.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5C86821F865D for ; Fri, 22 Jul 2011 05:05:31 -0700 (PDT) Received: from mail28-db3-R.bigfish.com (10.3.81.248) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.22; Fri, 22 Jul 2011 12:05:30 +0000 Received: from mail28-db3 (localhost.localdomain [127.0.0.1]) by mail28-db3-R.bigfish.com (Postfix) with ESMTP id D9000E50243 for ; Fri, 22 Jul 2011 12:05:29 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2dh2a8h668h839h8e2h8e3h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPVD:NLI; H:mail.freescale.net; RD:none; EFVD:NLI Received: from mail28-db3 (localhost.localdomain [127.0.0.1]) by mail28-db3 (MessageSwitch) id 1311336329553695_10003; Fri, 22 Jul 2011 12:05:29 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.243]) by mail28-db3.bigfish.com (Postfix) with ESMTP id 8083E4004B for ; Fri, 22 Jul 2011 12:05:29 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 22 Jul 2011 12:05:27 +0000 Received: from 039-SN1MPN1-003.039d.mgd.msft.net ([169.254.3.225]) by 039-SN1MMR1-003.039d.mgd.msft.net ([10.84.1.16]) with mapi id 14.01.0289.008; Fri, 22 Jul 2011 07:05:26 -0500 From: B Rampullaiah-B22344 To: "ipsec@ietfa.amsl.com" Thread-Topic: Need Info related to simultaneous rekey of IKE/IPSec SAs. Thread-Index: AcxIZ1N+/QJBsCvPR6y8a8F15axgwg== Date: Fri, 22 Jul 2011 12:05:26 +0000 Message-ID: <430A80FB34D5A949BA1BCC9C689FF9640D21B9@039-SN1MPN1-003.039d.mgd.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.232.117.28] Content-Type: multipart/alternative; boundary="_000_430A80FB34D5A949BA1BCC9C689FF9640D21B9039SN1MPN1003039d_" MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-Mailman-Approved-At: Fri, 22 Jul 2011 08:07:30 -0700 Subject: [IPsec] Need Info related to simultaneous rekey of IKE/IPSec SAs. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 12:07:46 -0000 --_000_430A80FB34D5A949BA1BCC9C689FF9640D21B9039SN1MPN1003039d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I need some information for the simulation of the following cases related t= o IKEV2 Exchange Collision Mechanism Implementation as per the RFC-4718. 1. When the host receives a request to rekey - a CHILD_SA pair that the hos= t is currently rekeying: Reply as usual, but prepare to close redundant SAs later based on the nonce= s. 2. When the host receives a request to rekey - the IKE_SA, and the host is = currently rekeying the IKE_SA: Reply as usual, but prepare to close redundant SAs and move inherited CHILD= _SAs later based on the nonces. 3. If a host receives a request to create or rekey a CHILD_SA when it is cu= rrently rekeying the IKE_SA: Reply with NO_ADDITIONAL_SAS. How to simulate the simultaneous rekeying of IKE/IPSec SAs? Regds, Ramu. --_000_430A80FB34D5A949BA1BCC9C689FF9640D21B9039SN1MPN1003039d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I need some information for the simulation of the= following cases related to IKEV2 Exchange Collision Mechanism Implementati= on as per the RFC-4718.

 

1. When the host receives a request to rekey - a = CHILD_SA pair that the host is currently rekeying:

Reply as usual, but prepare to close redundant SA= s later based on the nonces.

 

2. When the host receives a request to rekey - th= e IKE_SA, and the host is currently rekeying the IKE_SA:

Reply as usual, but prepare to close redundant SA= s and move inherited CHILD_SAs later based on the nonces.

 

3. If a host receives a request to create or reke= y a CHILD_SA when it is currently rekeying the IKE_SA:

      Reply with NO_ADDI= TIONAL_SAS.

 

How to simulate the simultaneous rekeying of IKE/= IPSec SAs?

 

Regds,

Ramu.

 

--_000_430A80FB34D5A949BA1BCC9C689FF9640D21B9039SN1MPN1003039d_-- From pramod.s.pawar@bt.com Fri Jul 22 07:27:00 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A4321F8ADC; Fri, 22 Jul 2011 07:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpf6gIRPvAah; Fri, 22 Jul 2011 07:26:59 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id A718421F8AAC; Fri, 22 Jul 2011 07:26:58 -0700 (PDT) Received: from EVHUB70-UKRD.domain1.systemhost.net (10.36.3.153) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 22 Jul 2011 15:26:57 +0100 Received: from EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) by EVHUB70-UKRD.domain1.systemhost.net (10.36.3.153) with Microsoft SMTP Server (TLS) id 14.1.323.0; Fri, 22 Jul 2011 15:26:57 +0100 Received: from EMV01-UKBR.domain1.systemhost.net ([169.254.1.8]) by EVMHT03-UKBR.domain1.systemhost.net ([193.113.108.56]) with mapi; Fri, 22 Jul 2011 15:26:57 +0100 From: To: Date: Fri, 22 Jul 2011 15:22:18 +0100 Thread-Topic: SecureComm2011 - Call for Posters Thread-Index: AQHMSHtoSbchWvVRbkqRKXkAgK15NA== Message-ID: <3C541DF34C043743A7BE9C16B7D2F72901FA7B0A21@EMV01-UKBR.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_3C541DF34C043743A7BE9C16B7D2F72901FA7B0A21EMV01UKBRdoma_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 22 Jul 2011 08:07:30 -0700 Subject: [IPsec] SecureComm2011 - Call for Posters X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:27:00 -0000 --_000_3C541DF34C043743A7BE9C16B7D2F72901FA7B0A21EMV01UKBRdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SECURECOMM 2011 CALL FOR POSTERS Seventh International Conference on Network Security & Privacy (SecureComm = 2011) London, United Kingdom Sept 7-9, 2011 WWW: http://www.securecomm.org Deadline for submissions: 3rd August 2011 Notification of Acceptance: 10th August 2011 ________________________________ The poster session will provide a forum for researchers to show their work = and obtain constructive feedback on ongoing research from knowledgeable con= ference attendees. Areas of technical interest are the same as those listed= in the technical call for papers. While the poster need not describe compl= eted work, it should report on research for which at least preliminary resu= lts are available. At least one of the authors of the poster must register for the conference = for the poster to be included as part of the poster session. SUBMISSION INSTRUCTIONS ________________________________ Each submission should also include an abstract of up to 250 words summariz= ing the research work and 2 A4 pages detailing the scientific merit of the = research work. Both the abstract and the poster must have the title, authors, institutiona= l affiliations and contact information. Please submit your poster to the Conference General Chair Dr Muttukrishnan = Rajarajan Email: r.muttukrishnan@city.ac.uk , in PDF format. PRESENTATION OF POSTERS ________________________________ Authors of accepted poster proposals will have a chance to present the post= er to interested attendees during a special poster session at the conferenc= e. Well-crafted posters will tell the story well by themselves, but author= s of posters are expected to be available to describe and discuss the work = in the poster during the session. ________________________________ --_000_3C541DF34C043743A7BE9C16B7D2F72901FA7B0A21EMV01UKBRdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= &n= bsp;

= SECURECOMM 2011

= CALL FOR POSTERS

= Seventh International Conference on Network Security & Privacy (SecureComm 201= 1)
London, United Kingdom
Sept 7-9, 2011

WWW: http://www.securecomm.org

Deadline for submissions: 3rd August 2011

Notification of Acceptance: 10th August 2011

The poster sessio= n will provide a forum for researchers to show their work and obtain constr= uctive feedback on ongoing research from knowledgeable conference attendees. Areas of technical interest are the same as those li= sted in the technical call for papers. While the poster need not describe c= ompleted work, it should report on research for which at least preliminary = results are available.

<= font color=3D"#000000">At l= east one of the authors of the poster must register for the conference for = the poster to be included as part of the poster session.

 <= /font>

SUBMISSION INSTRUCTIONS

Each submission should a= lso include an abstract of up to 250 words summarizing the research work an= d 2 A4 pages detailing the scientific merit of the research work.

Both the abstract and th= e poster must have the title, authors, institutional affiliations and conta= ct information.

Please submit your poste= r to the Conference General Chair Dr Muttukrishnan Rajarajan Email: r.muttukrishnan@city.ac.uk<= /u> , in PDF format.

 

PRESENTATION OF POSTERS

Authors of accepted post= er proposals will have a chance to present the poster to interested attende= es during a special poster session at the conference.  Well-crafted po= sters will tell the story well by themselves, but authors of posters are ex= pected to be available to describe and discuss the work in the poster durin= g the session.

 
<= /div>
--_000_3C541DF34C043743A7BE9C16B7D2F72901FA7B0A21EMV01UKBRdoma_-- From kagarigi@cisco.com Sun Jul 24 22:59:44 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E36B21F85DA for ; Sun, 24 Jul 2011 22:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrqZcT-X93SP for ; Sun, 24 Jul 2011 22:59:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6244211E8084 for ; Sun, 24 Jul 2011 22:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kagarigi@cisco.com; l=12536; q=dns/txt; s=iport; t=1311573582; x=1312783182; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=GYJZKZA6VzL3iWWJVFneutfHfmrgXOlBKubpqnduW4o=; b=eDaRbmpn+HhtaJqI6JQxYX/GYOuEH2Y6d7L2CM6aK4RdDxYoYFwMWxU3 cQ28eStDXQVZ8mMBFpIcPVeR5ihChONimnU1aBy6zktTYVWTedeQducvN iuvpsB64+t2ZBuz8oObXHk/Ly//3sXhl6HHtFLkQCjh9/WXTY4S+HteUT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAF0FLU6rRDoG/2dsb2JhbAA0AQEBAQMUAQwSA08RAgEJEQQBAQsGIwEGARM7DggBAQUMCwwbgjaVJI9Ud6tEnUqFYF8Eh1OQLYtY X-IronPort-AV: E=Sophos;i="4.67,258,1309737600"; d="scan'208,217";a="6008861" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jul 2011 05:59:41 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6P5x4SY031016; Mon, 25 Jul 2011 05:59:38 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 11:29:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4A8F.FBDD371E" Date: Mon, 25 Jul 2011 11:29:14 +0530 Message-ID: <04BD913C7AD1B84297D26D5614FBE1330466A394@XMB-BGL-417.cisco.com> In-reply-to: <430A80FB34D5A949BA1BCC9C689FF9640D21B9@039-SN1MPN1-003.039d.mgd.msft.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Need Info related to simultaneous rekey of IKE/IPSec SAs. Thread-Index: AcxIZ1N+/QJBsCvPR6y8a8F15axgwgCKDy+g References: <430A80FB34D5A949BA1BCC9C689FF9640D21B9@039-SN1MPN1-003.039d.mgd.msft.net> From: "Kalyani Garigipati (kagarigi)" To: "B Rampullaiah-B22344" X-OriginalArrivalTime: 25 Jul 2011 05:59:15.0244 (UTC) FILETIME=[FBD0B6C0:01CC4A8F] Cc: ipsec@ietfa.amsl.com Subject: Re: [IPsec] Need Info related to simultaneous rekey of IKE/IPSec SAs. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 05:59:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4A8F.FBDD371E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Ramu, =20 You can have a middle router between two ike peers. 1. Establish the ike and ipsec sa 2. Make one of the interfaces on middle router as down. 3. Then ensure ike/ipsec rekey happens simultaneously on both the routers. Since the middle router is down, the packets are don't reach peer, but are retransmitted. 4. Now make the interface up. The ike /ipsec rekey packets cross each other. And simulatenous rekey happens. =20 Regards, Kalyani =20 =20 =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of B Rampullaiah-B22344 Sent: Friday, July 22, 2011 5:35 PM To: ipsec@ietfa.amsl.com Subject: [IPsec] Need Info related to simultaneous rekey of IKE/IPSec SAs. =20 Hi, =20 I need some information for the simulation of the following cases related to IKEV2 Exchange Collision Mechanism Implementation as per the RFC-4718. =20 1. When the host receives a request to rekey - a CHILD_SA pair that the host is currently rekeying: Reply as usual, but prepare to close redundant SAs later based on the nonces. =20 2. When the host receives a request to rekey - the IKE_SA, and the host is currently rekeying the IKE_SA: Reply as usual, but prepare to close redundant SAs and move inherited CHILD_SAs later based on the nonces. =20 3. If a host receives a request to create or rekey a CHILD_SA when it is currently rekeying the IKE_SA: Reply with NO_ADDITIONAL_SAS. =20 How to simulate the simultaneous rekeying of IKE/IPSec SAs? =20 Regds, Ramu. =20 ------_=_NextPart_001_01CC4A8F.FBDD371E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = Ramu,

 

You can have a middle = router between two ike peers.

1.       Establish = the ike and ipsec sa

2.       Make one of = the interfaces on middle router as down.

3.       Then ensure ike/ipsec rekey happens simultaneously on both the routers. Since the = middle router is down, the packets are don’t reach peer, but are = retransmitted.

4.       Now make = the interface up. The ike /ipsec rekey packets cross each other. And = simulatenous rekey happens.

 

Regards,

Kalyani

       

 

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = B Rampullaiah-B22344
Sent: Friday, July 22, 2011 5:35 PM
To: ipsec@ietfa.amsl.com
Subject: [IPsec] Need Info related to simultaneous rekey of = IKE/IPSec SAs.

 

Hi,

 

I need some information for the simulation of = the following cases related to IKEV2 Exchange Collision Mechanism = Implementation as per the RFC-4718.

 

1. When the host receives a request to rekey - a = CHILD_SA pair that the host is currently rekeying:

Reply as usual, but prepare to close redundant = SAs later based on the nonces.

 

2. When the host receives a request to rekey - = the IKE_SA, and the host is currently rekeying the IKE_SA:

Reply as usual, but prepare to close redundant = SAs and move inherited CHILD_SAs later based on the nonces.

 

3. If a host receives a request to create or = rekey a CHILD_SA when it is currently rekeying the IKE_SA:

      Reply with NO_ADDITIONAL_SAS.

 

How to simulate the simultaneous rekeying of = IKE/IPSec SAs?

 

Regds,

Ramu.

 

------_=_NextPart_001_01CC4A8F.FBDD371E-- From kivinen@iki.fi Mon Jul 25 06:46:36 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF5D21F84CE for ; Mon, 25 Jul 2011 06:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM5-2cZx55XV for ; Mon, 25 Jul 2011 06:46:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD7321F84D1 for ; Mon, 25 Jul 2011 06:46:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p6PDkVbm026494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jul 2011 16:46:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p6PDkVwa004045; Mon, 25 Jul 2011 16:46:31 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit Message-ID: <20013.29623.491247.654466@fireball.kivinen.iki.fi> Date: Mon, 25 Jul 2011 16:46:31 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 1 min Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-secure-password-framework-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 13:46:36 -0000 CONTENT-TRANSFER-ENCODING: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fireball.kivinen.iki.fi X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_50,CANCEL_DNSWL_FROM_IKI, IKI_FI_RECEIVED,KIVINEN_GOOD_TEXT,RCVD_IN_DNSWL_MED,RDNS_NONE autolearn=no version=3.2.5 Received: from nyssetulee.iki.fi (root@nyssetulee.iki.fi [IPv6:2001:67c:2b0:1c1::194]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p6PDTsdU011367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jul 2011 16:29:54 +0300 (EEST) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::1e]) by nyssetulee.iki.fi (8.14.5/8.14.4) with ESMTP id p6PDTrcI004057 for ; Mon, 25 Jul 2011 16:29:54 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D78F21F8AB9 for ; Mon, 25 Jul 2011 06:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+52bNJ0xU-u for ; Mon, 25 Jul 2011 06:29:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C4621F8AAC; Mon, 25 Jul 2011 06:29:50 -0700 (PDT) X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110725132950.3833.99996.idtracker@ietfa.amsl.com> From: internet-drafts@ietf.org To: kivinen@iki.fi Cc: kivinen@iki.fi Subject: New Version Notification for draft-kivinen-ipsecme-secure-password-framework-01.txt Date: Mon, 25 Jul 2011 06:29:50 -0700 A new version of I-D, draft-kivinen-ipsecme-secure-password-framework-0= 1.txt has been successfully submitted by Tero Kivinen and posted to the= IETF repository. Filename:=09 draft-kivinen-ipsecme-secure-password-framework Revision:=09 01 Title:=09=09 Secure Password Framework for IKEv2 Creation date:=09 2011-07-25 WG ID:=09=09 Individual Submission Number of pages: 14 Abstract: This document creates a generic way for Internet Key Exchange (IKEv2= ) to use any of the symmetric secure password authentication methods. There are multiple methods already specified in other documents and this document does not add new one. This document specifies a commo= n way so those methods can agree on which method is to be used in current connection. This document also provides a common way to transmit secure password authentication method specific payloads between peers. = =20 The IETF Secretariat From prbatra@cisco.com Mon Jul 25 20:29:55 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECF521F85B2 for ; Mon, 25 Jul 2011 20:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq3AbM6VzEKp for ; Mon, 25 Jul 2011 20:29:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BC1CE21F85AA for ; Mon, 25 Jul 2011 20:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=255; q=dns/txt; s=iport; t=1311650994; x=1312860594; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=DRzB5XZAmvUO0mN0YMt8za4DybVJeyBm1thaC/FBvPM=; b=A7eN9EiKCPTKbxpBls5t6GbV3wgd6JM8mYLgU3RfWE1jp3PJ0VUPFwIJ 4dmZ4ECno+5JA9IZVGArLKCbuHFSS+z+DlK5p+rQ8TqLAtaGX/jw1xTdE lEMnI0AxOT+Inw2OAdl5CP9lV/Bs8/Zg+cZGMQ1Rdo33BPoPpdIR+h3bC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsHALozLk5Io8US/2dsb2JhbAA1AQEBAxQBIQpWAgErBiQGARNRAQEFDBcbmCCPFHesHp5bhWBfBIdVkC2LWA X-IronPort-AV: E=Sophos;i="4.67,266,1309737600"; d="scan'208";a="44265559" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 26 Jul 2011 03:29:52 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6Q3TBXA009041 for ; Tue, 26 Jul 2011 03:29:51 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 08:59:43 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: fSU= AMa4 A3oe A+vf CFot EsCh E4Nx FQJG F/wz GL3l GRgN HLeY Hsw/ H6oF I3W/ JnUh; 1; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {23720390-B9F9-4BE2-B914-772F4C4AE48B}; cAByAGIAYQB0AHIAYQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Tue, 26 Jul 2011 03:29:39 GMT; RABIACAAawBlAHkAcwAgAGMAYQBsAGMAdQBsAGEAdABpAG8AbgAgAHAAZQByAGYAbwByAG0AYQBuAGMAZQA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {23720390-B9F9-4BE2-B914-772F4C4AE48B} Content-class: urn:content-classes:message Date: Tue, 26 Jul 2011 08:59:38 +0530 Message-ID: In-Reply-To: <20013.29623.491247.654466@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DH keys calculation performance Thread-Index: AcxK0UywJgRnA9ThSiW+Is6Eot+WkgAcjspg References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> From: "Prashant Batra (prbatra)" To: X-OriginalArrivalTime: 26 Jul 2011 03:29:44.0171 (UTC) FILETIME=[430D5BB0:01CC4B44] Subject: [IPsec] DH keys calculation performance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 03:29:55 -0000 Hello, The DH exchange (Calculation of Public/Private key and the Secret) in IKEV2 Initial exchange=20 seems to be very expensive. This is slowing down the overall IKEv2 tunnel establishment. Is there a way to optimize it? Regards, Prashant From vishwas.ietf@gmail.com Mon Jul 25 21:37:40 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA00211E807F for ; Mon, 25 Jul 2011 21:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcrsE189m1h0 for ; Mon, 25 Jul 2011 21:37:39 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7983A21F8591 for ; Mon, 25 Jul 2011 21:37:39 -0700 (PDT) Received: by vws12 with SMTP id 12so56385vws.31 for ; Mon, 25 Jul 2011 21:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FEqtnf5KdazC33yj2mdAOfX70h7hxBUbwL0o3FbsMtE=; b=DXoYFiPXcJE1neueQ8DxyU6C4NkyDLdsn1W6r3y+q+m/hcEdM/ZKathPOac4dDXBEv 8CTTKC50xDtgamwzy6KNAN2HCA/tZaMhWTjq5BsfZrR3IrCFkINjezQpTEzo4ALZyO0s 61iZmAywlbzD1pWhe25UwPDkiit4NwGDcU2qM= MIME-Version: 1.0 Received: by 10.52.64.143 with SMTP id o15mr5258847vds.45.1311655058830; Mon, 25 Jul 2011 21:37:38 -0700 (PDT) Received: by 10.52.158.234 with HTTP; Mon, 25 Jul 2011 21:37:38 -0700 (PDT) In-Reply-To: References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> Date: Mon, 25 Jul 2011 21:37:38 -0700 Message-ID: From: Vishwas Manral To: "Prashant Batra (prbatra)" Content-Type: multipart/alternative; boundary=20cf30776153d9770504a8f17d4d Cc: ipsec@ietf.org Subject: Re: [IPsec] DH keys calculation performance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 04:37:41 -0000 --20cf30776153d9770504a8f17d4d Content-Type: text/plain; charset=ISO-8859-1 Hi Prashant, Back in the days we had some acceleration of DH in the hardware http://www.wipo.int/patentscope/search/en/WO2005008999. Other things you can do is put in more CPU or use a lower DH group. Thanks, Vishwas On Mon, Jul 25, 2011 at 8:29 PM, Prashant Batra (prbatra) wrote: > Hello, > > The DH exchange (Calculation of Public/Private key and the Secret) in > IKEV2 Initial exchange > seems to be very expensive. This is slowing down the overall IKEv2 > tunnel establishment. > Is there a way to optimize it? > > > Regards, > Prashant > --20cf30776153d9770504a8f17d4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Prashant,
=A0
Back in the days we had some acceleration of DH in the hardware http://www.wip= o.int/patentscope/search/en/WO2005008999.
=A0
Other things you can do is put in more CPU or=A0use a lower DH group.<= /div>
=A0
Thanks,
Vishwas

On Mon, Jul 25, 2011 at 8:29 PM, Prashant Batra = (prbatra) <prbatr= a@cisco.com> wrote:
Hello,

The DH exchange (C= alculation of Public/Private key and the Secret) in
IKEV2 Initial exchan= ge
seems to be very expensive. This is slowing down the overall IKEv2
tunne= l establishment.
Is there a way to optimize it?


Regards,
P= rashant
--20cf30776153d9770504a8f17d4d-- From ynir@checkpoint.com Tue Jul 26 03:40:30 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D598521F86DC for ; Tue, 26 Jul 2011 03:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3voRSKS6wNZp for ; Tue, 26 Jul 2011 03:40:30 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 93FAC21F86C4 for ; Tue, 26 Jul 2011 03:40:28 -0700 (PDT) X-CheckPoint: {4E2EA730-9-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6QAeMwb011282; Tue, 26 Jul 2011 13:40:22 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 26 Jul 2011 13:40:22 +0300 From: Yoav Nir To: "Prashant Batra (prbatra)" Date: Tue, 26 Jul 2011 13:40:19 +0300 Thread-Topic: [IPsec] DH keys calculation performance Thread-Index: AcxLgGtt7Mr1sXbTTLCdSZY1cCxZ2A== Message-ID: <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-7-509654174"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] DH keys calculation performance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 10:40:30 -0000 --Apple-Mail-7-509654174 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: > Hello, >=20 > The DH exchange (Calculation of Public/Private key and the Secret) in > IKEV2 Initial exchange=20 > seems to be very expensive. This is slowing down the overall IKEv2 > tunnel establishment. > Is there a way to optimize it? Hi Prashant. I know of three ways to optimize the D-H exchange. First, note that each peer has to perform two operations:=20 1. Generate: create a random x and calculate X=3D2^x mod p 2. Derive: calculate the shared secret S=3DY^x mod p The "Derive" operation has to be done during the exchange, but the = "Generate" operation can be done long before the exchange. If your = problem is degraded performance at some peak, you can pre-generate some = values. This has a high cost in memory, but can be useful for dealing = with peaks. Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 mod = p)) mod p If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p = for 0<=3Dx<=3D2048 and store these values. After that, both the generate = and derive operations become simple multiplications of the resulting = values. This has a fixed cost in memory, but can accelerate things. Third, you may want to look at the EC groups. The EC operations require = less computation. Hope this helps Yoav --Apple-Mail-7-509654174 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBScwggQPoAMC AQICEBW9tBlVg9WZf9zHij2h3zMwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNzIxMDAwMDAwWhcNMTIwNzIwMjM1OTU5WjAkMSIwIAYJKoZI hvcNAQkBFhN5bmlyQGNoZWNrcG9pbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxha8w2xboHPbsj9HBz/1LdG2kwp++sXC5I0izECjJRravnWdnlDqTSRx7outPOk4zkfP/jtO ZiFl35/W/ZgiVilKNrCAcIk4J4VYdbhUItos2Z1ydt1JcY6F24faWNNns2hV/cF6pNELNTxPYIsY HrVy7Cq7/oywfHQimKbL4cVZvUF34P57gZKrxKBEkw3cUAzch7bQ8pTtewjvFW+cjpDqPaFSZyGJ VfbBtAg3RBjlOolfp2VlTmLGW3gRxg9hi7XAxjJf417I9b1hz0NpTnhSr7n38zMEyUdhqr2Wb37b yFNmhF+dWeBUX/RzgdIeqO/whtI1+gH8ZNuzpAV1UQIDAQABo4IB4zCCAd8wHwYDVR0jBBgwFoAU ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFPzBjRi9Qe40hv+WSad/Om18V8HmMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEF BQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETeW5pckBjaGVj a3BvaW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAkLgfz4ztXKON97ZHaqFhBfxO3QGPhx76iB1U 9LevFF/AsfS0ap2IWzGDocGJze17FZTjM41vCpRORCKCAdek+u+6RO95zx8VQaZybicBNCGBb4LP 1h8GvtmrT/+JpdtETJp9i1KIEwn8hn9Q4aMdkk8S2QkemBmhzGXdcQ5nCxyCQHk1hcRSDhC1qfME DPGlKMxqDpMHrFmiI6vdCVBhufX7xECsGXOJDqMWMPg7YE0fubg50T8ehNHJ2Mvm8JpYIGwTIC3v V9egV4ghYxHXm6u1zbXZUD+3pV9cNKbboB1FjuVqzKIiuNnzsZ3StcasZRYaxlwaHAU4uAuNyzbN 3jGCA6swggOnAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZ VYPVmX/cx4o9od8zMAkGBSsOAwIaBQCgggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTExMDcyNjEwNDAxOVowIwYJKoZIhvcNAQkEMRYEFNk93XkQvj5gAt/Ug03/ jWQtGZp1MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEBW9tBlVg9WZf9zHij2h3zMwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZVYPVmX/cx4o9od8zMA0GCSqGSIb3DQEBAQUA BIIBAEhf059/czKDbaS32o93v2h2/H38awJDZ4RPh6Oz03OGh8KvxSoAOStREPSNTwie5FZUxXg+ yQg2VRW96tv2WDIP6QcHs86uY1UXPkGRn3UVpk2CwwFJhwZ5bU/VPhLzLBz2kOJyPzpmzjtjk5N3 3u3p7JsCo3ocdV0uFiFflJ+PLMCA79r1DMZqxe18ofsiTYOD+UPzlZAeQety4QxeSIwd/VpKIBKk PE8++WPFpOx4nA6VIXkwvUSbXt+PYKuSloc/xmPbwWHy2kEhJSea1HnMYfa9qOvoD5niQ7Bll/M7 n2pS9n3jQ9W2koh4D7qC/mawxMWSYnuBMBL6s9AAYCEAAAAAAAA= --Apple-Mail-7-509654174-- From yaronf.ietf@gmail.com Tue Jul 26 04:17:34 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CDF21F8C54 for ; Tue, 26 Jul 2011 04:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWhtYY2EXVHL for ; Tue, 26 Jul 2011 04:17:33 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 884AA21F8C50 for ; Tue, 26 Jul 2011 04:17:33 -0700 (PDT) Received: by wwg11 with SMTP id 11so2176337wwg.1 for ; Tue, 26 Jul 2011 04:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LB79WW0B1wUUAoPt3sowaWfE0adA/VEioWaJ08dbyz4=; b=HByF9tEnlkmOgW5Z9D6ja5/hONG8MnCnGO68pOMnwd2MAOfTkReNDzDpKbYD2uibwE kD4MVJOLbLy/tZvj0YW6K8sYxwHBpU4ZeksDlqR2DIk/TZpSIpoJiVFqdsqwK7bcBkEY z0Ob/8XHrOEu6H7LqYZSzP/zI3/DzAr032PAk= Received: by 10.227.24.68 with SMTP id u4mr4799261wbb.43.1311679052620; Tue, 26 Jul 2011 04:17:32 -0700 (PDT) Received: from [10.0.0.6] (93-173-6-225.bb.netvision.net.il [93.173.6.225]) by mx.google.com with ESMTPS id 20sm333432wbw.36.2011.07.26.04.17.31 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 04:17:31 -0700 (PDT) Message-ID: <4E2EA248.70708@gmail.com> Date: Tue, 26 Jul 2011 14:17:28 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Yoav Nir References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> In-Reply-To: <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "ipsec@ietf.org" , "Prashant Batra \(prbatra\)" Subject: Re: [IPsec] DH keys calculation performance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 11:17:34 -0000 You might want to review http://tools.ietf.org/html/rfc5996#section-2.12.

Also, session resumption (http://tools.ietf.org/html/rfc5723) reduces the computational costs of renewing an IKE SA when a client needs to reconnect to a gateway a second time after some failure.

Thanks,
    Yaron

On 07/26/2011 01:40 PM, Yoav Nir wrote: 
On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote:


Hello,

The DH exchange (Calculation of Public/Private key and the Secret) in
IKEV2 Initial exchange 
seems to be very expensive. This is slowing down the overall IKEv2
tunnel establishment.
Is there a way to optimize it?

Hi Prashant.

I know of three ways to optimize the D-H exchange.

First, note that each peer has to perform two operations: 
 1. Generate: create a random x and calculate X=2^x mod p
 2. Derive: calculate the shared secret S=Y^x mod p
The "Derive" operation has to be done during the exchange, but the "Generate" operation can be done long before the exchange. If your problem is degraded performance at some peak, you can pre-generate some values. This has a high cost in memory, but can be useful for dealing with peaks.

Second, note that 2^73 mod p = ((2^64 mod p) * (2^8 mod p) * (2^1 mod p)) mod p
If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p for 0<=x<=2048 and store these values. After that, both the generate and derive operations become simple multiplications of the resulting values. This has a fixed cost in memory, but can accelerate things.

Third, you may want to look at the EC groups. The EC operations require less computation.

Hope this helps

Yoav




_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
From prbatra@cisco.com Tue Jul 26 06:03:49 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C7C21F8BD3 for ; Tue, 26 Jul 2011 06:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLQcmaVSncRI for ; Tue, 26 Jul 2011 06:03:48 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD6E21F8BA3 for ; Tue, 26 Jul 2011 06:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=10254; q=dns/txt; s=iport; t=1311685427; x=1312895027; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=u4rtrR0UPRHcuv1FmzkfIiAMSdjGlByOC9WqV1nQrnE=; b=MymEAyBWbNEWRk5ATMkQdqmid7WGcTpiKpVlv7Pkbc765SBGQ2SK022W vbp1y7eN9U3kRXAOBEntwIRj7hITNsyxs9Th17Pv6E41S1PtqQcn5Ipgn z1BbhF2SM6K1vwrTfTurk7jQm3B2PaHop+hw42hoIN61JbMpjM+RdAM92 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AAHW6Lk5Io8UT/2dsb2JhbAA1AQEBAQMBAQERAQwSA0QLEQIBCREEAQELBiMBBgETEgYjDggBAQUBCwsMG4I2lSaHLAGILHeJAKNRnmOFYV8Eh1WQLYRZhn8 X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208,217";a="44354190" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 26 Jul 2011 13:03:44 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6QD3HQq015553; Tue, 26 Jul 2011 13:03:43 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 18:33:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4B94.67106B3E" Date: Tue, 26 Jul 2011 18:33:23 +0530 Message-ID: In-Reply-To: <4E2EA248.70708@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] DH keys calculation performance Thread-Index: AcxLhaEQ/3n0iknoSYWMDOSNUKdLmQADrOhA References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> From: "Prashant Batra (prbatra)" To: "Yaron Sheffer" , "Yoav Nir" X-OriginalArrivalTime: 26 Jul 2011 13:03:24.0647 (UTC) FILETIME=[67412F70:01CC4B94] Cc: ipsec@ietf.org Subject: Re: [IPsec] DH keys calculation performance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 13:03:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4B94.67106B3E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Yoav and Yaron for the suggestions. Even I was thinking and tried generating and storing the key pair well in the beginning,. This helped to some extent. =20 The secret calculation is also very expensive, but this has to be done in midst of the exchange only. =20 Regards, Prashant=20 =20 =20 From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 Sent: Tuesday, July 26, 2011 4:47 PM To: Yoav Nir Cc: Prashant Batra (prbatra); ipsec@ietf.org Subject: Re: [IPsec] DH keys calculation performance =20 You might want to review http://tools.ietf.org/html/rfc5996#section-2.12. Also, session resumption (http://tools.ietf.org/html/rfc5723) reduces the computational costs of renewing an IKE SA when a client needs to reconnect to a gateway a second time after some failure. Thanks, Yaron On 07/26/2011 01:40 PM, Yoav Nir wrote:=20 =20 On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: =20 Hello, =20 The DH exchange (Calculation of Public/Private key and the Secret) in IKEV2 Initial exchange=20 seems to be very expensive. This is slowing down the overall IKEv2 tunnel establishment. Is there a way to optimize it? =20 Hi Prashant. =20 I know of three ways to optimize the D-H exchange. =20 First, note that each peer has to perform two operations:=20 1. Generate: create a random x and calculate X=3D2^x mod p 2. Derive: calculate the shared secret S=3DY^x mod p The "Derive" operation has to be done during the exchange, but the "Generate" operation can be done long before the exchange. If your problem is degraded performance at some peak, you can pre-generate some values. This has a high cost in memory, but can be useful for dealing with peaks. =20 Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 mod p)) mod p If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p for 0<=3Dx<=3D2048 and store these values. After that, both the generate = and derive operations become simple multiplications of the resulting values. This has a fixed cost in memory, but can accelerate things. =20 Third, you may want to look at the EC groups. The EC operations require less computation. =20 Hope this helps =20 Yoav =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01CC4B94.67106B3E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Yoav and Yaron  for the = suggestions.

Even I was thinking and tried generating and storing the = key pair  well in the beginning,.  This helped to some = extent.

 

The secret calculation is also very expensive, but this = has to be done in midst of the exchange only.

 

Regards,

Prashant

 

 

From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Tuesday, July 26, 2011 4:47 PM
To: Yoav Nir
Cc: Prashant Batra (prbatra); ipsec@ietf.org
Subject: Re: [IPsec] DH keys calculation = performance

 

You might want to review http://tools.iet= f.org/html/rfc5996#section-2.12.

Also, session resumption (http://tools.ietf.org/html/rf= c5723) reduces the computational costs of renewing an IKE SA when a client = needs to reconnect to a gateway a second time after some failure.

Thanks,
    Yaron

On 07/26/2011 01:40 PM, Yoav Nir wrote: 

 
On Jul 25, 2011, at 11:29 PM, Prashant =
Batra (prbatra) wrote:
 
Hello,
 
The DH exchange (Calculation of =
Public/Private key and the Secret) in
IKEV2 Initial =
exchange 
seems to be very expensive. This is =
slowing down the overall IKEv2
tunnel =
establishment.
Is there a way to optimize =
it?
 
Hi =
Prashant.
 
I know of =
three ways to optimize the D-H =
exchange.
 
First, note =
that each peer has to perform two operations: =

 1. Generate: create a random x and calculate =
X=3D2^x mod p
 2. Derive: calculate the shared =
secret S=3DY^x mod p
The "Derive" =
operation has to be done during the exchange, but the =
"Generate" operation can be done long before the exchange. If =
your problem is degraded performance at some peak, you can pre-generate =
some values. This has a high cost in memory, but can be useful for =
dealing with =
peaks.
 
Second, note =
that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 mod p)) mod =
p
If you're using a 2048-bit D-H group, you can =
pre-calculate 2^x mod p for 0<=3Dx<=3D2048 and store these values. =
After that, both the generate and derive operations become simple =
multiplications of the resulting values. This has a fixed cost in =
memory, but can accelerate =
things.
 
Third, you may =
want to look at the EC groups. The EC operations require less =
computation.
 
Hope this =
helps
 
Yoav
 













_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
------_=_NextPart_001_01CC4B94.67106B3E-- From yaronf.ietf@gmail.com Tue Jul 26 06:43:07 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2081E21F8B9F for ; Tue, 26 Jul 2011 06:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.87 X-Spam-Level: X-Spam-Status: No, score=-102.87 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug7wM7HIVaLT for ; Tue, 26 Jul 2011 06:43:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57B9B21F8B8D for ; Tue, 26 Jul 2011 06:43:06 -0700 (PDT) Received: by wwe5 with SMTP id 5so352568wwe.13 for ; Tue, 26 Jul 2011 06:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Y+HOwGVi9TdC7ul645KiTs0Jkjbek+gE8Z7uMEfxwcY=; b=NytUu2yaddLhNraWEyTEeFf/WWdjvbq1Sec3It24l3yvmsmlxxxh6nGdKSyhAsnvK8 XoD/xC+pSmGJ/9JQXz1bNE/NDQhibS5Qf8zuCppbx97ONdObxHmcmzbItp0dQWj5etK8 Wc6LXgZuWJulkkH1/xZJtaBxGzZXsJP7wUvKc= Received: by 10.227.29.19 with SMTP id o19mr4981358wbc.31.1311687785472; Tue, 26 Jul 2011 06:43:05 -0700 (PDT) Received: from [10.0.0.6] (93-173-6-225.bb.netvision.net.il [93.173.6.225]) by mx.google.com with ESMTPS id o19sm447375wbh.9.2011.07.26.06.43.04 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 06:43:04 -0700 (PDT) Message-ID: <4E2EC467.2010108@gmail.com> Date: Tue, 26 Jul 2011 16:43:03 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: IPsecme WG References: <4E2EA4BF.4040005@gmail.com> <984CD17A-3636-4DAF-AF4C-B40A8DD884AC@vpnc.org> In-Reply-To: <984CD17A-3636-4DAF-AF4C-B40A8DD884AC@vpnc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] IPsecme WG: a quick update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 13:43:07 -0000 Hi, The working group recently published its last chartered deliverable, RFC 6311 (HA Protocol). We would like to use this opportunity to thank the authors. The group has not met for the last few IETF meetings, and will not meet this week in Quebec City. The current charter (http://tools.ietf.org/wg/ipsecme/charters) is set to auto-expire by 2/2012, which means the group is now officially going into hibernation, and will disband in February unless we have a new charter before that date. If you have a work item that you believe will be of interest to multiple WG participants, you will need to raise it on the mailing list and to get enough group support to explicitly add it to the charter. You will need to convince the chairs and ADs that several people with different affiliations are committed to contribute to the work item. Otherwise, the alternative document streams (Independent or Individual) are your best bet. We are open to suggestions for new work items, but are not actively trying to keep the WG open. Any proposals would need to come with commitments from more than just one or two people to work on them. Thanks, Paul and Yaron From dharkins@lounge.org Tue Jul 26 07:56:00 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F9321F863A for ; Tue, 26 Jul 2011 07:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5tyEfl+M4EN for ; Tue, 26 Jul 2011 07:55:59 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE4821F8890 for ; Tue, 26 Jul 2011 07:55:55 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BAF02A888108; Tue, 26 Jul 2011 07:55:54 -0700 (PDT) Received: from 130.129.103.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 26 Jul 2011 07:55:54 -0700 (PDT) Message-ID: In-Reply-To: References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> Date: Tue, 26 Jul 2011 07:55:54 -0700 (PDT) From: "Dan Harkins" To: "Prashant Batra (prbatra)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] DH keys calculation performance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:56:00 -0000 Hello, On Tue, July 26, 2011 6:03 am, Prashant Batra (prbatra) wrote: > Thanks Yoav and Yaron for the suggestions. > > Even I was thinking and tried generating and storing the key pair well > in the beginning,. This helped to some extent. > > > > The secret calculation is also very expensive, but this has to be done > in midst of the exchange only. You could pick one secret x and then for IKE exchanges do this: 0th exchange: y = g^x mod p 1st exchange: y = g^(x+1) mod p 2nd exchange: y = g^(x+2) mod p . . . nth exchange: y = g^(x+n) mod p Getting from exchange i to exchange i+1, then, is just a single modular multiply, which should be "cheaper" for you. Knowing n, y, g and p and that y = g^(x+n) mod p does not really give an advantage (above the discrete logarithm problem) in finding x. That said, I still would not suggest doing many more than a few of these (and I am not qualified to quantify that statement) but for a few-- i.e. keep n small and after n choose a new x and repeat-- it should be OK. Maybe this technique will allow you to "cheapen" your exchange a bit. I think throwing hardware at this problem is your best bet though. regards, Dan. From sfluhrer@cisco.com Tue Jul 26 08:13:38 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E724521F8834 for ; Tue, 26 Jul 2011 08:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFBC7tbVr8US for ; Tue, 26 Jul 2011 08:13:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2E46321F854D for ; Tue, 26 Jul 2011 08:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=2495; q=dns/txt; s=iport; t=1311693218; x=1312902818; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=aAy3FOgsu2TLlswQFiCaQNMNKnoQYp0EkJkujxYL09s=; b=BVPnJD7tbGEuFshwzI3Pk0a2xIwYz8W5+hGQe5umbJhD8K01HtABEm5r CapyR76xQvyiGXMae2HAOuw31qNdL+jJFGnuwCbJjJ16Qk01N+CMSb7cl xqwHkOK7NvskuPdsLt/8Pshaa7Jj88nvAF8jASQ7RS9wFKgyuz14VJ5y1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4AAKXYLk6rRDoJ/2dsb2JhbAA2AQEBAQMUASEKNw4MBQIBCQ4DBAEBAQoGIwEGARM7DggBAQUBFgwbl1yPWnerfp5ghWFfBIdXkCuLcA X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208";a="6521648" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jul 2011 15:13:37 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6QFDbqP029388; Tue, 26 Jul 2011 15:13:37 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 08:13:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 08:13:33 -0700 Message-ID: In-Reply-To: <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] DH keys calculation performance Thread-Index: AcxLgGtt7Mr1sXbTTLCdSZY1cCxZ2AAIzL6Q References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> From: "Scott Fluhrer (sfluhrer)" To: "Yoav Nir" , "Prashant Batra (prbatra)" X-OriginalArrivalTime: 26 Jul 2011 15:13:37.0054 (UTC) FILETIME=[97CFE3E0:01CC4BA6] Cc: ipsec@ietf.org Subject: Re: [IPsec] DH keys calculation performance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:13:39 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Yoav Nir > Sent: Tuesday, July 26, 2011 6:40 AM > To: Prashant Batra (prbatra) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] DH keys calculation performance >=20 >=20 > On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: >=20 > > Hello, > > > > The DH exchange (Calculation of Public/Private key and the Secret) in > > IKEV2 Initial exchange > > seems to be very expensive. This is slowing down the overall IKEv2 > > tunnel establishment. > > Is there a way to optimize it? >=20 > Hi Prashant. >=20 > I know of three ways to optimize the D-H exchange. >=20 > First, note that each peer has to perform two operations: >=20 > Second, note that 2^73 mod p =3D ((2^64 mod p) * (2^8 mod p) * (2^1 = mod > p)) mod p If you're using a 2048-bit D-H group, you can pre-calculate > 2^x mod p for 0<=3Dx<=3D2048 and store these values. Surely, you mean something like 0<=3Dx<320 or so. When you create a DH shared secret for a MODP group, it is pointless to create a secret as big as the prime. Against DH, there are two known types of attacks: (A) Attacks that take time based on the modulus (and don't depend on the value of the exponent at all) (B) Attacks that take time based on the exponent (and don't depend that much on the value of the modulus) What you want to do is pick your exponent just large enough that (B) attacks take about as long as (A) attacks; making the exponent any larger than that will make it more expensive for you without making it any more secure (because an attacker can just go ahead with an (A) attack); while making it smaller will make it less secure (because a (B) attack becomes easier). So, what's the size of such an exponent? Well, that's a difficult question; however, the RFC's do give guidance. If you're using a 2048 bit exponent for 2048 bit MODP group, that's an obvious thing to fix. If we look at RFC3526, we see that it suggests an exponent of length of between 220 and 320 bits (it's a range because experts have different estimates of how difficult type (A) attacks are). Also, if you're doing groups 22-24, then it's easy; use an exponent of the same size as 'q' (that'd be 160, 224 and 256 bits); a larger exponent is pointless. And, for completeness, for a ECDH group, it's also easy; use an exponent of the same size as the curve (e.g. 256 bits for the P256 curve). From ynir@checkpoint.com Tue Jul 26 08:38:23 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A5111E80C1 for ; Tue, 26 Jul 2011 08:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.482 X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiBRXiSXZXw8 for ; Tue, 26 Jul 2011 08:38:23 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A471511E812A for ; Tue, 26 Jul 2011 08:38:21 -0700 (PDT) X-CheckPoint: {4E2EED02-D-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6QFcFrg009743; Tue, 26 Jul 2011 18:38:15 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 26 Jul 2011 18:38:15 +0300 From: Yoav Nir To: "Scott Fluhrer (sfluhrer)" Date: Tue, 26 Jul 2011 18:38:13 +0300 Thread-Topic: [IPsec] DH keys calculation performance Thread-Index: AcxLqgjKhSazpSjVTXSjNW+Rwi9CYw== Message-ID: References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-9-527528605"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Prashant Batra \(prbatra\)" Subject: Re: [IPsec] DH keys calculation performance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:38:23 -0000 --Apple-Mail-9-527528605 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jul 26, 2011, at 11:13 AM, Scott Fluhrer (sfluhrer) wrote: > > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Yoav Nir >> Sent: Tuesday, July 26, 2011 6:40 AM >> To: Prashant Batra (prbatra) >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] DH keys calculation performance >> >> >> On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote: >> >>> Hello, >>> >>> The DH exchange (Calculation of Public/Private key and the Secret) > in >>> IKEV2 Initial exchange >>> seems to be very expensive. This is slowing down the overall IKEv2 >>> tunnel establishment. >>> Is there a way to optimize it? >> >> Hi Prashant. >> >> I know of three ways to optimize the D-H exchange. >> >> First, note that each peer has to perform two operations: >> >> Second, note that 2^73 mod p = ((2^64 mod p) * (2^8 mod p) * (2^1 mod >> p)) mod p If you're using a 2048-bit D-H group, you can pre-calculate >> 2^x mod p for 0<=x<=2048 and store these values. > > Surely, you mean something like 0<=x<320 or so. When you create a DH > shared secret for a MODP group, it is pointless to create a secret as > big as the prime. Against DH, there are two known types of attacks: > (A) Attacks that take time based on the modulus (and don't > depend on the value of the exponent at all) > (B) Attacks that take time based on the exponent (and don't > depend that much on the value of the modulus) > What you want to do is pick your exponent just large enough that (B) > attacks take about as long as (A) attacks; making the exponent any > larger than that will make it more expensive for you without making it > any more secure (because an attacker can just go ahead with an (A) > attack); while making it smaller will make it less secure (because a (B) > attack becomes easier). Yes. My bad. --Apple-Mail-9-527528605 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBScwggQPoAMC AQICEBW9tBlVg9WZf9zHij2h3zMwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNzIxMDAwMDAwWhcNMTIwNzIwMjM1OTU5WjAkMSIwIAYJKoZI hvcNAQkBFhN5bmlyQGNoZWNrcG9pbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxha8w2xboHPbsj9HBz/1LdG2kwp++sXC5I0izECjJRravnWdnlDqTSRx7outPOk4zkfP/jtO ZiFl35/W/ZgiVilKNrCAcIk4J4VYdbhUItos2Z1ydt1JcY6F24faWNNns2hV/cF6pNELNTxPYIsY HrVy7Cq7/oywfHQimKbL4cVZvUF34P57gZKrxKBEkw3cUAzch7bQ8pTtewjvFW+cjpDqPaFSZyGJ VfbBtAg3RBjlOolfp2VlTmLGW3gRxg9hi7XAxjJf417I9b1hz0NpTnhSr7n38zMEyUdhqr2Wb37b yFNmhF+dWeBUX/RzgdIeqO/whtI1+gH8ZNuzpAV1UQIDAQABo4IB4zCCAd8wHwYDVR0jBBgwFoAU ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFPzBjRi9Qe40hv+WSad/Om18V8HmMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEF BQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETeW5pckBjaGVj a3BvaW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAkLgfz4ztXKON97ZHaqFhBfxO3QGPhx76iB1U 9LevFF/AsfS0ap2IWzGDocGJze17FZTjM41vCpRORCKCAdek+u+6RO95zx8VQaZybicBNCGBb4LP 1h8GvtmrT/+JpdtETJp9i1KIEwn8hn9Q4aMdkk8S2QkemBmhzGXdcQ5nCxyCQHk1hcRSDhC1qfME DPGlKMxqDpMHrFmiI6vdCVBhufX7xECsGXOJDqMWMPg7YE0fubg50T8ehNHJ2Mvm8JpYIGwTIC3v V9egV4ghYxHXm6u1zbXZUD+3pV9cNKbboB1FjuVqzKIiuNnzsZ3StcasZRYaxlwaHAU4uAuNyzbN 3jGCA6swggOnAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZ VYPVmX/cx4o9od8zMAkGBSsOAwIaBQCgggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTExMDcyNjE1MzgxNFowIwYJKoZIhvcNAQkEMRYEFONQ7VFvT1HJH25qSK6B ZSOIcd1yMIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEBW9tBlVg9WZf9zHij2h3zMwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZVYPVmX/cx4o9od8zMA0GCSqGSIb3DQEBAQUA BIIBALWcyV3q5/J99sv+Jc/bYaE1Y9sKUfOmz0q3ye0CSwEriE1JhOev3EPUW4MQOlbXEazYuC8u KEz7KCyqLjlXKu5/fHNbvalMPJc+5KpsC2z402m1oghbsU6JOtBVagwpLZ5YaVfa5oN14KO+QL5w Rsk+0nO5Dad4latjZzRy+nWRbBQ7X55FKPSoRzp56Ce01UhwWzgG602mngTAU2JHZBHrPmSbFglF 9dm2u6O5umUAuMLIARnKelNbd5Pz5KQrRXzRSsg2ewbQrgG2LDfKplU0TRYz/AGWwA6IEQdh/0IU 8mL3GpI27EFEIU4NNZVLF7HjR63c5DG6WkM8acABJDgAAAAAAAA= --Apple-Mail-9-527528605-- From hugokraw@gmail.com Tue Jul 26 08:59:41 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B00911E80EC for ; Tue, 26 Jul 2011 08:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drTiI2xOmKGR for ; Tue, 26 Jul 2011 08:59:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B202B11E808E for ; Tue, 26 Jul 2011 08:59:34 -0700 (PDT) Received: by vws12 with SMTP id 12so534639vws.31 for ; Tue, 26 Jul 2011 08:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=RpnQ1x54p91YctjqJhGMUvqKgkxPTYRNaSjs4ZwnZtQ=; b=bT6CChanwlcTZVuI4VzoDpIhIBJEevCqkQIZ6OZ39GHuU+BAdGlUUi043rNrrDAgcD 1ZTU7FYv5zEN+Hc55nTi6OyXB9wEP/AKxfK4fnL+NG3qa/18S3wmVUvujqPVEN4bFtlL JFtyoRCqFfngJvNbiSZb22EAkz+kSjVkMLD1A= Received: by 10.52.93.65 with SMTP id cs1mr6073443vdb.444.1311695974094; Tue, 26 Jul 2011 08:59:34 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.52.159.4 with HTTP; Tue, 26 Jul 2011 08:59:14 -0700 (PDT) In-Reply-To: References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> From: Hugo Krawczyk Date: Tue, 26 Jul 2011 11:59:14 -0400 X-Google-Sender-Auth: 91HCxGFAGKjXH1aT9qemdnzraIk Message-ID: To: Dan Harkins Content-Type: multipart/alternative; boundary=bcaec501649796d6e704a8fb046d Cc: ipsec@ietf.org, Yoav Nir , "Prashant Batra \(prbatra\)" Subject: Re: [IPsec] DH keys calculation performance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:59:41 -0000 --bcaec501649796d6e704a8fb046d Content-Type: text/plain; charset=UTF-8 Regarding Dan's suggestion (*) of using g^x, g^{x+1}, etc as successive DH values, I would like to note the following. This would lead to situations where two parties exchange successive keys of the form g^{xy} and g^{(x+1)(y+1)}=g^{xy}*g^x*g^y*g. In this case, if an attacker learns the key g^{xy} it also learns the next key, something that violates key-exchange security (i.e. security against "known key attacks"). However, if one models the key derivation function applied to g^{xy} as a random oracle then this usage is probably ok (I did not prove it), assuming the attacker does not have access to g^{xy} before hashing. This is a weaker security property than the one achieved by always choosing x and y afresh (in which case we have proof of security without resorting to random oracle assumptions and without assuming that the attacker never gets to see g^{xy}). In a performance-vs-security tradeoff one may choose to use this method, but one should be aware that there is a trade-off here. Hugo (*) I am not blaming Dan. I actually suggested that trick in my 1995 SKEME paper as a way to improve over the suggestion of re-using the same exponent in multiple exchanges as proposed at the time in the Photuris protocol. It indeed improved over Photuris but today I would be more careful about suggesting that. On Tue, Jul 26, 2011 at 10:55 AM, Dan Harkins wrote: > > Hello, > > On Tue, July 26, 2011 6:03 am, Prashant Batra (prbatra) wrote: > > Thanks Yoav and Yaron for the suggestions. > > > > Even I was thinking and tried generating and storing the key pair well > > in the beginning,. This helped to some extent. > > > > > > > > The secret calculation is also very expensive, but this has to be done > > in midst of the exchange only. > > You could pick one secret x and then for IKE exchanges do this: > > 0th exchange: y = g^x mod p > 1st exchange: y = g^(x+1) mod p > 2nd exchange: y = g^(x+2) mod p > . > . > . > nth exchange: y = g^(x+n) mod p > > Getting from exchange i to exchange i+1, then, is just a single modular > multiply, which should be "cheaper" for you. > > Knowing n, y, g and p and that y = g^(x+n) mod p does not really give > an advantage (above the discrete logarithm problem) in finding x. That > said, I still would not suggest doing many more than a few of these (and > I am not qualified to quantify that statement) but for a few-- i.e. keep > n small and after n choose a new x and repeat-- it should be OK. > > Maybe this technique will allow you to "cheapen" your exchange a bit. > I think throwing hardware at this problem is your best bet though. > > regards, > > Dan. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --bcaec501649796d6e704a8fb046d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Regarding Dan's suggestion (*) of using g^x, g^{x+1}, etc as successive= DH values, I would like to note the following.

This would lead to s= ituations where two parties exchange successive keys of the form g^{xy} and= g^{(x+1)(y+1)}=3Dg^{xy}*g^x*g^y*g.
In this case, if an attacker learns the key g^{xy} it also learns the next = key, something that violates key-exchange security (i.e. security against &= quot;known key attacks"). However, if one models the key derivation fu= nction applied to g^{xy} as a random oracle then this usage is probably ok = (I did not prove it), assuming the attacker does not have access to g^{xy} = before hashing. This is a weaker security property than the one achieved by= always choosing x and y afresh (in which case we have proof of security wi= thout resorting to random oracle assumptions and without assuming that the = attacker never gets to see g^{xy}).

In a performance-vs-security tradeoff one may choose to use this method= , but one should be aware that there is a trade-off here.

Hugo
(*) I am not blaming Dan. I actually suggested that trick in my 1995 SKEM= E paper as a way to improve over the suggestion of re-using the same expone= nt in multiple exchanges as proposed at the time in the Photuris protocol. = It indeed improved over Photuris but today I would be more careful about su= ggesting that.

On Tue, Jul 26, 2011 at 10:55 AM, Dan Harkin= s <dharkins@lou= nge.org> wrote:

=C2=A0Hello,

On Tue, July 26, 2011 6:03 am, Prashant Batra (prbatra) wrote:
> Thanks Yoav and Yaron =C2=A0for the suggestions.
>
> Even I was thinking and tried generating and storing the key pair =C2= =A0well
> in the beginning,. =C2=A0This helped to some extent.
>
>
>
> The secret calculation is also very expensive, but this has to be done=
> in midst of the exchange only.

=C2=A0You could pick one secret x and then for IKE exchanges do this= :

0th exchange: y =3D g^x mod p
1st exchange: y =3D g^(x+1) mod p
2nd exchange: y =3D g^(x+2) mod p
.
.
.
nth exchange: y =3D g^(x+n) mod p

Getting from exchange i to exchange i+1, then, is just a single modular
multiply, which should be "cheaper" for you.

=C2=A0Knowing n, y, g and p and that y =3D g^(x+n) mod p does not really g= ive
an advantage (above the discrete logarithm problem) in finding x. That
said, I still would not suggest doing many more than a few of these (and I am not qualified to quantify that statement) but for a few-- i.e. keep n small and after n choose a new x and repeat-- it should be OK.

=C2=A0Maybe this technique will allow you to "cheapen" your exch= ange a bit.
I think throwing hardware at this problem is your best bet though.

=C2=A0regards,

=C2=A0Dan.


_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--bcaec501649796d6e704a8fb046d-- From ynir@checkpoint.com Wed Jul 27 08:14:23 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB40321F86DC for ; Wed, 27 Jul 2011 08:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.5 X-Spam-Level: X-Spam-Status: No, score=-10.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Duo1QT9GEYSR for ; Wed, 27 Jul 2011 08:14:23 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8299721F86D7 for ; Wed, 27 Jul 2011 08:14:22 -0700 (PDT) X-CheckPoint: {4E3038D7-8-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6RFDCIF006531; Wed, 27 Jul 2011 18:13:20 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 27 Jul 2011 18:13:12 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 27 Jul 2011 18:13:11 +0300 From: Yoav Nir To: Yaron Sheffer Date: Wed, 27 Jul 2011 18:13:08 +0300 Thread-Topic: [IPsec] IPsecme WG: a quick update Thread-Index: AcxMb7Ns/ZzfkFtkRA2+D8P3YTMmLQ== Message-ID: <2F9687A2-0B91-4538-A134-040C63694132@checkpoint.com> References: <4E2EA4BF.4040005@gmail.com> <984CD17A-3636-4DAF-AF4C-B40A8DD884AC@vpnc.org> <4E2EC467.2010108@gmail.com> In-Reply-To: <4E2EC467.2010108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Qin Wu Subject: Re: [IPsec] IPsecme WG: a quick update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:14:24 -0000 Alright, here's one. http://tools.ietf.org/html/draft-nir-ipsecme-erx-01 defines an extension to= IKEv2 so that ERX (as defined by the HOKEY group) can be used with IKEv2. This will allow a seamless transfer from a local network protected by 802.1= x to a public network where your access needs to be protected by IPsec. (th= ink leaving the building, and your phone or tablet remains "on-line") I don't know if Qin and I count as "multiple participants" or "several peop= le", but we definitely have "different affiliations", and there are open is= sues with this draft that we think should be discussed by the larger audien= ce available in a working group. If others are interested in this activity, I will make a short presentation= about this at Hokey tomorrow. I would have presented at IPSecME, but as Ya= ron said, we are not meeting this week. Yoav On Jul 26, 2011, at 9:43 AM, Yaron Sheffer wrote: > Hi, >=20 > The working group recently published its last chartered deliverable, RFC= =20 > 6311 (HA Protocol). We would like to use this opportunity to thank the=20 > authors. >=20 > The group has not met for the last few IETF meetings, and will not meet=20 > this week in Quebec City. The current charter=20 > (http://tools.ietf.org/wg/ipsecme/charters) is set to auto-expire by=20 > 2/2012, which means the group is now officially going into hibernation,=20 > and will disband in February unless we have a new charter before that dat= e. >=20 > If you have a work item that you believe will be of interest to multiple= =20 > WG participants, you will need to raise it on the mailing list and to=20 > get enough group support to explicitly add it to the charter. You will=20 > need to convince the chairs and ADs that several people with different=20 > affiliations are committed to contribute to the work item. Otherwise,=20 > the alternative document streams (Independent or Individual) are your=20 > best bet. >=20 > We are open to suggestions for new work items, but are not actively=20 > trying to keep the WG open. Any proposals would need to come with=20 > commitments from more than just one or two people to work on them. >=20 > Thanks, >=20 > Paul and Yaron From iesg-secretary@ietf.org Wed Jul 27 09:44:59 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D010421F8A4D; Wed, 27 Jul 2011 09:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt-5mcqEkPeF; Wed, 27 Jul 2011 09:44:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E0321F8A4E; Wed, 27 Jul 2011 09:44:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> Date: Wed, 27 Jul 2011 09:44:59 -0700 Cc: ipsec@ietf.org Subject: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:45:00 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'Secure Password Framework for IKEv2' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document creates a generic way for Internet Key Exchange (IKEv2) to use any of the symmetric secure password authentication methods. There are multiple methods already specified in other documents and this document does not add new one. This document specifies a common way so those methods can agree on which method is to be used in current connection. This document also provides a common way to transmit secure password authentication method specific payloads between peers. The file can be obtained via http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-secure-password-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-secure-password-framework/ No IPR declarations have been submitted directly on this I-D. From ynir@checkpoint.com Wed Jul 27 15:30:49 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB195E8001; Wed, 27 Jul 2011 15:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.602 X-Spam-Level: X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, LONGWORDS=1.803, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQnI8FvuzZ6I; Wed, 27 Jul 2011 15:30:49 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32F5E8004; Wed, 27 Jul 2011 15:30:48 -0700 (PDT) X-CheckPoint: {4E309F26-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6RMUh9w014193; Thu, 28 Jul 2011 01:30:43 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 28 Jul 2011 01:30:43 +0300 From: Yoav Nir To: "ietf@ietf.org" Date: Thu, 28 Jul 2011 01:30:41 +0300 Thread-Topic: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC Thread-Index: AcxMrNHXPdtMuzSzQVqEtsADz3B5Iw== Message-ID: <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> In-Reply-To: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:30:49 -0000 I think this is a terrible idea.=20 IKEv2 has a way for mutual authentication with a shared key. A concern was raised that this method was vulnerable to guessing if trivial= shared keys were configured. There were several proposals for a better cryptographic method. The IPsecME working group failed to choose between them. This is not so sur= prising, because most participants are engineers, not cryptographers. Even = those with some cryptographic background stayed silent because choosing bet= ween several cryptographic protocols is hard. IETF last calls and the IESG = did not help much either. This draft represents a total shirking of our responsibility. Rather than d= ecide on one protocol that is "best" or even arbitrarily choosing one that = is "good enough", it proposes to build a framework so that everyone and the= ir dog can have their own method. This is a nightmare for developers: since= you can't know what method the peer will support, you have to implement al= l of them.=20 If this had been a hierarchical organization, some manager would decide whi= ch of the methods gets developed (or published) and the others would be rel= egated to the recycle bin. The IETF is not like that and we seek to reach consensus. That's a good thi= ng, but this time it's leading us to a really bad solution for interoperabi= lity, and a really bad solution for implementers.=20 I am opposed to this draft. Yoav On Jul 27, 2011, at 12:44 PM, The IESG wrote: >=20 > The IESG has received a request from an individual submitter to consider > the following document: > - 'Secure Password Framework for IKEv2' > as an > Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-08-24. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document creates a generic way for Internet Key Exchange (IKEv2) > to use any of the symmetric secure password authentication methods. > There are multiple methods already specified in other documents and > this document does not add new one. This document specifies a common > way so those methods can agree on which method is to be used in > current connection. This document also provides a common way to > transmit secure password authentication method specific payloads > between peers. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-secure-password-fra= mework/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-secure-password-fra= mework/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. From kivinen@iki.fi Wed Jul 27 15:52:37 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BE011E8092; Wed, 27 Jul 2011 15:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LHmbwWtFc5P; Wed, 27 Jul 2011 15:52:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D8611E8084; Wed, 27 Jul 2011 15:52:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p6RMqOaf004834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jul 2011 01:52:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p6RMqOnp025098; Thu, 28 Jul 2011 01:52:24 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20016.38567.974476.933647@fireball.kivinen.iki.fi> Date: Thu, 28 Jul 2011 01:52:23 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: IPsecme WG , "ietf@ietf.org" Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:52:38 -0000 Yoav Nir writes: > This draft represents a total shirking of our responsibility. Rather > than decide on one protocol that is "best" or even arbitrarily > choosing one that is "good enough", it proposes to build a framework > so that everyone and their dog can have their own method. This is a > nightmare for developers: since you can't know what method the peer > will support, you have to implement all of them. Partially yes, but unfortunately all of the authors of those actual protocols decided that they wanted to continue publishing those drafts as individual RFCs, and each of them used different way to negotiate them, so there was no way to even implement multiple of them. At least this drafts gives you that option to implement multiple of them if you want. This draft only provides instructions for those other draft authors so they can at least common methods to negotiate the feature and use common method to trasmit data between peers. -- kivinen@iki.fi From paul.hoffman@vpnc.org Wed Jul 27 17:12:54 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A73E11E80BF; Wed, 27 Jul 2011 17:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.698 X-Spam-Level: X-Spam-Status: No, score=-101.698 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, LONGWORDS=1.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMdg7fSHOKYO; Wed, 27 Jul 2011 17:12:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC7521F8BA1; Wed, 27 Jul 2011 17:12:53 -0700 (PDT) Received: from dhcp-2121.meeting.ietf.org (dhcp-2121.meeting.ietf.org [130.129.33.33]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6S0CYeF098610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jul 2011 17:12:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> Date: Wed, 27 Jul 2011 20:12:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> To: IPsecme WG X-Mailer: Apple Mail (2.1084) Cc: IETF-Discussion list Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 00:12:54 -0000 On Jul 27, 2011, at 6:30 PM, Yoav Nir wrote: > I think this is a terrible idea.=20 +.5. I think is is a bad idea. > IKEv2 has a way for mutual authentication with a shared key. >=20 > A concern was raised that this method was vulnerable to guessing if = trivial shared keys were configured. >=20 > There were several proposals for a better cryptographic method. >=20 > The IPsecME working group failed to choose between them. This is not = so surprising, because most participants are engineers, not = cryptographers. Even those with some cryptographic background stayed = silent because choosing between several cryptographic protocols is hard. = IETF last calls and the IESG did not help much either. >=20 > This draft represents a total shirking of our responsibility. +.5. I think think it represents a shirking of our leadership's = responsibility. Our leadership said that they would deal with the issue = if the WG could not come to consensus, and the WG could not come to = consensus. Adding a layer of indirection that is mostly transparent is = not dealing with it. > Rather than decide on one protocol that is "best" or even arbitrarily = choosing one that is "good enough", it proposes to build a framework so = that everyone and their dog can have their own method. This is a = nightmare for developers: since you can't know what method the peer will = support, you have to implement all of them.=20 >=20 > If this had been a hierarchical organization, some manager would = decide which of the methods gets developed (or published) and the others = would be relegated to the recycle bin. >=20 > The IETF is not like that and we seek to reach consensus. That's a = good thing, but this time it's leading us to a really bad solution for = interoperability, and a really bad solution for implementers.=20 >=20 > I am opposed to this draft. +1 On Jul 27, 2011, at 6:52 PM, Tero Kivinen wrote: > Yoav Nir writes: >> This draft represents a total shirking of our responsibility. Rather >> than decide on one protocol that is "best" or even arbitrarily >> choosing one that is "good enough", it proposes to build a framework >> so that everyone and their dog can have their own method. This is a >> nightmare for developers: since you can't know what method the peer >> will support, you have to implement all of them. =20 >=20 > Partially yes, but unfortunately all of the authors of those actual > protocols decided that they wanted to continue publishing those drafts > as individual RFCs, and each of them used different way to negotiate > them, so there was no way to even implement multiple of them. Is this true? Because each has it's own way to negotiate its use, one = should be able to implement multiple of the competing proposals as-is, = yes? > At least this drafts gives you that option to implement multiple of > them if you want. This draft only provides instructions for those > other draft authors so they can at least common methods to negotiate > the feature and use common method to trasmit data between peers. True, but it is still punting the problem of us having just one. --Paul Hoffman From dharkins@lounge.org Wed Jul 27 22:02:40 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693E021F85C4; Wed, 27 Jul 2011 22:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaXObg4BzPnT; Wed, 27 Jul 2011 22:02:39 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id C049E21F856D; Wed, 27 Jul 2011 22:02:39 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 723ECA88810C; Wed, 27 Jul 2011 22:02:39 -0700 (PDT) Received: from 70.25.120.2 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 27 Jul 2011 22:02:39 -0700 (PDT) Message-ID: <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> In-Reply-To: <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> Date: Wed, 27 Jul 2011 22:02:39 -0700 (PDT) From: "Dan Harkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , IETF-Discussion list Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 05:02:40 -0000 Paul, The existence of this draft shows a failure of YOUR leadership (and that of your co-chairman) of the working group. Consensus was achieved to add an authentication method based on a simple password yet you seemingly worked to do everything possible to create division in the working group and then stepped in to declare failure because no consensus existed. We could've had a single standards-track solution to this problem over a year ago if you had treated the singular draft used to argue for addition of this work to the charter in the same way that you treated the singular draft used to argue for addition of "EAP only" authentication to the charter. The latter (authored by one of the chairmen) was advanced to standards track after receiving a whopping ZERO comments from the WG and the former was killed by the chairmen because the only comments on the list were from authors of competing drafts (after manufacturing the competition in the first place). There was hostility by the IPsecME chairmen to this work item from the beginning and you worked to ensure its failure in the WG. Now you're against advancement of Tero's draft to forge the best possible outcome now? Not a surprise! Put that hat back on, along with a sackcloth and ashes, and say "mea culpa". Dan. On Wed, July 27, 2011 5:12 pm, Paul Hoffman wrote: > > > On Jul 27, 2011, at 6:30 PM, Yoav Nir wrote: > >> I think this is a terrible idea. > > +.5. I think is is a bad idea. > >> IKEv2 has a way for mutual authentication with a shared key. >> >> A concern was raised that this method was vulnerable to guessing if >> trivial shared keys were configured. >> >> There were several proposals for a better cryptographic method. >> >> The IPsecME working group failed to choose between them. This is not so >> surprising, because most participants are engineers, not cryptographers. >> Even those with some cryptographic background stayed silent because >> choosing between several cryptographic protocols is hard. IETF last >> calls and the IESG did not help much either. >> >> This draft represents a total shirking of our responsibility. > > +.5. I think think it represents a shirking of our leadership's > responsibility. Our leadership said that they would deal with the issue if > the WG could not come to consensus, and the WG could not come to > consensus. Adding a layer of indirection that is mostly transparent is not > dealing with it. > >> Rather than decide on one protocol that is "best" or even arbitrarily >> choosing one that is "good enough", it proposes to build a framework so >> that everyone and their dog can have their own method. This is a >> nightmare for developers: since you can't know what method the peer will >> support, you have to implement all of them. >> >> If this had been a hierarchical organization, some manager would decide >> which of the methods gets developed (or published) and the others would >> be relegated to the recycle bin. >> >> The IETF is not like that and we seek to reach consensus. That's a good >> thing, but this time it's leading us to a really bad solution for >> interoperability, and a really bad solution for implementers. >> >> I am opposed to this draft. > > +1 > > > On Jul 27, 2011, at 6:52 PM, Tero Kivinen wrote: > >> Yoav Nir writes: >>> This draft represents a total shirking of our responsibility. Rather >>> than decide on one protocol that is "best" or even arbitrarily >>> choosing one that is "good enough", it proposes to build a framework >>> so that everyone and their dog can have their own method. This is a >>> nightmare for developers: since you can't know what method the peer >>> will support, you have to implement all of them. >> >> Partially yes, but unfortunately all of the authors of those actual >> protocols decided that they wanted to continue publishing those drafts >> as individual RFCs, and each of them used different way to negotiate >> them, so there was no way to even implement multiple of them. > > Is this true? Because each has it's own way to negotiate its use, one > should be able to implement multiple of the competing proposals as-is, > yes? > >> At least this drafts gives you that option to implement multiple of >> them if you want. This draft only provides instructions for those >> other draft authors so they can at least common methods to negotiate >> the feature and use common method to trasmit data between peers. > > True, but it is still punting the problem of us having just one. > > --Paul Hoffman > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf.ietf@gmail.com Wed Jul 27 22:50:10 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BC611E80A4; Wed, 27 Jul 2011 22:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h35RoRmOZSe; Wed, 27 Jul 2011 22:50:10 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 588DD11E8089; Wed, 27 Jul 2011 22:50:09 -0700 (PDT) Received: by wwe5 with SMTP id 5so1403995wwe.13 for ; Wed, 27 Jul 2011 22:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wFi8IvUotghE83t2Kb6ntbjZ+u8mlcxIh6gaASdcGzM=; b=YiUEVEfVwk4SzbEaEH1+AKB+QjJT3p7FncZGL886G2ebytXFVUNF2CJPmJ9W4WUgNd oGsIrbxzyZGTAGWslkhqR3GixritEQj7n9H26/bYSvSa69F0VatfQMsO8j35FhoTeoV9 6Hnz9CPKOSkd6xS5QLpmpMBU5oU4IO3zrD5HA= Received: by 10.227.175.139 with SMTP id ba11mr880864wbb.23.1311832208382; Wed, 27 Jul 2011 22:50:08 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-179-237-205.red.bezeqint.net [79.179.237.205]) by mx.google.com with ESMTPS id fr7sm511121wbb.56.2011.07.27.22.50.05 (version=SSLv3 cipher=OTHER); Wed, 27 Jul 2011 22:50:07 -0700 (PDT) Message-ID: <4E30F876.70200@gmail.com> Date: Thu, 28 Jul 2011 08:49:42 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Dan Harkins References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> In-Reply-To: <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman , IETF-Discussion list Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 05:50:10 -0000 Unfortunately Dan cannot accept that there may be objective, non political reasons for the group not to adopt his work. Which is the reason why three alternative proposals were published several months after his proposed PAKE solution. As co-chairmen of ipsecme, Paul and I did our best to get the group to agree on a single solution, to the point where we both supported Dan's criteria for selecting such a solution. Unfortunately we failed: while the group supported a PAKE in IKEv2 "in the abstract", there was not enough energy to pick a single protocol for this purpose. Back to the matter at hand: I am opposed to draft-kivinen-ipsecme-secure-password-framework. It has served its purpose when two of the proposals were changed to add method negotiation, and thus enable IKE peers to implement none, one or more of these methods. I believe the other justifications for this draft, including the preservation of IANA IKEv2 namespaces, are bogus. Adopting the rest of the framework would be a useless exercise. Personally, given that all three current proposals are being advanced as Experimental outside the WG, I would argue that we are wasting far too much energy on this grand unified framework. And this includes the current mail exchange. Thanks, Yaron On 28.7.2011 08:02, Dan Harkins wrote: > Paul, > > The existence of this draft shows a failure of YOUR leadership (and > that of your co-chairman) of the working group. Consensus was achieved > to add an authentication method based on a simple password yet you > seemingly worked to do everything possible to create division in the > working group and then stepped in to declare failure because no > consensus existed. > > We could've had a single standards-track solution to this problem over a > year ago if you had treated the singular draft used to argue for addition > of this work to the charter in the same way that you treated the singular > draft used to argue for addition of "EAP only" authentication to the > charter. The latter (authored by one of the chairmen) was advanced to > standards track after receiving a whopping ZERO comments from the WG and > the former was killed by the chairmen because the only comments on the > list were from authors of competing drafts (after manufacturing the > competition in the first place). > > There was hostility by the IPsecME chairmen to this work item from > the beginning and you worked to ensure its failure in the WG. Now you're > against advancement of Tero's draft to forge the best possible outcome > now? Not a surprise! > > Put that hat back on, along with a sackcloth and ashes, and say "mea > culpa". > > Dan. > > On Wed, July 27, 2011 5:12 pm, Paul Hoffman wrote: >> >> >> On Jul 27, 2011, at 6:30 PM, Yoav Nir wrote: >> >>> I think this is a terrible idea. >> +.5. I think is is a bad idea. >> >>> IKEv2 has a way for mutual authentication with a shared key. >>> >>> A concern was raised that this method was vulnerable to guessing if >>> trivial shared keys were configured. >>> >>> There were several proposals for a better cryptographic method. >>> >>> The IPsecME working group failed to choose between them. This is not so >>> surprising, because most participants are engineers, not cryptographers. >>> Even those with some cryptographic background stayed silent because >>> choosing between several cryptographic protocols is hard. IETF last >>> calls and the IESG did not help much either. >>> >>> This draft represents a total shirking of our responsibility. >> +.5. I think think it represents a shirking of our leadership's >> responsibility. Our leadership said that they would deal with the issue if >> the WG could not come to consensus, and the WG could not come to >> consensus. Adding a layer of indirection that is mostly transparent is not >> dealing with it. >> >>> Rather than decide on one protocol that is "best" or even arbitrarily >>> choosing one that is "good enough", it proposes to build a framework so >>> that everyone and their dog can have their own method. This is a >>> nightmare for developers: since you can't know what method the peer will >>> support, you have to implement all of them. >>> >>> If this had been a hierarchical organization, some manager would decide >>> which of the methods gets developed (or published) and the others would >>> be relegated to the recycle bin. >>> >>> The IETF is not like that and we seek to reach consensus. That's a good >>> thing, but this time it's leading us to a really bad solution for >>> interoperability, and a really bad solution for implementers. >>> >>> I am opposed to this draft. >> +1 >> >> >> On Jul 27, 2011, at 6:52 PM, Tero Kivinen wrote: >> >>> Yoav Nir writes: >>>> This draft represents a total shirking of our responsibility. Rather >>>> than decide on one protocol that is "best" or even arbitrarily >>>> choosing one that is "good enough", it proposes to build a framework >>>> so that everyone and their dog can have their own method. This is a >>>> nightmare for developers: since you can't know what method the peer >>>> will support, you have to implement all of them. >>> Partially yes, but unfortunately all of the authors of those actual >>> protocols decided that they wanted to continue publishing those drafts >>> as individual RFCs, and each of them used different way to negotiate >>> them, so there was no way to even implement multiple of them. >> Is this true? Because each has it's own way to negotiate its use, one >> should be able to implement multiple of the competing proposals as-is, >> yes? >> >>> At least this drafts gives you that option to implement multiple of >>> them if you want. This draft only provides instructions for those >>> other draft authors so they can at least common methods to negotiate >>> the feature and use common method to trasmit data between peers. >> True, but it is still punting the problem of us having just one. >> >> --Paul Hoffman >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From dharkins@lounge.org Thu Jul 28 05:48:42 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D675521F8BD6 for ; Thu, 28 Jul 2011 05:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyut6npCzQ3i for ; Thu, 28 Jul 2011 05:48:42 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 60C5F21F86E6 for ; Thu, 28 Jul 2011 05:48:42 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0E307A88810C; Thu, 28 Jul 2011 05:48:42 -0700 (PDT) Received: from 130.129.19.17 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 28 Jul 2011 05:48:42 -0700 (PDT) Message-ID: In-Reply-To: <4E30F876.70200@gmail.com> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> Date: Thu, 28 Jul 2011 05:48:42 -0700 (PDT) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 12:48:42 -0000 On Wed, July 27, 2011 10:49 pm, Yaron Sheffer wrote: > Unfortunately Dan cannot accept that there may be objective, non > political reasons for the group not to adopt his work. Which is the > reason why three alternative proposals were published several months > after his proposed PAKE solution. Well there certainly wasn't a technical reason. In fact, after delaying things for several months what we ended up with were 3 drafts that were effectively _identical_ from a technical point of view. That is the prime reason that the group (and later the AD) could not agree on which one to choose. > As co-chairmen of ipsecme, Paul and I did our best to get the group to > agree on a single solution, to the point where we both supported Dan's > criteria for selecting such a solution. Unfortunately we failed: while > the group supported a PAKE in IKEv2 "in the abstract", there was not > enough energy to pick a single protocol for this purpose. You are on the record opposing PAKE from the start. It seems that your "best" is best exemplified by your treatment of your own draft which whisked through the group on to the standards track with no working group input or, apparently, interest. PAKE got delayed (by you) and ultimately killed for lack of interest even though there were emails on the list discussing the 3 drafts. > Back to the matter at hand: I am opposed to > draft-kivinen-ipsecme-secure-password-framework. It has served its > purpose when two of the proposals were changed to add method > negotiation, and thus enable IKE peers to implement none, one or more of > these methods. I believe the other justifications for this draft, > including the preservation of IANA IKEv2 namespaces, are bogus. Adopting > the rest of the framework would be a useless exercise. Speaking as an implementer, this is not a useless exercise. If one must implement > 1 of these PAKE schemes having them inside of this framework simplifies things. > Personally, given that all three current proposals are being advanced as > Experimental outside the WG, I would argue that we are wasting far too > much energy on this grand unified framework. And this includes the > current mail exchange. Then don't update your draft! Let it expire and go where dead drafts go. Dan. From kivinen@iki.fi Thu Jul 28 07:11:11 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C79F21F8C77; Thu, 28 Jul 2011 07:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sAEfkjkw80z; Thu, 28 Jul 2011 07:11:10 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302B721F8C75; Thu, 28 Jul 2011 07:11:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p6SEB0xk008991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jul 2011 17:11:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p6SEAxEF000678; Thu, 28 Jul 2011 17:10:59 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20017.28147.864891.493584@fireball.kivinen.iki.fi> Date: Thu, 28 Jul 2011 17:10:59 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 21 min Cc: IPsecme WG , IETF-Discussion list Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:11:11 -0000 Paul Hoffman writes: > > Partially yes, but unfortunately all of the authors of those actual > > protocols decided that they wanted to continue publishing those drafts > > as individual RFCs, and each of them used different way to negotiate > > them, so there was no way to even implement multiple of them. > > Is this true? Because each has it's own way to negotiate its use, > one should be able to implement multiple of the competing proposals > as-is, yes? Before I proposed my common way to negotiate only one of the proposed protocols included any kind of support for indicating which version is used. The other two just assumed that initiator selects the method and responder supports it without any negotiation, meaning there was no way to make initiator version which supports multiple methods without trying the first method, if that failed, then starting IKE_SA_INIT from the beginning and trying second method etc... This has already been changing as one of the drafts is already changed to support what I have described in my draft, and another author has said he will update his. The third one already had negotiation altough done bit differently to compared what I proposed. As an implementor I myself I want to keep this problem concentrated in my code, meaning I do not want to make three completely differently done implementations for the same thing, when I can instead make generic changes to common code once, and separate the secure password method related processing in one module taking care as any methods needed to be implemented. > > At least this drafts gives you that option to implement multiple of > > them if you want. This draft only provides instructions for those > > other draft authors so they can at least common methods to negotiate > > the feature and use common method to trasmit data between peers. > > True, but it is still punting the problem of us having just one. Yes, but there is nothing I can do to that. I cannot fix the problem that all 3 drafts were sent forward and most likely will be published. If someone will decided only one of them will go forward (and there will not be any other ever) then my draft will be mostly unneeded as all of my draft can be put inside that one protocol draft going forward just like draft-shin-augmented-pake has already done. If there is no need to make sure multiple drafts make the negotiation and common payload things similarly as there is only one draft, then this draft is not needed. I am also the IANA expert for the IKEv2 registries, and that was the main reason I wanted to have common way to do things instead of doing dozen new allocations to the registries just to support 3 bit different ways to do same thing (when 3 allocations is enough). I wanted to point this out to the draft authors as early as possible, so it will not come as suprise to the authors that I do not support their way of allocating that many codepoints from the registries. -- kivinen@iki.fi From kivinen@iki.fi Thu Jul 28 07:27:43 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF3B21F8BD9; Thu, 28 Jul 2011 07:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EqdEGcouVJI; Thu, 28 Jul 2011 07:27:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9741021F8BDA; Thu, 28 Jul 2011 07:27:42 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p6SERcI4009247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jul 2011 17:27:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p6SERbqJ017233; Thu, 28 Jul 2011 17:27:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20017.29145.171495.225683@fireball.kivinen.iki.fi> Date: Thu, 28 Jul 2011 17:27:37 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <4E30F876.70200@gmail.com> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 11 min Cc: IPsecme WG , IETF-Discussion list , Dan Harkins , Paul Hoffman Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:27:43 -0000 Yaron Sheffer writes: > Back to the matter at hand: I am opposed to > draft-kivinen-ipsecme-secure-password-framework. It has served its > purpose when two of the proposals were changed to add method > negotiation, and thus enable IKE peers to implement none, one or more of > these methods. Actually there is currently only one draft, draft-shin-augmented-pake, which follows my negotiation process. The draft-harkins-ipsecme-spsk-auth author did say he is going to change his draft, but the draft is not yet there, and then there is draft-kuegler-ipsecme-pace-ikev2 (which you are co-author) which is doing negotiation differently and I do not know whether that is going to change to use same way than others. > I believe the other justifications for this draft, including the > preservation of IANA IKEv2 namespaces, are bogus. As an IANA Expert for the registries in question I strongly disagree. If you want to delay this fight to the IANA allocation time, that is fine by me, but I will point it out already now that I will be against allocating separate code points for each protocol as there is no need for that. > Adopting the rest of the framework would be a useless exercise. Keeping the IANA registries clean is important for me, in addition to make it easy to implement multiple methods in the same implementation. I do not consider them as useless resons. Especially as it only causes very small changes to the actual protocol drafts (I would expect less than an one hour of work). -- kivinen@iki.fi From darnold@stoke.com Wed Jul 27 23:07:56 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF59321F8AD3 for ; Wed, 27 Jul 2011 23:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPrq2hGXVeIy for ; Wed, 27 Jul 2011 23:07:55 -0700 (PDT) Received: from mail1.stoke.com (trio.stoke.com [209.78.40.112]) by ietfa.amsl.com (Postfix) with ESMTP id A53F211E80BD for ; Wed, 27 Jul 2011 23:07:55 -0700 (PDT) X-ASG-Debug-ID: 1311833267-014de25961c3070001-2ho77O Received: from minsk.us.stoke.com ([172.16.4.20]) by mail1.stoke.com with ESMTP id XTJE3UrY0OKyNJ95; Wed, 27 Jul 2011 23:07:47 -0700 (PDT) X-Barracuda-Envelope-From: darnold@stoke.com X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2011 23:07:45 -0700 X-ASG-Orig-Subj: RE: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC Message-ID: In-Reply-To: <4E30F876.70200@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC Thread-Index: AcxM6qzqPnlpe9cQSAOwbK1k1xNBfAAAfnkQ References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com><7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com><78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org><7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> From: "David Arnold" To: "Yaron Sheffer" , "Dan Harkins" X-Barracuda-Connect: UNKNOWN[172.16.4.20] X-Barracuda-Start-Time: 1311833267 X-Barracuda-URL: http://mail1.stoke.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at stoke.com X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.70184 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Mailman-Approved-At: Thu, 28 Jul 2011 08:07:35 -0700 Cc: IPsecme WG , Paul Hoffman , IETF-Discussion list Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 06:22:20 -0000 Well said David J. Arnold=A0- VP, Engineering T: 408.855.2969=A0=A0M:=A0707.703.9077=A0=A0F: 408.855.2978=A0=A0 SERVICES WITHOUT BOUNDARIES=20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Yaron Sheffer Sent: Wednesday, July 27, 2011 10:50 PM To: Dan Harkins Cc: IPsecme WG; Paul Hoffman; IETF-Discussion list Subject: Re: [IPsec] Last Call: = (Secure = Password Framework for IKEv2) to Informational RFC Unfortunately Dan cannot accept that there may be objective, non = political reasons for the group not to adopt his work. Which is the = reason why three alternative proposals were published several months = after his proposed PAKE solution. As co-chairmen of ipsecme, Paul and I did our best to get the group to = agree on a single solution, to the point where we both supported Dan's = criteria for selecting such a solution. Unfortunately we failed: while = the group supported a PAKE in IKEv2 "in the abstract", there was not = enough energy to pick a single protocol for this purpose. Back to the matter at hand: I am opposed to = draft-kivinen-ipsecme-secure-password-framework. It has served its = purpose when two of the proposals were changed to add method = negotiation, and thus enable IKE peers to implement none, one or more of = these methods. I believe the other justifications for this draft, = including the preservation of IANA IKEv2 namespaces, are bogus. Adopting = the rest of the framework would be a useless exercise. Personally, given that all three current proposals are being advanced as = Experimental outside the WG, I would argue that we are wasting far too = much energy on this grand unified framework. And this includes the = current mail exchange. Thanks, Yaron On 28.7.2011 08:02, Dan Harkins wrote: > Paul, > > The existence of this draft shows a failure of YOUR leadership (and = > that of your co-chairman) of the working group. Consensus was achieved = > to add an authentication method based on a simple password yet you=20 > seemingly worked to do everything possible to create division in the=20 > working group and then stepped in to declare failure because no=20 > consensus existed. > > We could've had a single standards-track solution to this problem=20 > over a year ago if you had treated the singular draft used to argue=20 > for addition of this work to the charter in the same way that you=20 > treated the singular draft used to argue for addition of "EAP only"=20 > authentication to the charter. The latter (authored by one of the=20 > chairmen) was advanced to standards track after receiving a whopping=20 > ZERO comments from the WG and the former was killed by the chairmen=20 > because the only comments on the list were from authors of competing=20 > drafts (after manufacturing the competition in the first place). > > There was hostility by the IPsecME chairmen to this work item from=20 > the beginning and you worked to ensure its failure in the WG. Now=20 > you're against advancement of Tero's draft to forge the best possible=20 > outcome now? Not a surprise! > > Put that hat back on, along with a sackcloth and ashes, and say=20 > "mea culpa". > > Dan. > > On Wed, July 27, 2011 5:12 pm, Paul Hoffman wrote: >> >> >> On Jul 27, 2011, at 6:30 PM, Yoav Nir wrote: >> >>> I think this is a terrible idea. >> +.5. I think is is a bad idea. >> >>> IKEv2 has a way for mutual authentication with a shared key. >>> >>> A concern was raised that this method was vulnerable to guessing if=20 >>> trivial shared keys were configured. >>> >>> There were several proposals for a better cryptographic method. >>> >>> The IPsecME working group failed to choose between them. This is not = >>> so surprising, because most participants are engineers, not = cryptographers. >>> Even those with some cryptographic background stayed silent because=20 >>> choosing between several cryptographic protocols is hard. IETF last=20 >>> calls and the IESG did not help much either. >>> >>> This draft represents a total shirking of our responsibility. >> +.5. I think think it represents a shirking of our leadership's >> responsibility. Our leadership said that they would deal with the=20 >> issue if the WG could not come to consensus, and the WG could not=20 >> come to consensus. Adding a layer of indirection that is mostly=20 >> transparent is not dealing with it. >> >>> Rather than decide on one protocol that is "best" or even=20 >>> arbitrarily choosing one that is "good enough", it proposes to build = >>> a framework so that everyone and their dog can have their own=20 >>> method. This is a nightmare for developers: since you can't know=20 >>> what method the peer will support, you have to implement all of = them. >>> >>> If this had been a hierarchical organization, some manager would=20 >>> decide which of the methods gets developed (or published) and the=20 >>> others would be relegated to the recycle bin. >>> >>> The IETF is not like that and we seek to reach consensus. That's a=20 >>> good thing, but this time it's leading us to a really bad solution=20 >>> for interoperability, and a really bad solution for implementers. >>> >>> I am opposed to this draft. >> +1 >> >> >> On Jul 27, 2011, at 6:52 PM, Tero Kivinen wrote: >> >>> Yoav Nir writes: >>>> This draft represents a total shirking of our responsibility.=20 >>>> Rather than decide on one protocol that is "best" or even=20 >>>> arbitrarily choosing one that is "good enough", it proposes to=20 >>>> build a framework so that everyone and their dog can have their own = >>>> method. This is a nightmare for developers: since you can't know=20 >>>> what method the peer will support, you have to implement all of = them. >>> Partially yes, but unfortunately all of the authors of those actual=20 >>> protocols decided that they wanted to continue publishing those=20 >>> drafts as individual RFCs, and each of them used different way to=20 >>> negotiate them, so there was no way to even implement multiple of = them. >> Is this true? Because each has it's own way to negotiate its use, one = >> should be able to implement multiple of the competing proposals=20 >> as-is, yes? >> >>> At least this drafts gives you that option to implement multiple of=20 >>> them if you want. This draft only provides instructions for those=20 >>> other draft authors so they can at least common methods to negotiate = >>> the feature and use common method to trasmit data between peers. >> True, but it is still punting the problem of us having just one. >> >> --Paul Hoffman >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nico@cryptonector.com Thu Jul 28 08:50:59 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2EC21F8C42; Thu, 28 Jul 2011 08:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjvMXTShJ6y6; Thu, 28 Jul 2011 08:50:58 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9EE21F8B9E; Thu, 28 Jul 2011 08:50:52 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 2D77343807E; Thu, 28 Jul 2011 08:50:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=eQX10NzzWVjD1SVS0wiBE RQzVaGsK1xZmj7Amme38AQ/oUGrYZ9V9N/ec0uy10r+38wpx/utn8DlVptlPCa0/ lg1uw9Wu9Wcx6SR+MljV3E3/wa9yGdPFMrZYxvLyc6KVld7OYRTI4fBJNqZlvKCZ wtp85vEVJlGoFGdEiPd6mE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=JlLmT9/6scvxkW+XfA4V 4UIAYgg=; b=erIgtLVD5F4pBut38AVj3aVuNs9HMN77fK6LCldC5t7gzD4AbLX5 k8jfFPOfP5Qcgg4CAhOyZO19SqGb/nisMQxyDSKhDhYilb5+14INDWBZ+CWdp/2f rdO0kKUgSIItcXw2E396vL52hY3Ow88p9nm1wjxUBvez9P0G8rXtU68= Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id F21DE438072; Thu, 28 Jul 2011 08:50:51 -0700 (PDT) Received: by pzk6 with SMTP id 6so4445841pzk.26 for ; Thu, 28 Jul 2011 08:50:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.21.5 with SMTP id r5mr483043pbe.39.1311868251475; Thu, 28 Jul 2011 08:50:51 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Thu, 28 Jul 2011 08:50:51 -0700 (PDT) In-Reply-To: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2011 10:50:51 -0500 Message-ID: From: Nico Williams To: ietf@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: ipsec@ietf.org, IETF-Announce Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:50:59 -0000 I support an IKEv2 ZKPP method framework. I don't understand the controversy -- i.e., I think it's much ado about nothing. Nico -- From yaronf.ietf@gmail.com Fri Jul 29 14:31:11 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE595E801D for ; Fri, 29 Jul 2011 14:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIwwFej6mvzh for ; Fri, 29 Jul 2011 14:31:10 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E08022800F for ; Fri, 29 Jul 2011 14:31:10 -0700 (PDT) Received: by wwe5 with SMTP id 5so2656413wwe.13 for ; Fri, 29 Jul 2011 14:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wfA/vRp2rq+TbjeiCzzZxQAWbXsfKZTYTefDvJ7UbMY=; b=C/AGe8uboZ2ItIZ8uoUQmx8EkZ7l9OcF4ERQ/bWtwflCNkttHbmVx4PXjwxYUhe5ch 2Cpx5TUWgFt59/PIIaNVValZvks276geqTQqOAG/x3Yty7+Bq/utwSpOGzJ97BAuCx57 Xr0QcKB2k7U19Dm78iBL5cpmulgVY9PHJzVes= Received: by 10.227.137.14 with SMTP id u14mr2438680wbt.31.1311975069633; Fri, 29 Jul 2011 14:31:09 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-179-237-205.red.bezeqint.net [79.179.237.205]) by mx.google.com with ESMTPS id fx12sm2070990wbb.42.2011.07.29.14.31.06 (version=SSLv3 cipher=OTHER); Fri, 29 Jul 2011 14:31:08 -0700 (PDT) Message-ID: <4E332698.20900@gmail.com> Date: Sat, 30 Jul 2011 00:31:04 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Tero Kivinen References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <20017.29145.171495.225683@fireball.kivinen.iki.fi> In-Reply-To: <20017.29145.171495.225683@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Dan Harkins , Paul Hoffman Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 21:31:11 -0000 [Removing the main IETF list] Hi Tero, it doesn't matter exactly what negotiation is used, as long as two peers can offer multiple methods in IKE_SA_INIT, and find out which auth methods they have in common, if any. This is true for PACE, and also for version -04 of SPSK, i.e. before it adopted your framework. Regarding IANA allocation, I would like to quote from RFC 5226: "The designated expert is responsible for initiating and coordinating the appropriate review of an assignment request. The review may be wide or narrow, depending on the situation and the judgment of the designated expert. This may involve consultation with a set of technology experts, discussion on a public mailing list, consultation with a working group (or its mailing list if the working group has disbanded), etc. [...] Designated experts are expected to be able to defend their decisions to the IETF community, and the evaluation process is not intended to be secretive or bestow unquestioned power on the expert." I certainly do not want to turn the IANA allocation into a "fight". I do think the community needs to be consulted. Thanks, Yaron On 07/28/2011 05:27 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> Back to the matter at hand: I am opposed to >> draft-kivinen-ipsecme-secure-password-framework. It has served its >> purpose when two of the proposals were changed to add method >> negotiation, and thus enable IKE peers to implement none, one or more of >> these methods. > Actually there is currently only one draft, draft-shin-augmented-pake, > which follows my negotiation process. The > draft-harkins-ipsecme-spsk-auth author did say he is going to change > his draft, but the draft is not yet there, and then there is > draft-kuegler-ipsecme-pace-ikev2 (which you are co-author) which is > doing negotiation differently and I do not know whether that is going > to change to use same way than others. > >> I believe the other justifications for this draft, including the >> preservation of IANA IKEv2 namespaces, are bogus. > As an IANA Expert for the registries in question I strongly disagree. > > If you want to delay this fight to the IANA allocation time, that is > fine by me, but I will point it out already now that I will be against > allocating separate code points for each protocol as there is no need > for that. > >> Adopting the rest of the framework would be a useless exercise. > Keeping the IANA registries clean is important for me, in addition to > make it easy to implement multiple methods in the same implementation. > I do not consider them as useless resons. Especially as it only causes > very small changes to the actual protocol drafts (I would expect less > than an one hour of work). From yaronf.ietf@gmail.com Fri Jul 29 14:47:22 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F79621F8AD8 for ; Fri, 29 Jul 2011 14:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br-22O9jXbKP for ; Fri, 29 Jul 2011 14:47:21 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBAA21F8ACE for ; Fri, 29 Jul 2011 14:47:21 -0700 (PDT) Received: by wyj26 with SMTP id 26so105439wyj.31 for ; Fri, 29 Jul 2011 14:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GukURfocq1R/ovo7RgCotugzM5uwulsRKRaQPyx6GxY=; b=xTitXNjRR+cGPUuh69Jp9HFTv2A5Zy5juZujHjZ9S514ZH0yRgFFdK80aomOSzesDJ w0z0WkIZgm7n7MsCblGqNQnitg7pylFhBfLtiqyBl1NiVIATpc8Sw5FDc0EYFFCZhAOc Xk3xPxSPudJ2fEPaRyy9H6F4aNvs8ANtgbwoM= Received: by 10.227.55.142 with SMTP id u14mr393271wbg.87.1311976040618; Fri, 29 Jul 2011 14:47:20 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-179-237-205.red.bezeqint.net [79.179.237.205]) by mx.google.com with ESMTPS id em16sm2076653wbb.67.2011.07.29.14.47.18 (version=SSLv3 cipher=OTHER); Fri, 29 Jul 2011 14:47:19 -0700 (PDT) Message-ID: <4E332A65.3030804@gmail.com> Date: Sat, 30 Jul 2011 00:47:17 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Dan Harkins References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 21:47:22 -0000 Hi Dan, there are three drafts on the table, and they are NOT identical. Crypto protocols, as you know well, are a mixture of cryptography and engineering. While the engineering on all three is very similar, the cryptography is not. I do not wish to offend, but I believe cryptography is better left to professional cryptographers. I am not a cryptographer; the primary author of draft-kuegler-ipsecme-pace-ikev2 is. Thanks, Yaron On 07/28/2011 03:48 PM, Dan Harkins wrote: > On Wed, July 27, 2011 10:49 pm, Yaron Sheffer wrote: >> Unfortunately Dan cannot accept that there may be objective, non >> political reasons for the group not to adopt his work. Which is the >> reason why three alternative proposals were published several months >> after his proposed PAKE solution. > Well there certainly wasn't a technical reason. In fact, after > delaying things for several months what we ended up with were 3 > drafts that were effectively _identical_ from a technical point of view. > That is the prime reason that the group (and later the AD) could not > agree on which one to choose. From dharkins@lounge.org Sat Jul 30 11:47:15 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38B921F85AB for ; Sat, 30 Jul 2011 11:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIIzdzlKT3Ak for ; Sat, 30 Jul 2011 11:47:15 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 416F021F850B for ; Sat, 30 Jul 2011 11:47:15 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0DB0CA88810C; Sat, 30 Jul 2011 11:47:16 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 30 Jul 2011 11:47:16 -0700 (PDT) Message-ID: In-Reply-To: <4E332A65.3030804@gmail.com> References: <20110727164459.29853.48303.idtracker@ietfa.amsl.com> <7C54FFE2-FFE0-4B4C-BF7E-142A6B10DF6B@checkpoint.com> <78B594BA-9406-44A2-AB8E-0BF5A425AEC1@vpnc.org> <7828ad8727dd860ccd6c5eb5acd52c19.squirrel@www.trepanning.net> <4E30F876.70200@gmail.com> <4E332A65.3030804@gmail.com> Date: Sat, 30 Jul 2011 11:47:16 -0700 (PDT) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , Dan Harkins Subject: Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 18:47:15 -0000 Hi Yaron, On Fri, July 29, 2011 2:47 pm, Yaron Sheffer wrote: > Hi Dan, > > there are three drafts on the table, and they are NOT identical. Crypto > protocols, as you know well, are a mixture of cryptography and > engineering. While the engineering on all three is very similar, the > cryptography is not. I didn't say the cryptography was identical, nor did I say the drafts are identical (if they were then this "controversy" would be even more contrived!). What I meant was that if your original opposition to my draft was technical (or non-political, as you say) then we would've seen some demonstrable technical difference in 1 of the 3 new drafts. We didn't. They all do a zero knowledge proof in about the same number of rounds (adding one to IKE_AUTH) with about the same amount of work (+- a modular exponentiation). They all achieve the same goal in approximately the same amount of messages with approximately the same amount of work. If there was a obvious demonstrable technical difference between the drafts then the WG would've picked a winner or the AD would've picked a winner or his designated expert would've picked a winner. But we have no winner so, as I said, they are "effectively _identical_ from a technical point of view." So there wasn't a technical reason for you to do what you did. We could've had a standards track solution to this work item if you had just treated my draft in the same way you treated your own. But no. We have 3 drafts, an implementation problem, and now your opposition to a draft to lessen that problem as much as possible. > I do not wish to offend, but I believe cryptography is better left to > professional cryptographers. I am not a cryptographer; the primary > author of draft-kuegler-ipsecme-pace-ikev2 is. I'm not offended because I'm not a cryptographer and have never said otherwise. But neither are any of the editors of the IKEv2 draft and I don't remember your opposition to the advancement of that draft to RFC. Dan.