From root@core3.amsl.com Mon Mar 1 08:15:02 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3CDF93A8AB5; Mon, 1 Mar 2010 08:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100301161502.3CDF93A8AB5@core3.amsl.com> Date: Mon, 1 Mar 2010 08:15:02 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 16:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Internet Key Exchange Protocol: IKEv2 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen Filename : draft-ietf-ipsecme-ikev2bis-08.txt Pages : 148 Date : 2010-2-26 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-3-1080439.I-D@ietf.org> --NextPart-- From yaronf@checkpoint.com Mon Mar 1 08:43:47 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55AD928C425 for ; Mon, 1 Mar 2010 08:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOOC1guzxKci for ; Mon, 1 Mar 2010 08:43:46 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 2707E28C3C2 for ; Mon, 1 Mar 2010 08:43:45 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o21GhiPb010847 for ; Mon, 1 Mar 2010 18:43:44 +0200 (IST) X-CheckPoint: {4B8BED93-1-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 1 Mar 2010 18:44:04 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Mon, 1 Mar 2010 18:44:02 +0200 Thread-Topic: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-08.txt - final WG review period Thread-Index: Acq5Wq9y7Ai4gevpSiWU+RYpfRi3cQAAdZFQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB5544@il-ex01.ad.checkpoint.com> References: <20100301161502.3CDF93A8AB5@core3.amsl.com> In-Reply-To: <20100301161502.3CDF93A8AB5@core3.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 Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-08.txt - final WG review period X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 16:43:47 -0000 Hi, This version of IKEv2-bis resolves dozens of issues received from many WG m= embers during (and after) the Last Call. I would like to thank everybody wh= o helped to improve this document, and the authors for the great effort tha= t went into -08. We are *not* planning a second WGLC. Instead, I would like to ask you to qu= ickly review the draft during the next few days (until Thursday end of day)= . You may want to "diff" it with -07, or to look up issues on the issue tra= cker. Please raise any new issues on the mailing list. Following this period and unless something major comes up, we will forward = -08 to Tim. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Monday, March 01, 2010 18:15 > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-08.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. >=20 > Title : Internet Key Exchange Protocol: IKEv2 > Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen > Filename : draft-ietf-ipsecme-ikev2bis-08.txt > Pages : 148 > Date : 2010-2-26 >=20 > This document describes version 2 of the Internet Key Exchange (IKE) > protocol. IKE is a component of IPsec used for performing mutual > authentication and establishing and maintaining security > associations > (SAs). This document replaces and updates RFC 4306, and includes > all > of the clarifications from RFC 4718. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-08.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From paul.hoffman@vpnc.org Mon Mar 1 09:00:31 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B4228C2EC for ; Mon, 1 Mar 2010 09:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdTkAoQn2iAZ for ; Mon, 1 Mar 2010 09:00:31 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 52D6D3A83F1 for ; Mon, 1 Mar 2010 09:00:27 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o21H0GJM052644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2010 10:00:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB5544@il-ex01.ad.checkpoint.com> References: <20100301161502.3CDF93A8AB5@core3.amsl.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB5544@il-ex01.ad.checkpoint.com> Date: Mon, 1 Mar 2010 09:00:15 -0800 To: Yaron Sheffer , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-08.txt - final WG review period X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 17:00:31 -0000 At 6:44 PM +0200 3/1/10, Yaron Sheffer wrote: >We are *not* planning a second WGLC. Instead, I would like to ask you to quickly review the draft during the next few days (until Thursday end of day). You may want to "diff" it with -07, or to look up issues on the issue tracker. Please raise any new issues on the mailing list. The IETF tools site provides diffs of the two drafts. I prefer the modern diff style at , but some folks prefer the Old Skool diff style at . We're getting closer, but we really need people to continue to do careful reviews. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Mar 1 16:34:19 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A74728C653; Mon, 1 Mar 2010 16:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU4j7jTzyi4K; Mon, 1 Mar 2010 16:34:18 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6D6C328C664; Mon, 1 Mar 2010 16:34:16 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o220YFqC078140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2010 17:34:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 1 Mar 2010 16:34:12 -0800 To: IPsecme WG , cfrg@irtf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 00:34:19 -0000 Greetings again. This message is cross-posted to both the IPsecME WG and the CFRG because it pertains to both groups. The recently-revised IPsecME charter has a new work item in it: ========== - IKEv2 supports mutual authentication with a shared secret, but this mechanism is intended for "strong" shared secrets. User-chosen passwords are typically of low entropy and subject to off-line dictionary attacks when used with this mechanism. Thus, RFC 4306 recommends using EAP with public-key based authentication of the responder instead. This approach would be typically used in enterprise remote access VPN scenarios where the VPN gateway does not usually even have the actual passwords for all users, but instead typically communicates with a back-end RADIUS server. However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. While it would be possible to use EAP in such situations (by having both peers implement both the EAP peer and the EAP server roles of an EAP method intended for "weak" shared secrets) with the mutual EAP-based authentication work item (above), a simpler solution may be desirable in many situations. The WG will develop a standards-track extension to IKEv2 to allow mutual authentication based on "weak" (low-entropy) shared secrets. The goal is to avoid off-line dictionary attacks without requiring the use of certificates or EAP. There are many already-developed algorithms that can be used, and the WG would need to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. The WG would also need to develop the protocol to use the chosen algorithm in IKEv2 in a secure fashion. It is noted up front that this work item poses a higher chance of failing to be completed than other WG work items; this is balanced by the very high expected value of the extension if it is standardized and deployed. ========== As the last paragraph says, there are multiple algorithms to choose from. Different algorithms have different properties. Before the WG decides on which algorithm to focus on, it needs to at least roughly decide which properties are important for the new protocol. I have included the CFRG on this message because they are a good source of expertise on cryptographic properties. Yaron Sheffer has created a short and admittedly biased draft listing some desired properties and possible candidate algorithms: . Other people (and even Yaron) might have different views on which properties are important, how the properties should be ranked, the importance of the crypto properties of the listed algorithms, and so on. This message is therefore meant to kick off the discussion. It is OK for messages to focus on one or more of the proposed algorithms, but getting a clearer view of which crypto and non-crypto properties are important is probably more important first. --Paul Hoffman, Director --VPN Consortium From Hannes.Tschofenig@gmx.net Tue Mar 2 09:23:08 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D065128C0E6 for ; Tue, 2 Mar 2010 09:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuieHV9MLe1N for ; Tue, 2 Mar 2010 09:23:07 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 757403A87DF for ; Tue, 2 Mar 2010 09:23:06 -0800 (PST) Received: (qmail invoked by alias); 02 Mar 2010 17:23:03 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp070) with SMTP; 02 Mar 2010 18:23:03 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/3OkkJAn33MsKa6zFLXlbOb/2BHWj4i+OBbkHjRf 8bGmZPYFepGplc Message-ID: <4B8D494F.8010009@gmx.net> Date: Tue, 02 Mar 2010 19:22:23 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55000000000000004 Cc: IPsecme WG , cfrg@irtf.org Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 17:23:08 -0000 The challenge I have in understanding the motivation for this work is impacted by ... 1) EAP is not only meant to be used with backend infrastructure. 2) EAP is an authentication framework and EAP methods exist that support strong-password based authentication. 3) EAP is implemented by folks in IKEv2 already. To me it seems that there is the chance to re-use existing mechanisms and to even re-use existing code. Ciao Hannes Paul Hoffman wrote: > Greetings again. This message is cross-posted to both the IPsecME WG and the CFRG because it pertains to both groups. > > The recently-revised IPsecME charter has a new work item in it: > > ========== > - IKEv2 supports mutual authentication with a shared secret, but this > mechanism is intended for "strong" shared secrets. User-chosen > passwords are typically of low entropy and subject to off-line > dictionary attacks when used with this mechanism. Thus, RFC 4306 > recommends using EAP with public-key based authentication of the > responder instead. This approach would be typically used in enterprise > remote access VPN scenarios where the VPN gateway does not usually > even have the actual passwords for all users, but instead typically > communicates with a back-end RADIUS server. > > However, user-configured shared secrets are still useful for many > other IPsec scenarios, such as authentication between two servers or > routers. These scenarios are usually symmetric: both peers know the > shared secret, no back-end authentication servers are involved, and > either peer can initiate an IKEv2 SA. While it would be possible to > use EAP in such situations (by having both peers implement both the > EAP peer and the EAP server roles of an EAP method intended for "weak" > shared secrets) with the mutual EAP-based authentication work item > (above), a simpler solution may be desirable in many situations. > > The WG will develop a standards-track extension to IKEv2 to allow > mutual authentication based on "weak" (low-entropy) shared > secrets. The goal is to avoid off-line dictionary attacks without > requiring the use of certificates or EAP. There are many > already-developed algorithms that can be used, and the WG would need > to pick one that both is believed to be secure and is believed to have > acceptable intellectual property features. The WG would also need to > develop the protocol to use the chosen algorithm in IKEv2 in a secure > fashion. It is noted up front that this work item poses a higher > chance of failing to be completed than other WG work items; this is > balanced by the very high expected value of the extension if it is > standardized and deployed. > ========== > > As the last paragraph says, there are multiple algorithms to choose from. Different algorithms have different properties. Before the WG decides on which algorithm to focus on, it needs to at least roughly decide which properties are important for the new protocol. I have included the CFRG on this message because they are a good source of expertise on cryptographic properties. > > Yaron Sheffer has created a short and admittedly biased draft listing some desired properties and possible candidate algorithms: . Other people (and even Yaron) might have different views on which properties are important, how the properties should be ranked, the importance of the crypto properties of the listed algorithms, and so on. > > This message is therefore meant to kick off the discussion. It is OK for messages to focus on one or more of the proposed algorithms, but getting a clearer view of which crypto and non-crypto properties are important is probably more important first. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > From suresh.krishnan@ericsson.com Tue Mar 2 09:42:06 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4144B28C13F for ; Tue, 2 Mar 2010 09:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vkLAbX4KCeg for ; Tue, 2 Mar 2010 09:42:05 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id CC6D63A8BF2 for ; Tue, 2 Mar 2010 09:42:04 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o22HiRZp006249; Tue, 2 Mar 2010 11:44:27 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 2 Mar 2010 12:42:04 -0500 From: Suresh Krishnan To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Tue, 2 Mar 2010 12:42:02 -0500 Thread-Topic: AD review comments for draft-ietf-ipsecme-roadmap-05 Thread-Index: Acq3H3SOmue/5sEoQIe0TW0wFHu7iwC+th4Q Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC14E5CF5BA39@EUSAACMS0703.eamcs.ericsson.se> References: <808FD6E27AD4884E94820BC333B2DB775848146182@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775848146182@NOK-EUMSG-01.mgdnok.nokia.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 Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-roadmap-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 17:42:06 -0000 Hi Pasi, Thanks for your comments. Some of them are pretty major and we would like= to request some time to properly address them. We will respond by next Mon= day with our proposed resolutions. Thanks Suresh > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Pasi.Eronen@nokia.com > Sent: Friday, February 26, 2010 12:08 PM > To: ipsec@ietf.org > Subject: [IPsec] AD review comments for draft-ietf-ipsecme-roadmap-05 >=20 > I've now done my AD review for draft-ietf-ipsecme-roadmap-05,=20 > and have bunch of comments (most of them minor). Most important first: >=20 > - I'm not very happy about the use of MUST, SHOULD, etc. in=20 > this document. This is supposed to be a purely informational=20 > guide to other documents, not something that sets=20 > requirements (of any level) for anyone. >=20 > For cryptographic algorithms, we already have separate=20 > documents that specify the requirement levels. IMHO repeating=20 > them here just means the two places will soon be inconsistent=20 > (which is not helpful for the audience here). If the WG has=20 > considered this and decided the repeating them here is=20 > useful, I would strongly suggest just having the tables in=20 > Appendix B (with explicit note that they're probably out of=20 > date by the time the reader finds them), and removing them=20 > from Section 5.x. >=20 > For things other than cryptographic algorithms, I'm not sure=20 > if talking about "requirements levels" even makes that much=20 > sense. Consider, for example, Section 4.2.4.2 (IKEv2 redirect): >=20 > Requirements levels for RFC5685: > IKEv1 - N/A > IKEv2 - optional >=20 > This is not really specifying any requirement level; a=20 > phrasing like "This extension applies only to IKEv2, not=20 > IKEv1" would IMHO be more accurate. Text in most other=20 > sections (than crypto algs) could be rephrased similarly. >=20 > - Appendix B: I'm trying to match table B against RFC=20 > 4307/4835 and I can't quite get them to match. For example,=20 > RFC 4307 lists > AUTH_AES_XCBC_96 as "SHOULD+", while the column "IKEv2" here=20 > says "optional". This suggests that perhaps even including=20 > this table isn't such a good idea... >=20 > - Section 5.4: "Since combined mode algorithms are not a=20 > feature of IPsec-v2, these IKEv1 implementations are used in=20 > conjunction with IPsec-v3." I'm not sure if this is really a=20 > good way to describe the situation; after all, GCM-for-ESP=20 > (RFC 4106) predates IPsec-v3... >=20 > I'd suggest something like "Although IPsec-v2 ESP [RFC2406]=20 > did not originally include combined mode algorithms, some=20 > IKEv1 implementations have added the capability to negotiate=20 > combined mode algorithms for use in IPsec SAs; these=20 > implementations do not include the capability to use combined=20 > mode algorithms to protect IKE SAs." >=20 > Analogous changes are needed in 5.4.1, 5.4.2, 5.4.3, and 5.6.2. >=20 > - Section 5.4.1: "[RFC4309] includes IANA values for use in=20 > ESP-v3"; ESP doesn't have any IANA registries; IKEv1 and=20 > IKEv2 do. RFC 4309 is included in both. >=20 > - Quite many IETF protocols use (or can use) IPsec to protect=20 > their traffic, so we have *lot* of RFCs that specify how to=20 > configure IPsec for use X (ranging from RADIUS and Diameter=20 > to iSCSI and TGREP). =20 > I don't think these belong in the IPsec document roadmap,=20 > unless they modify/extend how IPsec works (e.g. define new=20 > payloads/something for IKEv1/v2, or change the IPsec=20 > processing somehow). >=20 > With this in mind, I'd suggest deleting 8.1.1, 8.1.2, and=20 > 8.2; rephrasing 8.1.3 and 8.1.4 to explain their impact on=20 > IPsec; deleting 8.1.5/8.1.6/8.1.7 and adding RFC 5026 (text below). >=20 > Proposed new text for 8.1.3: >=20 > This document specifies the use of IPsec in securing Mobile IPv6 > traffic between mobile nodes and home agents. Mobile IPv6 requires > considering the Home Address destination option and Routing Header > in IPsec processing. Also, IPsec and IKE security association > addresses can be updated by Mobile IPv6 signaling messages. >=20 > Proposed new text for 8.1.4: >=20 > This document updates [RFC3776] in order to work with the revised > IPsec architecture [RFC4301]. Since the revised IPsec architecture > expands the list of selectors to include the Mobility=20 > Header message > type, it becomes much easier to differentiate between different > mobility header messages. This document also specifies the use > of IKEv2 configuration payloads for dynamic home address=20 > configuration. >=20 > Proposed text for RFC 5026: >=20 > This document extends [RFC4877] to support dynamic discovery of > home agents and the home network prefix; for the latter purpose, it > specifies a new IKEv2 configuration attribute and notificatio7n. >=20 > - Section 5.x: IMHO lines like "ESP-v2 - undefined (no IANA #)" > are a bit confusing, because ESP does not have any IANA=20 > registries; the registries are specific to a key management=20 > protocol (IKEv1, IKEv2, Photuris, KINK, HIP, ...).=20 >=20 > - Section 5.7.4: "It also includes 3 EC DH groups (groups=20 > 19-21) that were previously defined in [RFC4753]". The=20 > normative specification for groups 19-21 in IKE is still=20 > 4753/5753bis, so I would propose just omitting this sentence. >=20 > - I would suggest moving 3.2/3.3 somewhere later in the=20 > document -- as the document already says, this is not really=20 > deployed stuff, and might fit better in e.g. Section 7. >=20 > - IMHO MOBIKE would belong together with other IKEv2 remote=20 > access extensions in Section 4.2.4? >=20 > - Should RFC 2521 be mentioned? (it's largely obsolete, I=20 > guess, but for completeness..) >=20 > - What about RFC 2709? (it's definitely obsolete, but things=20 > like this influenced the design of the current IPsec NAT-T,=20 > like using a different port number to avoid any 2709-like stuff :-) >=20 > - Should we include RFC 3329? It does (partly) specify the=20 > "3gpp-ipsec" mechanism for setting up IPsec SAs (basically, a=20 > simple key management protocol instead of IKE), and this is=20 > something that is actually implemented (however, some of the=20 > details needed to implement this are not actually in 3329,=20 > but only in 3GPP specs...) >=20 > - Section 8.5.1: this has an IKE extension (to pretty core=20 > part of IKE), so might belong in Section 4.2 instead. >=20 > - RFC 4322 probably should be mentioned somewhere (near BTNS=20 > and/or IPSECKEY). >=20 > - Section 8.8.1: suggest adding something like "It also=20 > defines how public key fingerprints (hashes) are distributed=20 > via BGP, and used later to authenticate IKEv2 exchange=20 > between the tunnel endpoints." >=20 > - Section 6: MIKEY (as specified in IETF RFCs) creates=20 > security associations for SRTP, not IPsec -- so it's not=20 > really relevant for this document (some other SDOs have=20 > extended MIKEY to create IPsec SAs, but that's an area we=20 > IMHO don't need to cover in this roadmap). > So Sections 6.(7,8,9,10,12,13) should be dropped. >=20 > - Section 6.1: RFC 3740 barely mentions IPsec, so the=20 > description should probably point out that 3740 isn't really=20 > about IPsec. >=20 > - I'm not sure what 4534/4535 have to do with IPsec; it=20 > doesn't look like it supports creating IPsec SAs, for example. >=20 > - Sections 6.(14,15,16) are not about IPsec, but non-IPsec=20 > approaches to securing multicast; so they don't really belong here. >=20 > - Section 8.6 and 8.4.1 are not about IPsec, but adapting=20 > IKEv2 to non-IPsec uses. Perhaps these (and RFC 4705, which=20 > is missing from the > list) should be grouped under "Non-IPsec Protocols Related to=20 > IKE" or something? (and Section 8.4.1 doesn't really belong=20 > under title "EMU"; it did not come from the EMU WG). >=20 > - Section 7.4: would it be useful to mention that some=20 > vendors have proprietary extensions for Kerberos in IKEv1 (not KINK)? > (since these are really deployed and used, unlike KINK...) >=20 > - Section 7.1: I would suggest not having separate sections=20 > for all IPComp compression algorithms. Perhaps a one-sentence=20 > summary like: > "Compression algorithms for IPcomp include DEFLATE [RFC=20 > 2394], LZS [RFC2395], and LZJH [RFC 3051]." would be sufficient? >=20 > - Section 1: "The usage of terms in this document conforms to=20 > definitions in [RFC4949]." No, it does not; just remove this sentence. > Here's what Sam wrote back then for his ABSTAIN ballot for 4949: >=20 > "However there is a lot left in the glossary that is the author's > personal opinion. We found a number of instances where the author > was trying to use this glossary to establish normative meanings for > words based on his belief of how those words should be > used--sometimes in direct conflict with common practice." >=20 > (For example, 4949 considers terms like "MAC (message=20 > authentication code)" and "initialization vector" to be=20 > wrong; the "correct" terms would be "keyed hash"/"protected=20 > checksum" and "initialization value"). >=20 > - Section 4.2.4.3: now RFC 5739. >=20 > - Section 1 and 5: "MUST, SHALL or MAY" should probably be=20 > "MUST, SHOULD or MAY"? >=20 > - I'd suggest swapping the order of 7.2.1 and 7.2.2. >=20 > - Section 7.6 and 7.6.1: I'd suggest combining this to a=20 > single section. >=20 > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > = From paul.hoffman@vpnc.org Tue Mar 2 09:51:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F196D3A8A91; Tue, 2 Mar 2010 09:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0F8cKX3i2HZ; Tue, 2 Mar 2010 09:51:34 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 05B883A898D; Tue, 2 Mar 2010 09:51:33 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o22HpUXw038127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 10:51:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4B8D494F.8010009@gmx.net> References: <4B8D494F.8010009@gmx.net> Date: Tue, 2 Mar 2010 09:51:29 -0800 To: Hannes Tschofenig From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG , cfrg@irtf.org Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 17:51:35 -0000 At 7:22 PM +0200 3/2/10, Hannes Tschofenig wrote: >The challenge I have in understanding the motivation for this work is impacted by ... > >1) EAP is not only meant to be used with backend infrastructure. >2) EAP is an authentication framework and EAP methods exist that support strong-password based authentication. >3) EAP is implemented by folks in IKEv2 already. > >To me it seems that there is the chance to re-use existing mechanisms and to even re-use existing code. Hannes, it is not really appropriate to re-open closed charter issues. As you know, this was already discussed, at length, in the WG. That's why another part of the new charter has: - A standards-track IKEv2 extension to allow mutual EAP-based authentication in IKEv2, eliminating the need for the responder to present a certificate. The document will define the conditions that EAP methods need to fulfill in order to use this extension. The document will recommend, but will not require, the use of EAP methods that provide EAP channel binding. The proposed starting point for this work is draft-eronen-ipsec-ikev2-eap-auth-07.txt. For this thread, please focus on the issues at hand for a secure password-only authentication mode for IKEv2. Thanks! --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Tue Mar 2 10:00:01 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C80D028C1E8; Tue, 2 Mar 2010 10:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100302180001.C80D028C1E8@core3.amsl.com> Date: Tue, 2 Mar 2010 10:00:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 18:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Author(s) : S. Shen, Y. Mao, S. murthy Filename : draft-ietf-ipsecme-aes-ctr-ikev2-05.txt Pages : 10 Date : 2010-3-2 This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-aes-ctr-ikev2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-3-2095240.I-D@ietf.org> --NextPart-- From smb@cs.columbia.edu Tue Mar 2 10:19:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3EC3A898D for ; Tue, 2 Mar 2010 10:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kLWWfgcM0Gm for ; Tue, 2 Mar 2010 10:19:52 -0800 (PST) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 6DA8528C217 for ; Tue, 2 Mar 2010 10:19:51 -0800 (PST) Received: by machshav.com (Postfix, from userid 512) id 9A60052D3FB; Tue, 2 Mar 2010 13:19:52 -0500 (EST) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0CA4C52D3E9; Tue, 2 Mar 2010 13:19:52 -0500 (EST) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 7C13A293CEB; Tue, 2 Mar 2010 13:19:45 -0500 (EST) Date: Tue, 2 Mar 2010 13:19:44 -0500 From: "Steven M. Bellovin" To: "Blumenthal, Uri - 0662 - MITLL" Message-ID: <20100302131944.303e2615@yellowstone.machshav.com> In-Reply-To: <20100302180343.A31EE28C1FC@core3.amsl.com> References: <20100302180343.A31EE28C1FC@core3.amsl.com> Organization: Columbia University X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "'ipsec@ietf.org'" , "'Hannes.Tschofenig@gmx.net'" , "'cfrg@irtf.org'" , "'paul.hoffman@vpnc.org'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 18:19:58 -0000 On Tue, 2 Mar 2010 13:03:40 -0500 "Blumenthal, Uri - 0662 - MITLL" wrote: > I see value in adding a simpler-than-EAP method, and support this > effort. But overall it's an extremely difficult task because of IPR. > > I personally would hate to see a patent-encumbered solution - and > that would disqualify EKE and PAK outright (both held by > Alcatel-Lucent, AFAIK). SRP would be the only acceptable (from IPR > point of view) candidate that I'm aware of. Note that the EKE patent expires in October 2011. (At least I think it does; it was filed in October 1991.) Depending on when you expect implementations to appear-- and given how long it takes to produce standards-track documents in the IETF -- it might not be a problem. > I've been told that EKE > patent is written so broadly that it could cover SRP as well - > somebody more knowledgeable should comment on this. > I've been told that, too, but since I haven't worked for the patent assignee for almost 13 years, I've never felt any need to (go through the non-trivial amount of work necessary to) come to my own conclusions. From yaronf@checkpoint.com Tue Mar 2 10:32:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0AF428C24F; Tue, 2 Mar 2010 10:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPY15aAUdP9t; Tue, 2 Mar 2010 10:32:22 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 82BF828C0FE; Tue, 2 Mar 2010 10:32:21 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o22IW9sd002480; Tue, 2 Mar 2010 20:32:09 +0200 (IST) X-CheckPoint: {4B8D5870-1-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 2 Mar 2010 20:32:28 +0200 From: Yaron Sheffer To: "Steven M. Bellovin" , "Blumenthal, Uri - 0662 - MITLL" Date: Tue, 2 Mar 2010 20:32:26 +0200 Thread-Topic: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6NQxHgW1YgMkHQeSj7dEu3kOOlQAAN4DQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56D0@il-ex01.ad.checkpoint.com> References: <20100302180343.A31EE28C1FC@core3.amsl.com> <20100302131944.303e2615@yellowstone.machshav.com> In-Reply-To: <20100302131944.303e2615@yellowstone.machshav.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: "'ipsec@ietf.org'" , "'Hannes.Tschofenig@gmx.net'" , "'cfrg@irtf.org'" , "'paul.hoffman@vpnc.org'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 18:32:25 -0000 Whether or not the EKE patent is broad enough, if you search the IPR reposi= tory for RFC 2945 (SRP), you will find out that more than one company is ha= ppy to post an IPR warning related to SRP. This of course does not prove an= ything - they're just saying that their patents "might apply". BTW, I also = believe the EKE patent expires 10/2011. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Steven M. Bellovin > Sent: Tuesday, March 02, 2010 20:20 > To: Blumenthal, Uri - 0662 - MITLL > Cc: 'ipsec@ietf.org'; 'Hannes.Tschofenig@gmx.net'; 'cfrg@irtf.org'; > 'paul.hoffman@vpnc.org' > Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password- > only authentication for IKEv2 >=20 > On Tue, 2 Mar 2010 13:03:40 -0500 > "Blumenthal, Uri - 0662 - MITLL" wrote: >=20 > > I see value in adding a simpler-than-EAP method, and support this > > effort. But overall it's an extremely difficult task because of IPR. > > > > I personally would hate to see a patent-encumbered solution - and > > that would disqualify EKE and PAK outright (both held by > > Alcatel-Lucent, AFAIK). SRP would be the only acceptable (from IPR > > point of view) candidate that I'm aware of. >=20 > Note that the EKE patent expires in October 2011. (At least I think it > does; it was filed in October 1991.) Depending on when you expect > implementations to appear-- and given how long it takes to produce > standards-track documents in the IETF -- it might not be a problem. >=20 > > I've been told that EKE > > patent is written so broadly that it could cover SRP as well - > > somebody more knowledgeable should comment on this. > > > I've been told that, too, but since I haven't worked for the patent > assignee for almost 13 years, I've never felt any need to (go through > the non-trivial amount of work necessary to) come to my own > conclusions. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From dharkins@lounge.org Tue Mar 2 12:20:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467EE28C15A for ; Tue, 2 Mar 2010 12:20:32 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM06zAnIGxMF for ; Tue, 2 Mar 2010 12:20:32 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id DB4533A8C9F for ; Tue, 2 Mar 2010 12:20:31 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id F284C1022404A; Tue, 2 Mar 2010 12:12:18 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 2 Mar 2010 12:12:19 -0800 (PST) Message-ID: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> In-Reply-To: References: Date: Tue, 2 Mar 2010 12:12:19 -0800 (PST) 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 , cfrg@irtf.org Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 20:20:33 -0000 Hello, There are other criteria that should be evaluated in making a decision, such as how well does the solution fits into IKE(v2) and does it support "crypto agility". RFC 2409 supported negotiation of various parameters, like the group used for the Diffie-Hellman key exchange. That was removed in RFC 4306. All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- criteria do some sort of discrete logarithm cryptography and therefore it would be useful to list whether the candidate algorithm can use any of the groups either negotiated or asserted by IKE(v2). For instance, I do not believe EKE is suitable for any of the groups currently in the IANA registry of groups that can be used with IKE(v2). The MODP groups have a generator that is a quadratic residue which enables a passive attacker to eliminate passwords from the dictionary if they do not decrypt to a value that is, itself, a quadratic residue and ECP groups are unsuitable because a passive attacker can eliminate passwords from the group if they do not decrypt to a valid point on the curve. In either case, after seeing a trivial number of exchanges a passive attacker is able to determine the password with high probability. So EKE requires a hard-coded special group to be used for its discrete logarithm operations and since negotiation has been removed in RFC 4306 it means that the ability to change the group to suit the policy or whim of the user (what is popularly termed "crypto agility") goes away. EKE also requires specification of the mode of encryption used which may or may not be the same as the one negotiated or asserted in IKE(v2). It could be hard-coded into the specification, like the group, but this too further limits "crypto agility". The other candidates, I believe, can use the same group, whether MODP or ECP, that the IKE(v2) exchange is using. I think it would be good to add these criteria to the draft. Also, the table in section 5 should include IEEE 802.11s under the "standards" column for SPSK. And the phrase "may or may not infringe on existing patents" applies to all candidates, and frankly, to almost everything in the IETF. It is a meaningless phrase and it would be better to just remove it from the "IPR" column. regards, Dan. On Mon, March 1, 2010 4:34 pm, Paul Hoffman wrote: > Greetings again. This message is cross-posted to both the IPsecME WG and > the CFRG because it pertains to both groups. > > The recently-revised IPsecME charter has a new work item in it: > > ========== > - IKEv2 supports mutual authentication with a shared secret, but this > mechanism is intended for "strong" shared secrets. User-chosen > passwords are typically of low entropy and subject to off-line > dictionary attacks when used with this mechanism. Thus, RFC 4306 > recommends using EAP with public-key based authentication of the > responder instead. This approach would be typically used in enterprise > remote access VPN scenarios where the VPN gateway does not usually > even have the actual passwords for all users, but instead typically > communicates with a back-end RADIUS server. > > However, user-configured shared secrets are still useful for many > other IPsec scenarios, such as authentication between two servers or > routers. These scenarios are usually symmetric: both peers know the > shared secret, no back-end authentication servers are involved, and > either peer can initiate an IKEv2 SA. While it would be possible to > use EAP in such situations (by having both peers implement both the > EAP peer and the EAP server roles of an EAP method intended for "weak" > shared secrets) with the mutual EAP-based authentication work item > (above), a simpler solution may be desirable in many situations. > > The WG will develop a standards-track extension to IKEv2 to allow > mutual authentication based on "weak" (low-entropy) shared > secrets. The goal is to avoid off-line dictionary attacks without > requiring the use of certificates or EAP. There are many > already-developed algorithms that can be used, and the WG would need > to pick one that both is believed to be secure and is believed to have > acceptable intellectual property features. The WG would also need to > develop the protocol to use the chosen algorithm in IKEv2 in a secure > fashion. It is noted up front that this work item poses a higher > chance of failing to be completed than other WG work items; this is > balanced by the very high expected value of the extension if it is > standardized and deployed. > ========== > > As the last paragraph says, there are multiple algorithms to choose from. > Different algorithms have different properties. Before the WG decides on > which algorithm to focus on, it needs to at least roughly decide which > properties are important for the new protocol. I have included the CFRG on > this message because they are a good source of expertise on cryptographic > properties. > > Yaron Sheffer has created a short and admittedly biased draft listing some > desired properties and possible candidate algorithms: > . > Other people (and even Yaron) might have different views on which > properties are important, how the properties should be ranked, the > importance of the crypto properties of the listed algorithms, and so on. > > This message is therefore meant to kick off the discussion. It is OK for > messages to focus on one or more of the proposed algorithms, but getting a > clearer view of which crypto and non-crypto properties are important is > probably more important first. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf@checkpoint.com Tue Mar 2 12:49:39 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D6228C18B; Tue, 2 Mar 2010 12:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QT8i18i3qXc; Tue, 2 Mar 2010 12:49:38 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A3B4228C0CF; Tue, 2 Mar 2010 12:49:37 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o22Knasd018728; Tue, 2 Mar 2010 22:49:36 +0200 (IST) X-CheckPoint: {4B8D78A6-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 2 Mar 2010 22:49:56 +0200 From: Yaron Sheffer To: Dan Harkins , Paul Hoffman Date: Tue, 2 Mar 2010 22:49:53 +0200 Thread-Topic: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6ReTf1vkuZQjHQBCDjhMf6QNooQAAPpmQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56E1@il-ex01.ad.checkpoint.com> References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> In-Reply-To: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> 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 , "cfrg@irtf.org" Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 20:49:39 -0000 Hi Dan, EAP-EKE supports negotiation of various algorithms, a.k.a. crypto-agility. = One of the negotiated algorithms is in fact the group being used. EAP-EKE d= oes require MODP groups that fulfill certain conditions, and as a result, t= he document defines one such group (additional ones can be easily added). I= believe that crypto-agility is an important criterion. As to reuse of IKEv= 2 groups, this is probably much less important. It is a bit early to speculate about IKE+EKE, since to the best of my knowl= edge, it has not been written yet. By the way, IKEv2 does allow for negotiation of the DH group using the ugly= INVALID_KE_PAYLOAD hack. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Dan Harkins > Sent: Tuesday, March 02, 2010 22:12 > To: Paul Hoffman > Cc: IPsecme WG; cfrg@irtf.org > Subject: Re: [IPsec] Beginning discussion on secure password-only > authentication for IKEv2 >=20 >=20 > Hello, >=20 > There are other criteria that should be evaluated in making a > decision, such as how well does the solution fits into IKE(v2) and > does it support "crypto agility". >=20 > RFC 2409 supported negotiation of various parameters, like the group > used for the Diffie-Hellman key exchange. That was removed in RFC 4306. > All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- > criteria do some sort of discrete logarithm cryptography and therefore > it would be useful to list whether the candidate algorithm can use > any of the groups either negotiated or asserted by IKE(v2). >=20 > For instance, I do not believe EKE is suitable for any of the > groups currently in the IANA registry of groups that can be used with > IKE(v2). The MODP groups have a generator that is a quadratic residue > which enables a passive attacker to eliminate passwords from the > dictionary if they do not decrypt to a value that is, itself, a > quadratic > residue and ECP groups are unsuitable because a passive attacker can > eliminate passwords from the group if they do not decrypt to a valid > point > on the curve. In either case, after seeing a trivial number of > exchanges > a passive attacker is able to determine the password with high > probability. >=20 > So EKE requires a hard-coded special group to be used for its > discrete > logarithm operations and since negotiation has been removed in RFC 4306 > it means that the ability to change the group to suit the policy or > whim > of the user (what is popularly termed "crypto agility") goes away. EKE > also requires specification of the mode of encryption used which may or > may not be the same as the one negotiated or asserted in IKE(v2). It > could be hard-coded into the specification, like the group, but this > too > further limits "crypto agility". >=20 > The other candidates, I believe, can use the same group, whether MODP > or ECP, that the IKE(v2) exchange is using. I think it would be good to > add these criteria to the draft. >=20 > Also, the table in section 5 should include IEEE 802.11s under the > "standards" column for SPSK. And the phrase "may or may not infringe on > existing patents" applies to all candidates, and frankly, to almost > everything in the IETF. It is a meaningless phrase and it would be > better > to just remove it from the "IPR" column. >=20 > regards, >=20 > Dan. >=20 > On Mon, March 1, 2010 4:34 pm, Paul Hoffman wrote: > > Greetings again. This message is cross-posted to both the IPsecME WG > and > > the CFRG because it pertains to both groups. > > > > The recently-revised IPsecME charter has a new work item in it: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > - IKEv2 supports mutual authentication with a shared secret, but this > > mechanism is intended for "strong" shared secrets. User-chosen > > passwords are typically of low entropy and subject to off-line > > dictionary attacks when used with this mechanism. Thus, RFC 4306 > > recommends using EAP with public-key based authentication of the > > responder instead. This approach would be typically used in > enterprise > > remote access VPN scenarios where the VPN gateway does not usually > > even have the actual passwords for all users, but instead typically > > communicates with a back-end RADIUS server. > > > > However, user-configured shared secrets are still useful for many > > other IPsec scenarios, such as authentication between two servers or > > routers. These scenarios are usually symmetric: both peers know the > > shared secret, no back-end authentication servers are involved, and > > either peer can initiate an IKEv2 SA. While it would be possible to > > use EAP in such situations (by having both peers implement both the > > EAP peer and the EAP server roles of an EAP method intended for > "weak" > > shared secrets) with the mutual EAP-based authentication work item > > (above), a simpler solution may be desirable in many situations. > > > > The WG will develop a standards-track extension to IKEv2 to allow > > mutual authentication based on "weak" (low-entropy) shared > > secrets. The goal is to avoid off-line dictionary attacks without > > requiring the use of certificates or EAP. There are many > > already-developed algorithms that can be used, and the WG would need > > to pick one that both is believed to be secure and is believed to > have > > acceptable intellectual property features. The WG would also need to > > develop the protocol to use the chosen algorithm in IKEv2 in a secure > > fashion. It is noted up front that this work item poses a higher > > chance of failing to be completed than other WG work items; this is > > balanced by the very high expected value of the extension if it is > > standardized and deployed. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > As the last paragraph says, there are multiple algorithms to choose > from. > > Different algorithms have different properties. Before the WG decides > on > > which algorithm to focus on, it needs to at least roughly decide > which > > properties are important for the new protocol. I have included the > CFRG on > > this message because they are a good source of expertise on > cryptographic > > properties. > > > > Yaron Sheffer has created a short and admittedly biased draft listing > some > > desired properties and possible candidate algorithms: > > criteria-00.txt>. > > Other people (and even Yaron) might have different views on which > > properties are important, how the properties should be ranked, the > > importance of the crypto properties of the listed algorithms, and so > on. > > > > This message is therefore meant to kick off the discussion. It is OK > for > > messages to focus on one or more of the proposed algorithms, but > getting a > > clearer view of which crypto and non-crypto properties are important > is > > probably more important first. > > > > --Paul Hoffman, Director > > --VPN Consortium > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From paul.hoffman@vpnc.org Tue Mar 2 13:37:53 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E483928C12B; Tue, 2 Mar 2010 13:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dgcFf70IjUz; Tue, 2 Mar 2010 13:37:53 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id F416C3A8CC7; Tue, 2 Mar 2010 13:37:52 -0800 (PST) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o22LbpfQ052184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 14:37:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> Date: Tue, 2 Mar 2010 13:37:50 -0800 To: "Dan Harkins" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG , cfrg@irtf.org Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 21:37:54 -0000 At 12:12 PM -0800 3/2/10, Dan Harkins wrote: > There are other criteria that should be evaluated in making a >decision, such as how well does the solution fits into IKE(v2) and >does it support "crypto agility". ...and what we mean by "agility". To some, that means "in-protocol negotiation of parameters", but to others it means "have enough variants of the algorithm with different parameters to meet some security threshold". > RFC 2409 supported negotiation of various parameters, like the group >used for the Diffie-Hellman key exchange. That was removed in RFC 4306. >All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- >criteria do some sort of discrete logarithm cryptography and therefore >it would be useful to list whether the candidate algorithm can use >any of the groups either negotiated or asserted by IKE(v2). OK, but... > For instance, I do not believe EKE is suitable for any of the >groups currently in the IANA registry of groups that can be used with >IKE(v2). The MODP groups have a generator that is a quadratic residue >which enables a passive attacker to eliminate passwords from the >dictionary if they do not decrypt to a value that is, itself, a quadratic >residue and ECP groups are unsuitable because a passive attacker can >eliminate passwords from the group if they do not decrypt to a valid point >on the curve. In either case, after seeing a trivial number of exchanges >a passive attacker is able to determine the password with high probability. Those two paragraphs don't line up. Why would you want to use the groups negotiated or demanded in the IKEv2 exchange if they allow for easier attacks? Wouldn't it be better to allow the PAKE to negotiate or demand its own, presumably better, groups? > So EKE requires a hard-coded special group to be used for its discrete >logarithm operations and since negotiation has been removed in RFC 4306 >it means that the ability to change the group to suit the policy or whim >of the user (what is popularly termed "crypto agility") goes away. EKE >also requires specification of the mode of encryption used which may or >may not be the same as the one negotiated or asserted in IKE(v2). It >could be hard-coded into the specification, like the group, but this too >further limits "crypto agility". Yaron disagreed with this assessment. I would like to hear from others with EKE experience. > The other candidates, I believe, can use the same group, whether MODP >or ECP, that the IKE(v2) exchange is using. I think it would be good to >add these criteria to the draft. See above. I think the requirement should be "crypto agility, which means X Y Z" unless that agility itself opens up a security hole, such as a downgrade attack. > Also, the table in section 5 should include IEEE 802.11s under the >"standards" column for SPSK. And the phrase "may or may not infringe on >existing patents" applies to all candidates, and frankly, to almost >everything in the IETF. It is a meaningless phrase and it would be better >to just remove it from the "IPR" column. +1 --Paul Hoffman, Director --VPN Consortium From danmcd@sun.com Tue Mar 2 13:41:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2F33A8CB8 for ; Tue, 2 Mar 2010 13:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGWOS7VObqwr for ; Tue, 2 Mar 2010 13:41:32 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 4D5E73A8839 for ; Tue, 2 Mar 2010 13:41:31 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o22LfWeK009619 for ; Tue, 2 Mar 2010 21:41:32 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id o22LfVUq021413 for ; Tue, 2 Mar 2010 16:41:31 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o22LYdG8023278 for ; Tue, 2 Mar 2010 16:34:39 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o22LYd8e023277 for ipsec@ietf.org; Tue, 2 Mar 2010 16:34:39 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Tue, 2 Mar 2010 16:34:39 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20100302213439.GJ11824@kebe.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [IPsec] Still incorrect understanding of PF_KEY in ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 21:41:33 -0000 Even as of draft-08, section 2.9: When an RFC4301-compliant IPsec subsystem receives an IP packet that matches a "protect" selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. Maintenance of a system's SPD is outside the scope of IKE (see [PFKEY] for an example programming interface, although it only applies to IKEv1), though some implementations might update their SPD in connection with the running of IKE (for an example scenario, see Section 1.1.3). is entirely incorrect about PF_KEY. PF_KEY maintains the SADB and expresses the SPD and/or triggering packet when IPsec requires a new outbound SA. Some PF_KEY extensions (notably in any KAME/WIDE-derived implementations) also maintain the SPD. And it certainly is not applicable to just IKEv1 - it was intended to allow an ARBITRARY Key Management daemon to add/delete/etc. SAs. The PF_KEY SADB_ACQUIRE message is an expression of the SPD entry for the packet. So as not to just be a whiner, I will provide a replacement first two paragraphs: When an RFC4301-compliant IPsec subsystem receives an IP packet that matches a "protect" selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. Maintenance of a system's SPD is outside the scope of IKE, though some implementations might update their SPD in connection with the running of IKE (for an example scenario, see Section 1.1.3). Traffic Selector (TS) payloads allow endpoints to communicate some of the information from their SPD to their peers. These must be communicated to IKE from the SPD (for example the PF_KEY API [PFKEY] uses the SADB_ACQUIRE message). TS payloads specify the selection criteria for packets that will be forwarded over the newly set up SA. This can serve as a consistency check in some scenarios to assure that the SPDs are consistent. In others, it guides the dynamic update of the SPD. Thanks, Dan From dharkins@lounge.org Tue Mar 2 14:25:45 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D65E28C19F for ; Tue, 2 Mar 2010 14:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I08L+NFL-ZPP for ; Tue, 2 Mar 2010 14:25:42 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 4CE8C3A8CC2 for ; Tue, 2 Mar 2010 14:25:42 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 40C7F1022404A; Tue, 2 Mar 2010 14:25:43 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 2 Mar 2010 14:25:43 -0800 (PST) Message-ID: <15cec0967fa816093466c3e2986ea728.squirrel@www.trepanning.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56E1@il-ex01.ad.checkpoint.co m> References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56E1@il-ex01.ad.checkpoint.com> Date: Tue, 2 Mar 2010 14:25:43 -0800 (PST) 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 , Paul Hoffman Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 22:25:45 -0000 Hi Yaron, The discussion is on the secure password-only authentication work item in which a password authenticated key exchange is being added directly to IKE(v2). It doesn't matter what EAP-EKE does or does not do because EAP is not being used for this work item. Now we can add some sort of negotiation or assertion of the special group required by EKE (analagous to what EAP-EKE does) but that doesn't fit well with IKEv2 today. Whether the ability to use the existing IANA group registry or whether hard-coding special groups into the exchange is less or more important is a matter of opinion and when we get to that stage we can argue about it. But right now all I'm saying is that this should be included in the criteria that we are using to evaluate candidates. Do we need a shoe horn or a jack hammer to put the exchange into IKE(v2)? Once in does it constrain us in any way? These are valid topics to discuss. Don't you agree? regards, Dan. On Tue, March 2, 2010 12:49 pm, Yaron Sheffer wrote: > Hi Dan, > > EAP-EKE supports negotiation of various algorithms, a.k.a. crypto-agility. > One of the negotiated algorithms is in fact the group being used. EAP-EKE > does require MODP groups that fulfill certain conditions, and as a result, > the document defines one such group (additional ones can be easily added). > I believe that crypto-agility is an important criterion. As to reuse of > IKEv2 groups, this is probably much less important. > > It is a bit early to speculate about IKE+EKE, since to the best of my > knowledge, it has not been written yet. > > By the way, IKEv2 does allow for negotiation of the DH group using the > ugly INVALID_KE_PAYLOAD hack. > > Thanks, > Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Tuesday, March 02, 2010 22:12 >> To: Paul Hoffman >> Cc: IPsecme WG; cfrg@irtf.org >> Subject: Re: [IPsec] Beginning discussion on secure password-only >> authentication for IKEv2 >> >> >> Hello, >> >> There are other criteria that should be evaluated in making a >> decision, such as how well does the solution fits into IKE(v2) and >> does it support "crypto agility". >> >> RFC 2409 supported negotiation of various parameters, like the group >> used for the Diffie-Hellman key exchange. That was removed in RFC 4306. >> All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- >> criteria do some sort of discrete logarithm cryptography and therefore >> it would be useful to list whether the candidate algorithm can use >> any of the groups either negotiated or asserted by IKE(v2). >> >> For instance, I do not believe EKE is suitable for any of the >> groups currently in the IANA registry of groups that can be used with >> IKE(v2). The MODP groups have a generator that is a quadratic residue >> which enables a passive attacker to eliminate passwords from the >> dictionary if they do not decrypt to a value that is, itself, a >> quadratic >> residue and ECP groups are unsuitable because a passive attacker can >> eliminate passwords from the group if they do not decrypt to a valid >> point >> on the curve. In either case, after seeing a trivial number of >> exchanges >> a passive attacker is able to determine the password with high >> probability. >> >> So EKE requires a hard-coded special group to be used for its >> discrete >> logarithm operations and since negotiation has been removed in RFC 4306 >> it means that the ability to change the group to suit the policy or >> whim >> of the user (what is popularly termed "crypto agility") goes away. EKE >> also requires specification of the mode of encryption used which may or >> may not be the same as the one negotiated or asserted in IKE(v2). It >> could be hard-coded into the specification, like the group, but this >> too >> further limits "crypto agility". >> >> The other candidates, I believe, can use the same group, whether MODP >> or ECP, that the IKE(v2) exchange is using. I think it would be good to >> add these criteria to the draft. >> >> Also, the table in section 5 should include IEEE 802.11s under the >> "standards" column for SPSK. And the phrase "may or may not infringe on >> existing patents" applies to all candidates, and frankly, to almost >> everything in the IETF. It is a meaningless phrase and it would be >> better >> to just remove it from the "IPR" column. >> >> regards, >> >> Dan. >> >> On Mon, March 1, 2010 4:34 pm, Paul Hoffman wrote: >> > Greetings again. This message is cross-posted to both the IPsecME WG >> and >> > the CFRG because it pertains to both groups. >> > >> > The recently-revised IPsecME charter has a new work item in it: >> > >> > ========== >> > - IKEv2 supports mutual authentication with a shared secret, but this >> > mechanism is intended for "strong" shared secrets. User-chosen >> > passwords are typically of low entropy and subject to off-line >> > dictionary attacks when used with this mechanism. Thus, RFC 4306 >> > recommends using EAP with public-key based authentication of the >> > responder instead. This approach would be typically used in >> enterprise >> > remote access VPN scenarios where the VPN gateway does not usually >> > even have the actual passwords for all users, but instead typically >> > communicates with a back-end RADIUS server. >> > >> > However, user-configured shared secrets are still useful for many >> > other IPsec scenarios, such as authentication between two servers or >> > routers. These scenarios are usually symmetric: both peers know the >> > shared secret, no back-end authentication servers are involved, and >> > either peer can initiate an IKEv2 SA. While it would be possible to >> > use EAP in such situations (by having both peers implement both the >> > EAP peer and the EAP server roles of an EAP method intended for >> "weak" >> > shared secrets) with the mutual EAP-based authentication work item >> > (above), a simpler solution may be desirable in many situations. >> > >> > The WG will develop a standards-track extension to IKEv2 to allow >> > mutual authentication based on "weak" (low-entropy) shared >> > secrets. The goal is to avoid off-line dictionary attacks without >> > requiring the use of certificates or EAP. There are many >> > already-developed algorithms that can be used, and the WG would need >> > to pick one that both is believed to be secure and is believed to >> have >> > acceptable intellectual property features. The WG would also need to >> > develop the protocol to use the chosen algorithm in IKEv2 in a secure >> > fashion. It is noted up front that this work item poses a higher >> > chance of failing to be completed than other WG work items; this is >> > balanced by the very high expected value of the extension if it is >> > standardized and deployed. >> > ========== >> > >> > As the last paragraph says, there are multiple algorithms to choose >> from. >> > Different algorithms have different properties. Before the WG decides >> on >> > which algorithm to focus on, it needs to at least roughly decide >> which >> > properties are important for the new protocol. I have included the >> CFRG on >> > this message because they are a good source of expertise on >> cryptographic >> > properties. >> > >> > Yaron Sheffer has created a short and admittedly biased draft listing >> some >> > desired properties and possible candidate algorithms: >> > > criteria-00.txt>. >> > Other people (and even Yaron) might have different views on which >> > properties are important, how the properties should be ranked, the >> > importance of the crypto properties of the listed algorithms, and so >> on. >> > >> > This message is therefore meant to kick off the discussion. It is OK >> for >> > messages to focus on one or more of the proposed algorithms, but >> getting a >> > clearer view of which crypto and non-crypto properties are important >> is >> > probably more important first. >> > >> > --Paul Hoffman, Director >> > --VPN Consortium >> > _______________________________________________ >> > 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 >> >> Scanned by Check Point Total Security Gateway. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Tue Mar 2 15:00:31 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D803A7A68 for ; Tue, 2 Mar 2010 15:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emSxtuEu5xmU for ; Tue, 2 Mar 2010 15:00:31 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 0917A3A7870 for ; Tue, 2 Mar 2010 15:00:31 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5C1E51022404A; Tue, 2 Mar 2010 14:54:43 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 2 Mar 2010 14:54:43 -0800 (PST) Message-ID: In-Reply-To: References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> Date: Tue, 2 Mar 2010 14:54:43 -0800 (PST) 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 , cfrg@irtf.org, Dan Harkins Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 23:00:31 -0000 Hi Paul, On Tue, March 2, 2010 1:37 pm, Paul Hoffman wrote: [snip] >> RFC 2409 supported negotiation of various parameters, like the group >>used for the Diffie-Hellman key exchange. That was removed in RFC 4306. >>All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- >>criteria do some sort of discrete logarithm cryptography and therefore >>it would be useful to list whether the candidate algorithm can use >>any of the groups either negotiated or asserted by IKE(v2). > > OK, but... > >> For instance, I do not believe EKE is suitable for any of the >>groups currently in the IANA registry of groups that can be used with >>IKE(v2). The MODP groups have a generator that is a quadratic residue >>which enables a passive attacker to eliminate passwords from the >>dictionary if they do not decrypt to a value that is, itself, a quadratic >>residue and ECP groups are unsuitable because a passive attacker can >>eliminate passwords from the group if they do not decrypt to a valid >> point >>on the curve. In either case, after seeing a trivial number of exchanges >>a passive attacker is able to determine the password with high >> probability. > > Those two paragraphs don't line up. Why would you want to use the groups > negotiated or demanded in the IKEv2 exchange if they allow for easier > attacks? Wouldn't it be better to allow the PAKE to negotiate or demand > its own, presumably better, groups? The candidate exchanges all rely on the "hard problem" of doing a discrete logarithm in one of the defined groups. It's the same "hard problem" that makes the Diffie-Hellman portion of IKE secure. If the group negotiated or demanded in IKE allows for an "easier attack" then it shouldn't be used in the IKE exchange to do the Diffie-Hellman. And if the group is good enough to use for the Diffie-Hellman key exchange then, by definition, it is good enough for password authentication. If someone wants to use a 521-bit ECP group for the Diffie-Hellman key exchange then requiring him to use a 2048-bit MODP group for authentication seems a bit odd and constraining. It would make more sense, to me at least, if the same 521-bit ECP group was used for authentication. Substitute the group based on your own policy or whim-- 192-bit ECP, 8192-bit MODP, 1024-bit MODP-- and it's still odd and constraining to be forced to use a different one for authentication. I think there is value in being able to use the same group (a lesson learned from IKEv1 is that not everything needs to be negotiated and the increase in complexity just isn't worth it). Some may find value in negotiating groups separately. Whatever. But I think this should be included in the criteria for selection so we can discuss the pros and cons. >> So EKE requires a hard-coded special group to be used for its discrete >>logarithm operations and since negotiation has been removed in RFC 4306 >>it means that the ability to change the group to suit the policy or whim >>of the user (what is popularly termed "crypto agility") goes away. EKE >>also requires specification of the mode of encryption used which may or >>may not be the same as the one negotiated or asserted in IKE(v2). It >>could be hard-coded into the specification, like the group, but this too >>further limits "crypto agility". > > Yaron disagreed with this assessment. I would like to hear from others > with EKE experience. Yaron points out that EAP-EKE negotiates the special group but we're not using EAP here so the point he makes is neither here nor there. >> The other candidates, I believe, can use the same group, whether MODP >>or ECP, that the IKE(v2) exchange is using. I think it would be good to >>add these criteria to the draft. > > See above. I think the requirement should be "crypto agility, which means > X Y Z" unless that agility itself opens up a security hole, such as a > downgrade attack. No downgrade attacks. I agree. An attacker will go after the weakest point. Which in this case has to be repeated active guessing attack (which should be easy enough to notice and deal with). regards, Dan. From Black_David@emc.com Tue Mar 2 15:49:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D8128C196; Tue, 2 Mar 2010 15:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11bJm-oW1nU2; Tue, 2 Mar 2010 15:49:34 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id B572328C0DC; Tue, 2 Mar 2010 15:49:33 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o22NnYSa031645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 18:49:34 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 2 Mar 2010 18:49:31 -0500 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o22NnU9Q017153; Tue, 2 Mar 2010 18:49:30 -0500 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.202]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 18:49:30 -0500 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: Tue, 2 Mar 2010 18:49:29 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6XFd06v4lPJs6SDyaR07JlFPXKwAA/HCA References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> From: To: , X-OriginalArrivalTime: 02 Mar 2010 23:49:30.0279 (UTC) FILETIME=[0048F370:01CABA63] X-EMM-EM: Active Cc: ipsec@ietf.org, cfrg@irtf.org, Black_David@emc.com Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 23:49:35 -0000 Dan, > >> For instance, I do not believe EKE is suitable for any of the > >>groups currently in the IANA registry of groups that can be used = with > >>IKE(v2). There was an analogous experience with SRP for iSCSI - completely = different groups were used up to 2048 bits and beyond there, the modulus = primes from the larger IKEv2 groups were combined with different = generators (i.e., not 2) - see Appendix A of RFC 3723. [... snip ...] OTOH, I think you've oversimplified here ... > The candidate exchanges all rely on the "hard problem" of doing a > discrete logarithm in one of the defined groups. It's the same "hard > problem" that makes the Diffie-Hellman portion of IKE secure. If the > group negotiated or demanded in IKE allows for an "easier attack" then > it shouldn't be used in the IKE exchange to do the Diffie-Hellman.=20 If I follow your logic, I think you're arguing that because the existing = groups allow easier attacks on password authentication (e.g., based on = checks on what a guessed password decrypts to) then they allow easier = attacks on IKE with existing authentication, *hence* those groups are = unacceptable to use with IKE. I think the *hence* is off the mark due = to the much larger candidate search space when other techniques (e.g., = certificate-based) are used to authenticate. > And > if the group is good enough to use for the Diffie-Hellman key exchange > then, by definition, it is good enough for password authentication. No argument here, but I don't think that statement implies its converse. [... snip ..] > I think there is value in being able to use the same group (a lesson > learned from IKEv1 is that not everything needs to be negotiated and = the > increase in complexity just isn't worth it). Some may find value in > negotiating groups separately. Whatever. But I think this should be > included in the criteria for selection so we can discuss the pros and > cons. I would agree with that - the ability to use the existing groups should = be a plus for evaluation. I'd also suggest that if new groups are defined for password = authentication, those groups ought to be usable for IKE as well = *provided that* the resulting negotiation complexity doesn't get out of = hand. I don't think we can retire/replace the existing groups, and I = don't think you're suggesting that. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 black_david@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Dan Harkins > Sent: Tuesday, March 02, 2010 5:55 PM > To: Paul Hoffman > Cc: IPsecme WG; cfrg@irtf.org; Dan Harkins > Subject: Re: [IPsec] Beginning discussion on secure password-only = authentication for IKEv2 >=20 >=20 > Hi Paul, >=20 > On Tue, March 2, 2010 1:37 pm, Paul Hoffman wrote: > [snip] > >> RFC 2409 supported negotiation of various parameters, like the = group > >>used for the Diffie-Hellman key exchange. That was removed in RFC = 4306. > >>All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- > >>criteria do some sort of discrete logarithm cryptography and = therefore > >>it would be useful to list whether the candidate algorithm can use > >>any of the groups either negotiated or asserted by IKE(v2). > > > > OK, but... > > > >> For instance, I do not believe EKE is suitable for any of the > >>groups currently in the IANA registry of groups that can be used = with > >>IKE(v2). The MODP groups have a generator that is a quadratic = residue > >>which enables a passive attacker to eliminate passwords from the > >>dictionary if they do not decrypt to a value that is, itself, a = quadratic > >>residue and ECP groups are unsuitable because a passive attacker can > >>eliminate passwords from the group if they do not decrypt to a valid > >> point > >>on the curve. In either case, after seeing a trivial number of = exchanges > >>a passive attacker is able to determine the password with high > >> probability. > > > > Those two paragraphs don't line up. Why would you want to use the = groups > > negotiated or demanded in the IKEv2 exchange if they allow for = easier > > attacks? Wouldn't it be better to allow the PAKE to negotiate or = demand > > its own, presumably better, groups? >=20 > The candidate exchanges all rely on the "hard problem" of doing a > discrete logarithm in one of the defined groups. It's the same "hard > problem" that makes the Diffie-Hellman portion of IKE secure. If the > group negotiated or demanded in IKE allows for an "easier attack" then > it shouldn't be used in the IKE exchange to do the Diffie-Hellman. And > if the group is good enough to use for the Diffie-Hellman key exchange > then, by definition, it is good enough for password authentication. >=20 > If someone wants to use a 521-bit ECP group for the Diffie-Hellman = key > exchange then requiring him to use a 2048-bit MODP group for = authentication > seems a bit odd and constraining. It would make more sense, to me at = least, > if the same 521-bit ECP group was used for authentication. Substitute = the > group based on your own policy or whim-- 192-bit ECP, 8192-bit MODP, > 1024-bit MODP-- and it's still odd and constraining to be forced to = use > a different one for authentication. >=20 > I think there is value in being able to use the same group (a lesson > learned from IKEv1 is that not everything needs to be negotiated and = the > increase in complexity just isn't worth it). Some may find value in > negotiating groups separately. Whatever. But I think this should be > included in the criteria for selection so we can discuss the pros and > cons. >=20 > >> So EKE requires a hard-coded special group to be used for its = discrete > >>logarithm operations and since negotiation has been removed in RFC = 4306 > >>it means that the ability to change the group to suit the policy or = whim > >>of the user (what is popularly termed "crypto agility") goes away. = EKE > >>also requires specification of the mode of encryption used which may = or > >>may not be the same as the one negotiated or asserted in IKE(v2). It > >>could be hard-coded into the specification, like the group, but this = too > >>further limits "crypto agility". > > > > Yaron disagreed with this assessment. I would like to hear from = others > > with EKE experience. >=20 > Yaron points out that EAP-EKE negotiates the special group but we're > not using EAP here so the point he makes is neither here nor there. >=20 > >> The other candidates, I believe, can use the same group, whether = MODP > >>or ECP, that the IKE(v2) exchange is using. I think it would be good = to > >>add these criteria to the draft. > > > > See above. I think the requirement should be "crypto agility, which = means > > X Y Z" unless that agility itself opens up a security hole, such as = a > > downgrade attack. >=20 > No downgrade attacks. I agree. An attacker will go after the weakest > point. Which in this case has to be repeated active guessing attack > (which should be easy enough to notice and deal with). >=20 > regards, >=20 > Dan. >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From smb@cs.columbia.edu Tue Mar 2 16:11:50 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF2B3A8CC0 for ; Tue, 2 Mar 2010 16:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bNS7zzXsDdB for ; Tue, 2 Mar 2010 16:11:49 -0800 (PST) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 801C33A7D1B for ; Tue, 2 Mar 2010 16:11:49 -0800 (PST) Received: by machshav.com (Postfix, from userid 512) id 87DA352D3FB; Tue, 2 Mar 2010 19:11:54 -0500 (EST) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 38E1652D3E9; Tue, 2 Mar 2010 19:11:54 -0500 (EST) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 6DEC2293D07; Tue, 2 Mar 2010 19:11:47 -0500 (EST) Date: Tue, 2 Mar 2010 19:11:46 -0500 From: "Steven M. Bellovin" To: "Dan Harkins" Message-ID: <20100302191146.1fc08316@yellowstone.machshav.com> In-Reply-To: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> Organization: Columbia University X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPsecme WG , cfrg@irtf.org, Paul Hoffman Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 00:11:50 -0000 On Tue, 2 Mar 2010 12:12:19 -0800 (PST) "Dan Harkins" wrote: > > Hello, > > There are other criteria that should be evaluated in making a > decision, such as how well does the solution fits into IKE(v2) and > does it support "crypto agility". > There are certainly many things that need to be considered, including how, specifically, a particular algorithm can be embedded into an engineered framework. Any solution that requires a single, fixed-for-all-time modulus and base is, to me, unacceptable. (That was the problem with SKIP, way back when.) From dharkins@lounge.org Tue Mar 2 16:55:32 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53DC23A89F9 for ; Tue, 2 Mar 2010 16:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLjC+pwE11cD for ; Tue, 2 Mar 2010 16:55:32 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 326EF3A8881 for ; Tue, 2 Mar 2010 16:55:32 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 826461022404A; Tue, 2 Mar 2010 16:48:07 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 2 Mar 2010 16:48:07 -0800 (PST) Message-ID: In-Reply-To: References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> Date: Tue, 2 Mar 2010 16:48:07 -0800 (PST) From: "Dan Harkins" To: Black_David@emc.com 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, cfrg@irtf.org, paul.hoffman@vpnc.org Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 00:55:32 -0000 Hi David, On Tue, March 2, 2010 3:49 pm, Black_David@emc.com wrote: [snip] > > OTOH, I think you've oversimplified here ... > >> The candidate exchanges all rely on the "hard problem" of doing a >> discrete logarithm in one of the defined groups. It's the same "hard >> problem" that makes the Diffie-Hellman portion of IKE secure. If the >> group negotiated or demanded in IKE allows for an "easier attack" then >> it shouldn't be used in the IKE exchange to do the Diffie-Hellman. > > If I follow your logic, I think you're arguing that because the existing > groups allow easier attacks on password authentication (e.g., based on > checks on what a guessed password decrypts to) then they allow easier > attacks on IKE with existing authentication, *hence* those groups are > unacceptable to use with IKE. I think the *hence* is off the mark due to > the much larger candidate search space when other techniques (e.g., > certificate-based) are used to authenticate. That wasn't what I was arguing. I think all the candidate exchanges are based on the computational Diffie-Hellman assumption. And the work factor to attack them on that front should be the same as the work factor to attack a standard Diffie-Hellman key exchange. Or am I missing something? I don't think any of the currently-defined groups are unacceptable to use with IKE. But hypothetically, if there was some group defined that allowed an easy attack (the order was unacceptably small, for instance) then it would be unsuitable for IKE just like it would be unsuitable for any of the candidate password authentication schemes. For these password authentication schemes to be secure, the only method of attack is repeated active guessing attacks of the password (the advantage an attacker gains is through interaction, not computation). An "easier attack" is an off-line dictionary attack to learn the password (the advantage gained is through computation) and using any of the groups in IKE(v2)'s IANA registry with EKE would enable a dictionary attack. But the attacker doesn't learn the ephemeral secret that results from EKE, the CDH assumption still applies. The issue isn't with the group, per se, it's with the (mis)use of the group. regards, Dan. From smb@cs.columbia.edu Tue Mar 2 16:58:42 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9FC28C287 for ; Tue, 2 Mar 2010 16:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEjHzkaf6eVZ for ; Tue, 2 Mar 2010 16:58:41 -0800 (PST) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 2EF713A8863 for ; Tue, 2 Mar 2010 16:58:41 -0800 (PST) Received: by machshav.com (Postfix, from userid 512) id D837E52D3FB; Tue, 2 Mar 2010 19:58:43 -0500 (EST) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 627E752D3E9; Tue, 2 Mar 2010 19:58:43 -0500 (EST) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 47832293D07; Tue, 2 Mar 2010 19:58:36 -0500 (EST) Date: Tue, 2 Mar 2010 19:58:35 -0500 From: "Steven M. Bellovin" To: "Dan Harkins" Message-ID: <20100302195835.07e66c4e@yellowstone.machshav.com> In-Reply-To: References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> Organization: Columbia University X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, cfrg@irtf.org, Black_David@emc.com, paul.hoffman@vpnc.org Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 00:58:42 -0000 On Tue, 2 Mar 2010 16:48:07 -0800 (PST) "Dan Harkins" wrote: > > Hi David, > > > On Tue, March 2, 2010 3:49 pm, Black_David@emc.com wrote: > [snip] > > > > OTOH, I think you've oversimplified here ... > > > >> The candidate exchanges all rely on the "hard problem" of doing a > >> discrete logarithm in one of the defined groups. It's the same > >> "hard problem" that makes the Diffie-Hellman portion of IKE > >> secure. If the group negotiated or demanded in IKE allows for an > >> "easier attack" then it shouldn't be used in the IKE exchange to > >> do the Diffie-Hellman. > > > > If I follow your logic, I think you're arguing that because the > > existing groups allow easier attacks on password authentication > > (e.g., based on checks on what a guessed password decrypts to) then > > they allow easier attacks on IKE with existing authentication, > > *hence* those groups are unacceptable to use with IKE. I think the > > *hence* is off the mark due to the much larger candidate search > > space when other techniques (e.g., certificate-based) are used to > > authenticate. > > That wasn't what I was arguing. I think all the candidate exchanges > are based on the computational Diffie-Hellman assumption. And the > work factor to attack them on that front should be the same as the > work factor to attack a standard Diffie-Hellman key exchange. Or am > I missing something? > > I don't think any of the currently-defined groups are unacceptable > to use with IKE. But hypothetically, if there was some group defined > that allowed an easy attack (the order was unacceptably small, for > instance) then it would be unsuitable for IKE just like it would be > unsuitable for any of the candidate password authentication schemes. > > For these password authentication schemes to be secure, the only > method of attack is repeated active guessing attacks of the password > (the advantage an attacker gains is through interaction, not > computation). An "easier attack" is an off-line dictionary attack to > learn the password (the advantage gained is through computation) and > using any of the groups in IKE(v2)'s IANA registry with EKE would > enable a dictionary attack. But the attacker doesn't learn the > ephemeral secret that results from EKE, the CDH assumption still > applies. The issue isn't with the group, per se, it's with the > (mis)use of the group. > Right. In the original EKE paper, we called this a "partition attack". There are others possible; it's important to take care to avoid them. For example, suppose that we wanted a ~2048-bit -- 256 byte -- modulus. Choosing a modulus of 2040 bits, though about the same difficulty when it comes to solving discrete log, is unacceptable for EKE, because in a correct guess the high-order byte would be all zeros; an incorrect guess would, with probability 255/256, let you rule out a candidate password. A good EKE modulus would be close enough to 2^2048 to have a negligible probability of a decryption with a bad guess being in the range [p, 2^2048-1]. In other words, good moduli for EKE have specialized properties. From Black_David@emc.com Tue Mar 2 17:18:01 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB90B28C1F8; Tue, 2 Mar 2010 17:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFbs7zM82g6p; Tue, 2 Mar 2010 17:17:59 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id B92113A8CFF; Tue, 2 Mar 2010 17:17:59 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o231HrYV019757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 20:17:53 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 2 Mar 2010 20:17:45 -0500 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o231HjqS032202; Tue, 2 Mar 2010 20:17:45 -0500 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.202]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 20:17:45 -0500 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, 2 Mar 2010 20:17:44 -0500 Message-ID: In-Reply-To: <20100302195835.07e66c4e@yellowstone.machshav.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6bKy+5oQXVB2WTXSuRtcZQnK7jAAAbysg References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> <20100302195835.07e66c4e@yellowstone.machshav.com> From: To: , X-OriginalArrivalTime: 03 Mar 2010 01:17:45.0097 (UTC) FILETIME=[543E0F90:01CABA6F] X-EMM-EM: Active Cc: ipsec@ietf.org, cfrg@irtf.org Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 01:18:01 -0000 > > >> The candidate exchanges all rely on the "hard problem" of doing a > > >> discrete logarithm in one of the defined groups. It's the same > > >> "hard problem" that makes the Diffie-Hellman portion of IKE > > >> secure. If the group negotiated or demanded in IKE allows for an > > >> "easier attack" then it shouldn't be used in the IKE exchange to > > >> do the Diffie-Hellman. > > > > > > If I follow your logic, I think you're arguing that because the > > > existing groups allow easier attacks on password authentication > > > (e.g., based on checks on what a guessed password decrypts to) then > > > they allow easier attacks on IKE with existing authentication, > > > *hence* those groups are unacceptable to use with IKE. I think the > > > *hence* is off the mark due to the much larger candidate search > > > space when other techniques (e.g., certificate-based) are used to > > > authenticate. > > > > That wasn't what I was arguing. I think all the candidate exchanges > > are based on the computational Diffie-Hellman assumption. And the > > work factor to attack them on that front should be the same as the > > work factor to attack a standard Diffie-Hellman key exchange. Or am > > I missing something? > > > > I don't think any of the currently-defined groups are unacceptable > > to use with IKE. But hypothetically, if there was some group defined > > that allowed an easy attack (the order was unacceptably small, for > > instance) then it would be unsuitable for IKE just like it would be > > unsuitable for any of the candidate password authentication schemes. > > > > For these password authentication schemes to be secure, the only > > method of attack is repeated active guessing attacks of the password > > (the advantage an attacker gains is through interaction, not > > computation). An "easier attack" is an off-line dictionary attack to > > learn the password (the advantage gained is through computation) and > > using any of the groups in IKE(v2)'s IANA registry with EKE would > > enable a dictionary attack. But the attacker doesn't learn the > > ephemeral secret that results from EKE, the CDH assumption still > > applies. The issue isn't with the group, per se, it's with the > > (mis)use of the group. > > > Right. In the original EKE paper, we called this a "partition > attack". There are others possible; it's important to take care to > avoid them. For example, suppose that we wanted a ~2048-bit -- 256 byte > -- modulus. Choosing a modulus of 2040 bits, though about the same > difficulty when it comes to solving discrete log, is unacceptable for > EKE, because in a correct guess the high-order byte would be all zeros; > an incorrect guess would, with probability 255/256, let you rule out a > candidate password. A good EKE modulus would be close enough to 2^2048 > to have a negligible probability of a decryption with a bad guess being > in the range [p, 2^2048-1]. In other words, good moduli for EKE have > specialized properties. That's roughly what I understood - good groups for EKE should be good groups for IKE, but good groups for IKE (e.g., the existing groups) are not necessarily good groups for EKE because they may not have the specialized properties required to block additional attacks on EKE that don't apply to IKE. It appears like Dan agrees, so I may have misinterpreted what he originally wrote. Thanks, --David From yaronf@checkpoint.com Tue Mar 2 23:03:55 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4918728C14B for ; Tue, 2 Mar 2010 23:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.13 X-Spam-Level: X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV5lZUgYE0wn for ; Tue, 2 Mar 2010 23:03:53 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 833E428C223 for ; Tue, 2 Mar 2010 23:03:53 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2373rsd012486; Wed, 3 Mar 2010 09:03:53 +0200 (IST) X-CheckPoint: {4B8E089A-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 3 Mar 2010 09:04:13 +0200 From: Yaron Sheffer To: Dan Harkins Date: Wed, 3 Mar 2010 09:04:12 +0200 Thread-Topic: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6V1qhDsqRwC78SwmBTqGEKDF1wwARtSig Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56F1@il-ex01.ad.checkpoint.com> References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56E1@il-ex01.ad.checkpoint.com> <15cec0967fa816093466c3e2986ea728.squirrel@www.trepanning.net> In-Reply-To: <15cec0967fa816093466c3e2986ea728.squirrel@www.trepanning.net> 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 , Paul Hoffman Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 07:03:55 -0000 Hi Dan, I consider reuse of DH groups a minor issue at best. But yes, it's a valid = criterion. Thanks, Yaron > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Wednesday, March 03, 2010 0:26 > To: Yaron Sheffer > Cc: Dan Harkins; Paul Hoffman; IPsecme WG > Subject: Re: [IPsec] Beginning discussion on secure password-only > authentication for IKEv2 >=20 >=20 > Hi Yaron, >=20 > The discussion is on the secure password-only authentication work > item > in which a password authenticated key exchange is being added directly > to IKE(v2). It doesn't matter what EAP-EKE does or does not do because > EAP is not being used for this work item. >=20 > Now we can add some sort of negotiation or assertion of the special > group required by EKE (analagous to what EAP-EKE does) but that doesn't > fit well with IKEv2 today. >=20 > Whether the ability to use the existing IANA group registry or > whether > hard-coding special groups into the exchange is less or more important > is a matter of opinion and when we get to that stage we can argue about > it. But right now all I'm saying is that this should be included in the > criteria that we are using to evaluate candidates. Do we need a shoe > horn > or a jack hammer to put the exchange into IKE(v2)? Once in does it > constrain us in any way? These are valid topics to discuss. Don't you > agree? >=20 > regards, >=20 > Dan. >=20 > On Tue, March 2, 2010 12:49 pm, Yaron Sheffer wrote: > > Hi Dan, > > > > EAP-EKE supports negotiation of various algorithms, a.k.a. crypto- > agility. > > One of the negotiated algorithms is in fact the group being used. > EAP-EKE > > does require MODP groups that fulfill certain conditions, and as a > result, > > the document defines one such group (additional ones can be easily > added). > > I believe that crypto-agility is an important criterion. As to reuse > of > > IKEv2 groups, this is probably much less important. > > > > It is a bit early to speculate about IKE+EKE, since to the best of my > > knowledge, it has not been written yet. > > > > By the way, IKEv2 does allow for negotiation of the DH group using > the > > ugly INVALID_KE_PAYLOAD hack. > > > > Thanks, > > Yaron > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >> Of Dan Harkins > >> Sent: Tuesday, March 02, 2010 22:12 > >> To: Paul Hoffman > >> Cc: IPsecme WG; cfrg@irtf.org > >> Subject: Re: [IPsec] Beginning discussion on secure password-only > >> authentication for IKEv2 > >> > >> > >> Hello, > >> > >> There are other criteria that should be evaluated in making a > >> decision, such as how well does the solution fits into IKE(v2) and > >> does it support "crypto agility". > >> > >> RFC 2409 supported negotiation of various parameters, like the > group > >> used for the Diffie-Hellman key exchange. That was removed in RFC > 4306. > >> All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- > >> criteria do some sort of discrete logarithm cryptography and > therefore > >> it would be useful to list whether the candidate algorithm can use > >> any of the groups either negotiated or asserted by IKE(v2). > >> > >> For instance, I do not believe EKE is suitable for any of the > >> groups currently in the IANA registry of groups that can be used > with > >> IKE(v2). The MODP groups have a generator that is a quadratic > residue > >> which enables a passive attacker to eliminate passwords from the > >> dictionary if they do not decrypt to a value that is, itself, a > >> quadratic > >> residue and ECP groups are unsuitable because a passive attacker can > >> eliminate passwords from the group if they do not decrypt to a valid > >> point > >> on the curve. In either case, after seeing a trivial number of > >> exchanges > >> a passive attacker is able to determine the password with high > >> probability. > >> > >> So EKE requires a hard-coded special group to be used for its > >> discrete > >> logarithm operations and since negotiation has been removed in RFC > 4306 > >> it means that the ability to change the group to suit the policy or > >> whim > >> of the user (what is popularly termed "crypto agility") goes away. > EKE > >> also requires specification of the mode of encryption used which may > or > >> may not be the same as the one negotiated or asserted in IKE(v2). It > >> could be hard-coded into the specification, like the group, but this > >> too > >> further limits "crypto agility". > >> > >> The other candidates, I believe, can use the same group, whether > MODP > >> or ECP, that the IKE(v2) exchange is using. I think it would be good > to > >> add these criteria to the draft. > >> > >> Also, the table in section 5 should include IEEE 802.11s under the > >> "standards" column for SPSK. And the phrase "may or may not infringe > on > >> existing patents" applies to all candidates, and frankly, to almost > >> everything in the IETF. It is a meaningless phrase and it would be > >> better > >> to just remove it from the "IPR" column. > >> > >> regards, > >> > >> Dan. > >> > >> On Mon, March 1, 2010 4:34 pm, Paul Hoffman wrote: > >> > Greetings again. This message is cross-posted to both the IPsecME > WG > >> and > >> > the CFRG because it pertains to both groups. > >> > > >> > The recently-revised IPsecME charter has a new work item in it: > >> > > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > - IKEv2 supports mutual authentication with a shared secret, but > this > >> > mechanism is intended for "strong" shared secrets. User-chosen > >> > passwords are typically of low entropy and subject to off-line > >> > dictionary attacks when used with this mechanism. Thus, RFC 4306 > >> > recommends using EAP with public-key based authentication of the > >> > responder instead. This approach would be typically used in > >> enterprise > >> > remote access VPN scenarios where the VPN gateway does not usually > >> > even have the actual passwords for all users, but instead > typically > >> > communicates with a back-end RADIUS server. > >> > > >> > However, user-configured shared secrets are still useful for many > >> > other IPsec scenarios, such as authentication between two servers > or > >> > routers. These scenarios are usually symmetric: both peers know > the > >> > shared secret, no back-end authentication servers are involved, > and > >> > either peer can initiate an IKEv2 SA. While it would be possible > to > >> > use EAP in such situations (by having both peers implement both > the > >> > EAP peer and the EAP server roles of an EAP method intended for > >> "weak" > >> > shared secrets) with the mutual EAP-based authentication work item > >> > (above), a simpler solution may be desirable in many situations. > >> > > >> > The WG will develop a standards-track extension to IKEv2 to allow > >> > mutual authentication based on "weak" (low-entropy) shared > >> > secrets. The goal is to avoid off-line dictionary attacks without > >> > requiring the use of certificates or EAP. There are many > >> > already-developed algorithms that can be used, and the WG would > need > >> > to pick one that both is believed to be secure and is believed to > >> have > >> > acceptable intellectual property features. The WG would also need > to > >> > develop the protocol to use the chosen algorithm in IKEv2 in a > secure > >> > fashion. It is noted up front that this work item poses a higher > >> > chance of failing to be completed than other WG work items; this > is > >> > balanced by the very high expected value of the extension if it is > >> > standardized and deployed. > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > >> > As the last paragraph says, there are multiple algorithms to > choose > >> from. > >> > Different algorithms have different properties. Before the WG > decides > >> on > >> > which algorithm to focus on, it needs to at least roughly decide > >> which > >> > properties are important for the new protocol. I have included the > >> CFRG on > >> > this message because they are a good source of expertise on > >> cryptographic > >> > properties. > >> > > >> > Yaron Sheffer has created a short and admittedly biased draft > listing > >> some > >> > desired properties and possible candidate algorithms: > >> > >> criteria-00.txt>. > >> > Other people (and even Yaron) might have different views on which > >> > properties are important, how the properties should be ranked, the > >> > importance of the crypto properties of the listed algorithms, and > so > >> on. > >> > > >> > This message is therefore meant to kick off the discussion. It is > OK > >> for > >> > messages to focus on one or more of the proposed algorithms, but > >> getting a > >> > clearer view of which crypto and non-crypto properties are > important > >> is > >> > probably more important first. > >> > > >> > --Paul Hoffman, Director > >> > --VPN Consortium > >> > _______________________________________________ > >> > 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 > >> > >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Wed Mar 3 00:14:09 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827D828C2CD; Wed, 3 Mar 2010 00:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9O8UYwTmzcF; Wed, 3 Mar 2010 00:14:06 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 90A4C28C2D1; Wed, 3 Mar 2010 00:14:03 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o238E2sd020886; Wed, 3 Mar 2010 10:14:03 +0200 (IST) X-CheckPoint: {4B8E190C-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 3 Mar 2010 10:14:22 +0200 From: Yoav Nir To: Yaron Sheffer Date: Wed, 3 Mar 2010 10:14:07 +0200 Thread-Topic: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6qYdfAdfTFsYcTXS1Qz8cnFDpQw== Message-ID: References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56E1@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56E1@il-ex01.ad.checkpoint.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 , "cfrg@irtf.org" , Dan Harkins , Paul Hoffman Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 08:14:09 -0000 Yes, you can sort-of negotiate DH groups, but you don't have the "New Group= Mode" that we had in section 5.6 or RFC 2409. So with RFC 4306, you're stuck with only those groups that appear in the IA= NA registry, rather than your own pet DH groups. On Mar 2, 2010, at 10:49 PM, Yaron Sheffer wrote: >=20 >=20 > By the way, IKEv2 does allow for negotiation of the DH group using the ug= ly INVALID_KE_PAYLOAD hack. >=20 >=20 >> RFC 2409 supported negotiation of various parameters, like the group >> used for the Diffie-Hellman key exchange. That was removed in RFC 4306. >> All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- >> criteria do some sort of discrete logarithm cryptography and therefore >> it would be useful to list whether the candidate algorithm can use >> any of the groups either negotiated or asserted by IKE(v2). From kivinen@iki.fi Wed Mar 3 03:30:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0173A8626; Wed, 3 Mar 2010 03:30:34 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4nKTJBflGzw; Wed, 3 Mar 2010 03:30:33 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 203163A8D8B; Wed, 3 Mar 2010 03:30:32 -0800 (PST) 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 o23BUPVh017043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Mar 2010 13:30:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o23BUMTn022580; Wed, 3 Mar 2010 13:30:22 +0200 (EET) 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: <19342.18510.893700.928436@fireball.kivinen.iki.fi> Date: Wed, 3 Mar 2010 13:30:22 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB56E1@il-ex01.ad.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 , Paul Hoffman , "cfrg@irtf.org" , Dan Harkins Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 11:30:34 -0000 Yoav Nir writes: > Yes, you can sort-of negotiate DH groups, but you don't have the > "New Group Mode" that we had in section 5.6 or RFC 2409. Yes, that was left out but as it was seen that nobody will accept new group proposed from unknown party without checking it first, and checking that the modulus is prime and otherwise secure is quite hard task... > So with RFC 4306, you're stuck with only those groups that appear in > the IANA registry, rather than your own pet DH groups. That is not completely true. RFC4306 has a SHOULD requirement which says: ---------------------------------------------------------------------- ... In support of this goal, all implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie- Hellman (DH) parameters (the generator, modulus, and exponent lengths and values) for new DH groups. Implementations SHOULD provide a management interface via which these parameters and the associated transform IDs may be entered (by a user or system administrator), to enable negotiating such groups. ---------------------------------------------------------------------- I.e. as it was seen that implementations will not want to accept group they have not verified, and that verification is computationally costly operation, it will not be done online. So if you want to use your own private groups you use off-line communication and communicate the group parameters to the other side and both ends store that group parameters along with the group number allocated from private number space, and then you can use the privete group. -- kivinen@iki.fi From uri@ll.mit.edu Tue Mar 2 10:03:45 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95F528C1FE; Tue, 2 Mar 2010 10:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdz0zqSnBJwQ; Tue, 2 Mar 2010 10:03:43 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id A31EE28C1FC; Tue, 2 Mar 2010 10:03:43 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id o22I3bmC010198; Tue, 2 Mar 2010 13:03:41 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'paul.hoffman@vpnc.org'" , "'Hannes.Tschofenig@gmx.net'" Date: Tue, 2 Mar 2010 13:03:40 -0500 Thread-Topic: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6MQWuh8nCpVjYR+SBTYwCj8rQgwAAarSe Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003020157 Message-Id: <20100302180343.A31EE28C1FC@core3.amsl.com> X-Mailman-Approved-At: Wed, 03 Mar 2010 07:30:57 -0800 Cc: "'ipsec@ietf.org'" , "'cfrg@irtf.org'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 18:03:45 -0000 SSBzZWUgdmFsdWUgaW4gYWRkaW5nIGEgc2ltcGxlci10aGFuLUVBUCBtZXRob2QsIGFuZCBzdXBw b3J0IHRoaXMgZWZmb3J0LiBCdXQgb3ZlcmFsbCBpdCdzIGFuIGV4dHJlbWVseSBkaWZmaWN1bHQg dGFzayBiZWNhdXNlIG9mIElQUi4NCg0KSSBwZXJzb25hbGx5IHdvdWxkIGhhdGUgdG8gc2VlIGEg cGF0ZW50LWVuY3VtYmVyZWQgc29sdXRpb24gLSBhbmQgdGhhdCB3b3VsZCBkaXNxdWFsaWZ5IEVL RSBhbmQgUEFLIG91dHJpZ2h0IChib3RoIGhlbGQgYnkgQWxjYXRlbC1MdWNlbnQsIEFGQUlLKS4g U1JQIHdvdWxkIGJlIHRoZSBvbmx5IGFjY2VwdGFibGUgKGZyb20gSVBSIHBvaW50IG9mIHZpZXcp IGNhbmRpZGF0ZSB0aGF0IEknbSBhd2FyZSBvZi4gSSd2ZSBiZWVuIHRvbGQgdGhhdCBFS0UgcGF0 ZW50IGlzIHdyaXR0ZW4gc28gYnJvYWRseSB0aGF0IGl0IGNvdWxkIGNvdmVyIFNSUCBhcyB3ZWxs IC0gc29tZWJvZHkgbW9yZSBrbm93bGVkZ2VhYmxlIHNob3VsZCBjb21tZW50IG9uIHRoaXMuDQoN ClRueCENCg0KUmVnYXJkcywNClVyaQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpG cm9tOiBjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcgPGNmcmctYm91bmNlc0BpcnRmLm9yZz4NClRvOiBI YW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldD4NCkNjOiBJUHNlY21l IFdHIDxpcHNlY0BpZXRmLm9yZz47IGNmcmdAaXJ0Zi5vcmcgPGNmcmdAaXJ0Zi5vcmc+DQpTZW50 OiBUdWUgTWFyIDAyIDEyOjUxOjI5IDIwMTAKU3ViamVjdDogUmU6IFtDZnJnXSBbSVBzZWNdIEJl Z2lubmluZyBkaXNjdXNzaW9uIG9uIHNlY3VyZSBwYXNzd29yZC1vbmx5IGF1dGhlbnRpY2F0aW9u IGZvciBJS0V2Mg0KDQpBdCA3OjIyIFBNICswMjAwIDMvMi8xMCwgSGFubmVzIFRzY2hvZmVuaWcg d3JvdGU6DQo+VGhlIGNoYWxsZW5nZSBJIGhhdmUgaW4gdW5kZXJzdGFuZGluZyB0aGUgbW90aXZh dGlvbiBmb3IgdGhpcyB3b3JrIGlzIGltcGFjdGVkIGJ5IC4uLg0KPg0KPjEpIEVBUCBpcyBub3Qg b25seSBtZWFudCB0byBiZSB1c2VkIHdpdGggYmFja2VuZCBpbmZyYXN0cnVjdHVyZS4NCj4yKSBF QVAgaXMgYW4gYXV0aGVudGljYXRpb24gZnJhbWV3b3JrIGFuZCBFQVAgbWV0aG9kcyBleGlzdCB0 aGF0IHN1cHBvcnQgc3Ryb25nLXBhc3N3b3JkIGJhc2VkIGF1dGhlbnRpY2F0aW9uLg0KPjMpIEVB UCBpcyBpbXBsZW1lbnRlZCBieSBmb2xrcyBpbiBJS0V2MiBhbHJlYWR5Lg0KPg0KPlRvIG1lIGl0 IHNlZW1zIHRoYXQgdGhlcmUgaXMgdGhlIGNoYW5jZSB0byByZS11c2UgZXhpc3RpbmcgbWVjaGFu aXNtcyBhbmQgdG8gZXZlbiByZS11c2UgZXhpc3RpbmcgY29kZS4NCg0KSGFubmVzLCBpdCBpcyBu b3QgcmVhbGx5IGFwcHJvcHJpYXRlIHRvIHJlLW9wZW4gY2xvc2VkIGNoYXJ0ZXIgaXNzdWVzLiBB cyB5b3Uga25vdywgdGhpcyB3YXMgYWxyZWFkeSBkaXNjdXNzZWQsIGF0IGxlbmd0aCwgaW4gdGhl IFdHLiBUaGF0J3Mgd2h5IGFub3RoZXIgcGFydCBvZiB0aGUgbmV3IGNoYXJ0ZXIgaGFzOg0KDQot IEEgc3RhbmRhcmRzLXRyYWNrIElLRXYyIGV4dGVuc2lvbiB0byBhbGxvdyBtdXR1YWwgRUFQLWJh c2VkDQphdXRoZW50aWNhdGlvbiBpbiBJS0V2MiwgZWxpbWluYXRpbmcgdGhlIG5lZWQgZm9yIHRo ZSByZXNwb25kZXIgdG8NCnByZXNlbnQgYSBjZXJ0aWZpY2F0ZS4gVGhlIGRvY3VtZW50IHdpbGwg ZGVmaW5lIHRoZSBjb25kaXRpb25zIHRoYXQNCkVBUCBtZXRob2RzIG5lZWQgdG8gZnVsZmlsbCBp biBvcmRlciB0byB1c2UgdGhpcyBleHRlbnNpb24uIFRoZQ0KZG9jdW1lbnQgd2lsbCByZWNvbW1l bmQsIGJ1dCB3aWxsIG5vdCByZXF1aXJlLCB0aGUgdXNlIG9mIEVBUCBtZXRob2RzDQp0aGF0IHBy b3ZpZGUgRUFQIGNoYW5uZWwgYmluZGluZy4gVGhlIHByb3Bvc2VkIHN0YXJ0aW5nIHBvaW50IGZv ciB0aGlzDQp3b3JrIGlzIGRyYWZ0LWVyb25lbi1pcHNlYy1pa2V2Mi1lYXAtYXV0aC0wNy50eHQu DQoNCkZvciB0aGlzIHRocmVhZCwgcGxlYXNlIGZvY3VzIG9uIHRoZSBpc3N1ZXMgYXQgaGFuZCBm b3IgYSBzZWN1cmUgcGFzc3dvcmQtb25seSBhdXRoZW50aWNhdGlvbiBtb2RlIGZvciBJS0V2Mi4g VGhhbmtzIQ0KDQotLVBhdWwgSG9mZm1hbiwgRGlyZWN0b3INCi0tVlBOIENvbnNvcnRpdW0NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDZnJnIG1haWxp bmcgbGlzdA0KQ2ZyZ0BpcnRmLm9yZw0KaHR0cDovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NmcmcNCg== From uri@ll.mit.edu Wed Mar 3 06:25:54 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087E63A86BC; Wed, 3 Mar 2010 06:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhKmU3Ap7dee; Wed, 3 Mar 2010 06:25:53 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id 18DB13A8875; Wed, 3 Mar 2010 06:25:53 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id o23EPlTo017592; Wed, 3 Mar 2010 09:25:48 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'pgut001@cs.auckland.ac.nz'" Date: Wed, 3 Mar 2010 09:25:47 -0500 Thread-Topic: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6ak8EIGcFtxyYQSa7KHc82fTKJgAcxuY+ Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003030097 Message-Id: <20100303142553.18DB13A8875@core3.amsl.com> X-Mailman-Approved-At: Wed, 03 Mar 2010 07:30:57 -0800 Cc: "'ipsec@ietf.org'" , "'cfrg@irtf.org'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 14:25:54 -0000 WW91J3JlIGdvb2QhICA6LSkNCg0KT24gdGhlIHZlbmRvciBzaWRlIC0gcGVyaGFwcyBFS0UgcGF0 ZW50IGNvbmNlcm4gd2FzIHRoZSBjYXVzZSAoeW91IGltcGxlbWVudC9zZWxsIGZyZWUgU1JQIGFu ZCBnZXQgc2xhcHBlZCB3aXRoIEVLRSBsaWNlbnNpbmcpPyBBbmQgdGhlIHVzZXJzIGZvdW5kIGFs dGVybmF0aXZlIHNvbHV0aW9ucyBpbiB0aGUgbWVhbndoaWxlPw0KDQpEbyB5b3UgdGhpbmsgd2Vh ayBwYXNzd29yZHMgYXJlIHRvbyBkYW5nZXJvdXMgb3ZlcmFsbCAobWFueSBvdGhlciB3YXlzIG9m IGF0dGFja2luZyB0aGVtIG91dHNpZGUgb2YgZGlyZWN0IHByb3RvY29sIGF0dGVtcHRzIHRoYXQg d2UgdHJ5IHRvIGRlZmVuZCBhZ2FpbnN0KSwgYW5kIHNvIHdlIHNob3VsZG4ndCBlbnRlcnRhaW4g dGhlbSBhdCBhbGw/DQoNClRueCENClJlZ2FyZHMsDQpVcmkNCg0KLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLQ0KRnJvbTogcGd1dDAwMSA8cGd1dDAwMUB3aW50ZXJtdXRlMDIuY3MuYXVja2xh bmQuYWMubno+DQpUbzogc21iQGNzLmNvbHVtYmlhLmVkdSA8c21iQGNzLmNvbHVtYmlhLmVkdT47 IEJsdW1lbnRoYWwsIFVyaSAtIDA2NjIgLSBNSVRMTA0KQ2M6IGNmcmdAaXJ0Zi5vcmcgPGNmcmdA aXJ0Zi5vcmc+OyBIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0IDxIYW5uZXMuVHNjaG9mZW5pZ0Bn bXgubmV0PjsgaXBzZWNAaWV0Zi5vcmcgPGlwc2VjQGlldGYub3JnPjsgcGF1bC5ob2ZmbWFuQHZw bmMub3JnIDxwYXVsLmhvZmZtYW5AdnBuYy5vcmc+DQpTZW50OiBUdWUgTWFyIDAyIDE5OjQxOjQz IDIwMTAKU3ViamVjdDogUmU6IFtDZnJnXSBbSVBzZWNdIEJlZ2lubmluZyBkaXNjdXNzaW9uIG9u IHNlY3VyZSBwYXNzd29yZC1vbmx5IGF1dGhlbnRpY2F0aW9uIGZvciBJS0V2Mg0KDQoiU3RldmVu IE0uIEJlbGxvdmluIiA8c21iQGNzLmNvbHVtYmlhLmVkdT4gd3JpdGVzOg0KDQo+Tm90ZSB0aGF0 IHRoZSBFS0UgcGF0ZW50IGV4cGlyZXMgaW4gT2N0b2JlciAyMDExLiAgKEF0IGxlYXN0IEkgdGhp bmsgaXQgZG9lczsNCj5pdCB3YXMgZmlsZWQgaW4gT2N0b2JlciAxOTkxLikgIERlcGVuZGluZyBv biB3aGVuIHlvdSBleHBlY3QgaW1wbGVtZW50YXRpb25zDQo+dG8gYXBwZWFyLS0gYW5kIGdpdmVu IGhvdyBsb25nIGl0IHRha2VzIHRvIHByb2R1Y2Ugc3RhbmRhcmRzLXRyYWNrIGRvY3VtZW50cw0K PmluIHRoZSBJRVRGIC0tIGl0IG1pZ2h0IG5vdCBiZSBhIHByb2JsZW0uDQoNCkdpdmVuIHRoYXQg U1JQIGltcGxlbWVudGF0aW9ucyBoYXZlIGJlZW4gYXZhaWxhYmxlIGFuZCBtb3JlIG9yIGxlc3Mg ZnJlZWx5IA0KdXNhYmxlIGZvciBxdWl0ZSBzb21lIHRpbWUgYW5kIFRMUy1QU0sgaXMgY29tcGxl dGVseSB1bmVuY3VtYmVyZWQgYW55d2F5LCBJIA0KdGhpbmsgdGhlIHJlYWwgaXNzdWUgd29uJ3Qg YmUgIndoZW4gd2lsbCBpbXBsZW1lbnRhdGlvbnMgYXBwZWFyIiBidXQgIndoeSANCmlzbid0IGFu eW9uZSB1c2luZyB0aGVtIHdoZW4gdGhleSBhcmUgYXZhaWxhYmxlIj8NCg0KKE1pbmQgeW91IHRo YXQncyBhIGxheWVyIDggaXNzdWUsIGFuZCB0aGVyZWZvcmUgbm90IG91ciBwcm9ibGVtIDotKS4N Cg0KUGV0ZXIuDQo= From uri@ll.mit.edu Wed Mar 3 06:31:27 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98833A8DE8; Wed, 3 Mar 2010 06:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqI5FKFvrKPf; Wed, 3 Mar 2010 06:31:25 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id C283028C3DC; Wed, 3 Mar 2010 06:31:10 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id o23EU8JP022467; Wed, 3 Mar 2010 09:31:03 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'smb@cs.columbia.edu'" , "'dharkins@lounge.org'" Date: Wed, 3 Mar 2010 09:30:53 -0500 Thread-Topic: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6bLW5CMI6M/LuSDuZhJBh3xGCjQAcWtXs Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003030098 Message-Id: <20100303143110.C283028C3DC@core3.amsl.com> X-Mailman-Approved-At: Wed, 03 Mar 2010 07:30:57 -0800 Cc: "'ipsec@ietf.org'" , "'cfrg@irtf.org'" , "'Black_David@emc.com'" , "'paul.hoffman@vpnc.org'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 14:31:28 -0000 QSByZWFzb25hYmxlIHF1ZXN0aW9uIGlzIC0gZG8gYWxsIHRoZSBwcm9wb3NlZCAiRUtFIHZhcmlh dGlvbnMiIGhhdmUgdGhlIHNhbWUgcmVxdWlyZW1lbnQgKGFuZCB0aGUgc2FtZSB3ZWFrbmVzcyk/ IE9yIG9ubHkgdGhlIG9yaWdpbmFsIEVLRSBkb2VzPw0KDQpSZWdhcmRzLA0KVXJpDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IGNmcmctYm91bmNlc0BpcnRmLm9yZyA8Y2Zy Zy1ib3VuY2VzQGlydGYub3JnPg0KVG86IERhbiBIYXJraW5zIDxkaGFya2luc0Bsb3VuZ2Uub3Jn Pg0KQ2M6IGlwc2VjQGlldGYub3JnIDxpcHNlY0BpZXRmLm9yZz47IGNmcmdAaXJ0Zi5vcmcgPGNm cmdAaXJ0Zi5vcmc+OyBCbGFja19EYXZpZEBlbWMuY29tIDxCbGFja19EYXZpZEBlbWMuY29tPjsg cGF1bC5ob2ZmbWFuQHZwbmMub3JnIDxwYXVsLmhvZmZtYW5AdnBuYy5vcmc+DQpTZW50OiBUdWUg TWFyIDAyIDE5OjU4OjM1IDIwMTAKU3ViamVjdDogUmU6IFtDZnJnXSBbSVBzZWNdIEJlZ2lubmlu ZyBkaXNjdXNzaW9uIG9uIHNlY3VyZSBwYXNzd29yZC1vbmx5IGF1dGhlbnRpY2F0aW9uIGZvciBJ S0V2Mg0KDQpPbiBUdWUsIDIgTWFyIDIwMTAgMTY6NDg6MDcgLTA4MDAgKFBTVCkNCiJEYW4gSGFy a2lucyIgPGRoYXJraW5zQGxvdW5nZS5vcmc+IHdyb3RlOg0KDQo+IA0KPiAgIEhpIERhdmlkLA0K PiANCj4gDQo+IE9uIFR1ZSwgTWFyY2ggMiwgMjAxMCAzOjQ5IHBtLCBCbGFja19EYXZpZEBlbWMu Y29tIHdyb3RlOg0KPiBbc25pcF0NCj4gPg0KPiA+IE9UT0gsIEkgdGhpbmsgeW91J3ZlIG92ZXJz aW1wbGlmaWVkIGhlcmUgLi4uDQo+ID4NCj4gPj4gICBUaGUgY2FuZGlkYXRlIGV4Y2hhbmdlcyBh bGwgcmVseSBvbiB0aGUgImhhcmQgcHJvYmxlbSIgb2YgZG9pbmcgYQ0KPiA+PiBkaXNjcmV0ZSBs b2dhcml0aG0gaW4gb25lIG9mIHRoZSBkZWZpbmVkIGdyb3Vwcy4gSXQncyB0aGUgc2FtZQ0KPiA+ PiAiaGFyZCBwcm9ibGVtIiB0aGF0IG1ha2VzIHRoZSBEaWZmaWUtSGVsbG1hbiBwb3J0aW9uIG9m IElLRQ0KPiA+PiBzZWN1cmUuIElmIHRoZSBncm91cCBuZWdvdGlhdGVkIG9yIGRlbWFuZGVkIGlu IElLRSBhbGxvd3MgZm9yIGFuDQo+ID4+ICJlYXNpZXIgYXR0YWNrIiB0aGVuIGl0IHNob3VsZG4n dCBiZSB1c2VkIGluIHRoZSBJS0UgZXhjaGFuZ2UgdG8NCj4gPj4gZG8gdGhlIERpZmZpZS1IZWxs bWFuLg0KPiA+DQo+ID4gSWYgSSBmb2xsb3cgeW91ciBsb2dpYywgSSB0aGluayB5b3UncmUgYXJn dWluZyB0aGF0IGJlY2F1c2UgdGhlDQo+ID4gZXhpc3RpbmcgZ3JvdXBzIGFsbG93IGVhc2llciBh dHRhY2tzIG9uIHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uDQo+ID4gKGUuZy4sIGJhc2VkIG9uIGNo ZWNrcyBvbiB3aGF0IGEgZ3Vlc3NlZCBwYXNzd29yZCBkZWNyeXB0cyB0bykgdGhlbg0KPiA+IHRo ZXkgYWxsb3cgZWFzaWVyIGF0dGFja3Mgb24gSUtFIHdpdGggZXhpc3RpbmcgYXV0aGVudGljYXRp b24sDQo+ID4gKmhlbmNlKiB0aG9zZSBncm91cHMgYXJlIHVuYWNjZXB0YWJsZSB0byB1c2Ugd2l0 aCBJS0UuICBJIHRoaW5rIHRoZQ0KPiA+ICpoZW5jZSogaXMgb2ZmIHRoZSBtYXJrIGR1ZSB0byB0 aGUgbXVjaCBsYXJnZXIgY2FuZGlkYXRlIHNlYXJjaA0KPiA+IHNwYWNlIHdoZW4gb3RoZXIgdGVj aG5pcXVlcyAoZS5nLiwgY2VydGlmaWNhdGUtYmFzZWQpIGFyZSB1c2VkIHRvDQo+ID4gYXV0aGVu dGljYXRlLg0KPiANCj4gICBUaGF0IHdhc24ndCB3aGF0IEkgd2FzIGFyZ3VpbmcuIEkgdGhpbmsg YWxsIHRoZSBjYW5kaWRhdGUgZXhjaGFuZ2VzDQo+IGFyZSBiYXNlZCBvbiB0aGUgY29tcHV0YXRp b25hbCBEaWZmaWUtSGVsbG1hbiBhc3N1bXB0aW9uLiBBbmQgdGhlDQo+IHdvcmsgZmFjdG9yIHRv IGF0dGFjayB0aGVtIG9uIHRoYXQgZnJvbnQgc2hvdWxkIGJlIHRoZSBzYW1lIGFzIHRoZQ0KPiB3 b3JrIGZhY3RvciB0byBhdHRhY2sgYSBzdGFuZGFyZCBEaWZmaWUtSGVsbG1hbiBrZXkgZXhjaGFu Z2UuIE9yIGFtDQo+IEkgbWlzc2luZyBzb21ldGhpbmc/DQo+IA0KPiAgIEkgZG9uJ3QgdGhpbmsg YW55IG9mIHRoZSBjdXJyZW50bHktZGVmaW5lZCBncm91cHMgYXJlIHVuYWNjZXB0YWJsZQ0KPiB0 byB1c2Ugd2l0aCBJS0UuIEJ1dCBoeXBvdGhldGljYWxseSwgaWYgdGhlcmUgd2FzIHNvbWUgZ3Jv dXAgZGVmaW5lZA0KPiB0aGF0IGFsbG93ZWQgYW4gZWFzeSBhdHRhY2sgKHRoZSBvcmRlciB3YXMg dW5hY2NlcHRhYmx5IHNtYWxsLCBmb3INCj4gaW5zdGFuY2UpIHRoZW4gaXQgd291bGQgYmUgdW5z dWl0YWJsZSBmb3IgSUtFIGp1c3QgbGlrZSBpdCB3b3VsZCBiZQ0KPiB1bnN1aXRhYmxlIGZvciBh bnkgb2YgdGhlIGNhbmRpZGF0ZSBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzLg0KPiAN Cj4gICBGb3IgdGhlc2UgcGFzc3dvcmQgYXV0aGVudGljYXRpb24gc2NoZW1lcyB0byBiZSBzZWN1 cmUsIHRoZSBvbmx5DQo+IG1ldGhvZCBvZiBhdHRhY2sgaXMgcmVwZWF0ZWQgYWN0aXZlIGd1ZXNz aW5nIGF0dGFja3Mgb2YgdGhlIHBhc3N3b3JkDQo+ICh0aGUgYWR2YW50YWdlIGFuIGF0dGFja2Vy IGdhaW5zIGlzIHRocm91Z2ggaW50ZXJhY3Rpb24sIG5vdA0KPiBjb21wdXRhdGlvbikuIEFuICJl YXNpZXIgYXR0YWNrIiBpcyBhbiBvZmYtbGluZSBkaWN0aW9uYXJ5IGF0dGFjayB0bw0KPiBsZWFy biB0aGUgcGFzc3dvcmQgKHRoZSBhZHZhbnRhZ2UgZ2FpbmVkIGlzIHRocm91Z2ggY29tcHV0YXRp b24pIGFuZA0KPiB1c2luZyBhbnkgb2YgdGhlIGdyb3VwcyBpbiBJS0UodjIpJ3MgSUFOQSByZWdp c3RyeSB3aXRoIEVLRSB3b3VsZA0KPiBlbmFibGUgYSBkaWN0aW9uYXJ5IGF0dGFjay4gQnV0IHRo ZSBhdHRhY2tlciBkb2Vzbid0IGxlYXJuIHRoZQ0KPiBlcGhlbWVyYWwgc2VjcmV0IHRoYXQgcmVz dWx0cyBmcm9tIEVLRSwgdGhlIENESCBhc3N1bXB0aW9uIHN0aWxsDQo+IGFwcGxpZXMuIFRoZSBp c3N1ZSBpc24ndCB3aXRoIHRoZSBncm91cCwgcGVyIHNlLCBpdCdzIHdpdGggdGhlDQo+IChtaXMp dXNlIG9mIHRoZSBncm91cC4NCj4gDQpSaWdodC4gIEluIHRoZSBvcmlnaW5hbCBFS0UgcGFwZXIs IHdlIGNhbGxlZCB0aGlzIGEgInBhcnRpdGlvbg0KYXR0YWNrIi4gIFRoZXJlIGFyZSBvdGhlcnMg cG9zc2libGU7IGl0J3MgaW1wb3J0YW50IHRvIHRha2UgY2FyZSB0bw0KYXZvaWQgdGhlbS4gIEZv ciBleGFtcGxlLCBzdXBwb3NlIHRoYXQgd2Ugd2FudGVkIGEgfjIwNDgtYml0IC0tIDI1NiBieXRl DQotLSBtb2R1bHVzLiAgQ2hvb3NpbmcgYSBtb2R1bHVzIG9mIDIwNDAgYml0cywgdGhvdWdoIGFi b3V0IHRoZSBzYW1lDQpkaWZmaWN1bHR5IHdoZW4gaXQgY29tZXMgdG8gc29sdmluZyBkaXNjcmV0 ZSBsb2csIGlzIHVuYWNjZXB0YWJsZSBmb3INCkVLRSwgYmVjYXVzZSBpbiBhIGNvcnJlY3QgZ3Vl c3MgdGhlIGhpZ2gtb3JkZXIgYnl0ZSB3b3VsZCBiZSBhbGwgemVyb3M7DQphbiBpbmNvcnJlY3Qg Z3Vlc3Mgd291bGQsIHdpdGggcHJvYmFiaWxpdHkgMjU1LzI1NiwgbGV0IHlvdSBydWxlIG91dCBh DQpjYW5kaWRhdGUgcGFzc3dvcmQuICBBIGdvb2QgRUtFIG1vZHVsdXMgd291bGQgYmUgY2xvc2Ug ZW5vdWdoIHRvIDJeMjA0OA0KdG8gaGF2ZSBhIG5lZ2xpZ2libGUgcHJvYmFiaWxpdHkgb2YgYSBk ZWNyeXB0aW9uIHdpdGggYSBiYWQgZ3Vlc3MgYmVpbmcNCmluIHRoZSByYW5nZSBbcCwgMl4yMDQ4 LTFdLiAgSW4gb3RoZXIgd29yZHMsIGdvb2QgbW9kdWxpIGZvciBFS0UgaGF2ZQ0Kc3BlY2lhbGl6 ZWQgcHJvcGVydGllcy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpDZnJnIG1haWxpbmcgbGlzdA0KQ2ZyZ0BpcnRmLm9yZw0KaHR0cDovL3d3dy5pcnRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCg== From thomwu@cisco.com Wed Mar 3 07:45:49 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCDA3A8B0F for ; Wed, 3 Mar 2010 07:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.848 X-Spam-Level: X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm3WpIe1Ck74 for ; Wed, 3 Mar 2010 07:45:48 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B581D3A8AB7 for ; Wed, 3 Mar 2010 07:45:48 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH8TjkurRN+K/2dsb2JhbACbDXOnPYp/jUyCcYILBIMXiyA X-IronPort-AV: E=Sophos;i="4.49,574,1262563200"; d="scan'208";a="95210309" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 03 Mar 2010 15:45:38 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o23Fjc6t005039; Wed, 3 Mar 2010 15:45:38 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 07:45:38 -0800 Received: from 10.21.116.72 ([10.21.116.72]) by xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) with Microsoft Exchange Server HTTP-DAV ; Wed, 3 Mar 2010 15:45:36 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 03 Mar 2010 07:47:41 -0800 From: thomwu To: "Blumenthal, Uri - 0662 - MITLL" , "'pgut001@cs.auckland.ac.nz'" Message-ID: Thread-Topic: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6ak8EIGcFtxyYQSa7KHc82fTKJgAcxuY+AALcNKs= In-Reply-To: <20100303142553.18DB13A8875@core3.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Mar 2010 15:45:38.0135 (UTC) FILETIME=[92311670:01CABAE8] Cc: "'ipsec@ietf.org'" , "'cfrg@irtf.org'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 15:45:49 -0000 On 3/3/10 6:25 AM, "Blumenthal, Uri - 0662 - MITLL" wrote: > You're good! :-) > > On the vendor side - perhaps EKE patent concern was the cause (you > implement/sell free SRP and get slapped with EKE licensing)? And the users > found alternative solutions in the meanwhile? No, I can say that this was definitely not the case in any instances that I was involved in. Performance, implementation complexity (of strong password protocols in general), and protocol complexity ranked much higher on the list. Users cared far more about whether strong password protocols degraded their user experience by adding round trips to the protocol; at that point, patents were a complete non-issue. Tom From smb@cs.columbia.edu Wed Mar 3 08:05:20 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA92628C129 for ; Wed, 3 Mar 2010 08:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4eLXgr1Jhqj for ; Wed, 3 Mar 2010 08:05:20 -0800 (PST) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 8B88928C126 for ; Wed, 3 Mar 2010 08:05:20 -0800 (PST) Received: by machshav.com (Postfix, from userid 512) id 88DCA52D409; Wed, 3 Mar 2010 11:05:15 -0500 (EST) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 392EC52D3F2; Wed, 3 Mar 2010 11:05:14 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 7E35C293DB9; Wed, 3 Mar 2010 11:05:07 -0500 (EST) Date: Wed, 3 Mar 2010 11:05:07 -0500 From: "Steven M. Bellovin" To: "Blumenthal, Uri - 0662 - MITLL" Message-ID: <20100303110507.738a1ce2@cs.columbia.edu> In-Reply-To: <20100303143110.C283028C3DC@core3.amsl.com> References: <20100303143110.C283028C3DC@core3.amsl.com> Organization: Columbia University X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "'ipsec@ietf.org'" , "'paul.hoffman@vpnc.org'" , "'cfrg@irtf.org'" , "'dharkins@lounge.org'" , "'Black_David@emc.com'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:05:21 -0000 On Wed, 3 Mar 2010 09:30:53 -0500 "Blumenthal, Uri - 0662 - MITLL" wrote: > A reasonable question is - do all the proposed "EKE variations" have > the same requirement (and the same weakness)? Or only the original > EKE does? > I'm not sure what you mean by "EKE variants" -- all of the variants in the original paper except for the main one (which was also the first) -- are now known to be insecure. Do you mean other PAKE protocols? I suspect that any PAKE protocol that relies on the lack of verifiable plaintext would have the same requirement; the form, however, may differ. The specific example I gave in my original note, quoted below, is specific to EKE, but it's far from the only conceivable attack. We're going to have to look at any proposal very carefully, with this in mind. > ----- Original Message ----- > From: cfrg-bounces@irtf.org > To: Dan Harkins > Cc: ipsec@ietf.org ; cfrg@irtf.org ; > Black_David@emc.com ; paul.hoffman@vpnc.org > Sent: Tue Mar 02 19:58:35 2010 Subject: Re: > [Cfrg] [IPsec] Beginning discussion on secure password-only > authentication for IKEv2 > > On Tue, 2 Mar 2010 16:48:07 -0800 (PST) > "Dan Harkins" wrote: > > > > > Hi David, > > > > > > On Tue, March 2, 2010 3:49 pm, Black_David@emc.com wrote: > > [snip] > > > > > > OTOH, I think you've oversimplified here ... > > > > > >> The candidate exchanges all rely on the "hard problem" of > > >> doing a discrete logarithm in one of the defined groups. It's > > >> the same "hard problem" that makes the Diffie-Hellman portion of > > >> IKE secure. If the group negotiated or demanded in IKE allows > > >> for an "easier attack" then it shouldn't be used in the IKE > > >> exchange to do the Diffie-Hellman. > > > > > > If I follow your logic, I think you're arguing that because the > > > existing groups allow easier attacks on password authentication > > > (e.g., based on checks on what a guessed password decrypts to) > > > then they allow easier attacks on IKE with existing > > > authentication, *hence* those groups are unacceptable to use with > > > IKE. I think the *hence* is off the mark due to the much larger > > > candidate search space when other techniques (e.g., > > > certificate-based) are used to authenticate. > > > > That wasn't what I was arguing. I think all the candidate > > exchanges are based on the computational Diffie-Hellman assumption. > > And the work factor to attack them on that front should be the same > > as the work factor to attack a standard Diffie-Hellman key > > exchange. Or am I missing something? > > > > I don't think any of the currently-defined groups are unacceptable > > to use with IKE. But hypothetically, if there was some group defined > > that allowed an easy attack (the order was unacceptably small, for > > instance) then it would be unsuitable for IKE just like it would be > > unsuitable for any of the candidate password authentication schemes. > > > > For these password authentication schemes to be secure, the only > > method of attack is repeated active guessing attacks of the password > > (the advantage an attacker gains is through interaction, not > > computation). An "easier attack" is an off-line dictionary attack to > > learn the password (the advantage gained is through computation) and > > using any of the groups in IKE(v2)'s IANA registry with EKE would > > enable a dictionary attack. But the attacker doesn't learn the > > ephemeral secret that results from EKE, the CDH assumption still > > applies. The issue isn't with the group, per se, it's with the > > (mis)use of the group. > > > Right. In the original EKE paper, we called this a "partition > attack". There are others possible; it's important to take care to > avoid them. For example, suppose that we wanted a ~2048-bit -- 256 > byte -- modulus. Choosing a modulus of 2040 bits, though about the > same difficulty when it comes to solving discrete log, is > unacceptable for EKE, because in a correct guess the high-order byte > would be all zeros; an incorrect guess would, with probability > 255/256, let you rule out a candidate password. A good EKE modulus > would be close enough to 2^2048 to have a negligible probability of a > decryption with a bad guess being in the range [p, 2^2048-1]. In > other words, good moduli for EKE have specialized properties. > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --Steve Bellovin, http://www.cs.columbia.edu/~smb From uri@ll.mit.edu Wed Mar 3 08:44:08 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5523D3A8B8F; Wed, 3 Mar 2010 08:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmpgSTR8LLEj; Wed, 3 Mar 2010 08:44:07 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id CBA323A8B87; Wed, 3 Mar 2010 08:44:06 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id o23GfJnq005603; Wed, 3 Mar 2010 11:43:57 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'smb@cs.columbia.edu'" Date: Wed, 3 Mar 2010 11:43:51 -0500 Thread-Topic: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq661rCFqgJYjFXRKC3us/v+bZgvAABVmZ1 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003030135 Message-Id: <20100303164406.CBA323A8B87@core3.amsl.com> Cc: "'ipsec@ietf.org'" , "'paul.hoffman@vpnc.org'" , "'cfrg@irtf.org'" , "'dharkins@lounge.org'" , "'Black_David@emc.com'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:44:08 -0000 WWVzIEkgbWVhbiBvdGhlciBwcm90b2NvbHMgcG90ZW50aWFsbHkgY292ZXJlZCBieSBFS0UgcGF0 ZW50Lg0KDQpSZWdhcmRzLA0KVXJpDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZy b206IFN0ZXZlbiBNLiBCZWxsb3ZpbiA8c21iQGNzLmNvbHVtYmlhLmVkdT4NClRvOiBCbHVtZW50 aGFsLCBVcmkgLSAwNjYyIC0gTUlUTEwNCkNjOiAnZGhhcmtpbnNAbG91bmdlLm9yZycgPGRoYXJr aW5zQGxvdW5nZS5vcmc+OyAnaXBzZWNAaWV0Zi5vcmcnIDxpcHNlY0BpZXRmLm9yZz47ICdjZnJn QGlydGYub3JnJyA8Y2ZyZ0BpcnRmLm9yZz47ICdCbGFja19EYXZpZEBlbWMuY29tJyA8QmxhY2tf RGF2aWRAZW1jLmNvbT47ICdwYXVsLmhvZmZtYW5AdnBuYy5vcmcnIDxwYXVsLmhvZmZtYW5AdnBu Yy5vcmc+DQpTZW50OiBXZWQgTWFyIDAzIDExOjA1OjA3IDIwMTAKU3ViamVjdDogUmU6IFtDZnJn XSBbSVBzZWNdIEJlZ2lubmluZyBkaXNjdXNzaW9uIG9uIHNlY3VyZSBwYXNzd29yZC1vbmx5IGF1 dGhlbnRpY2F0aW9uIGZvciBJS0V2Mg0KDQpPbiBXZWQsIDMgTWFyIDIwMTAgMDk6MzA6NTMgLTA1 MDANCiJCbHVtZW50aGFsLCBVcmkgLSAwNjYyIC0gTUlUTEwiIDx1cmlAbGwubWl0LmVkdT4gd3Jv dGU6DQoNCj4gQSByZWFzb25hYmxlIHF1ZXN0aW9uIGlzIC0gZG8gYWxsIHRoZSBwcm9wb3NlZCAi RUtFIHZhcmlhdGlvbnMiIGhhdmUNCj4gdGhlIHNhbWUgcmVxdWlyZW1lbnQgKGFuZCB0aGUgc2Ft ZSB3ZWFrbmVzcyk/IE9yIG9ubHkgdGhlIG9yaWdpbmFsDQo+IEVLRSBkb2VzPw0KPiANCkknbSBu b3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICJFS0UgdmFyaWFudHMiIC0tIGFsbCBvZiB0aGUgdmFy aWFudHMgaW4NCnRoZSBvcmlnaW5hbCBwYXBlciBleGNlcHQgZm9yIHRoZSBtYWluIG9uZSAod2hp Y2ggd2FzIGFsc28gdGhlIGZpcnN0KQ0KLS0gYXJlIG5vdyBrbm93biB0byBiZSBpbnNlY3VyZS4g IERvIHlvdSBtZWFuIG90aGVyIFBBS0UgcHJvdG9jb2xzPyAgSQ0Kc3VzcGVjdCB0aGF0IGFueSBQ QUtFIHByb3RvY29sIHRoYXQgcmVsaWVzIG9uIHRoZSBsYWNrIG9mIHZlcmlmaWFibGUNCnBsYWlu dGV4dCB3b3VsZCBoYXZlIHRoZSBzYW1lIHJlcXVpcmVtZW50OyB0aGUgZm9ybSwgaG93ZXZlciwg bWF5DQpkaWZmZXIuICBUaGUgc3BlY2lmaWMgZXhhbXBsZSBJIGdhdmUgaW4gbXkgb3JpZ2luYWwg bm90ZSwgcXVvdGVkIGJlbG93LA0KaXMgc3BlY2lmaWMgdG8gRUtFLCBidXQgaXQncyBmYXIgZnJv bSB0aGUgb25seSBjb25jZWl2YWJsZSBhdHRhY2suDQpXZSdyZSBnb2luZyB0byBoYXZlIHRvIGxv b2sgYXQgYW55IHByb3Bvc2FsIHZlcnkgY2FyZWZ1bGx5LCB3aXRoIHRoaXMNCmluIG1pbmQuDQoN Cj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiBjZnJnLWJvdW5jZXNAaXJ0 Zi5vcmcgPGNmcmctYm91bmNlc0BpcnRmLm9yZz4NCj4gVG86IERhbiBIYXJraW5zIDxkaGFya2lu c0Bsb3VuZ2Uub3JnPg0KPiBDYzogaXBzZWNAaWV0Zi5vcmcgPGlwc2VjQGlldGYub3JnPjsgY2Zy Z0BpcnRmLm9yZyA8Y2ZyZ0BpcnRmLm9yZz47DQo+IEJsYWNrX0RhdmlkQGVtYy5jb20gPEJsYWNr X0RhdmlkQGVtYy5jb20+OyBwYXVsLmhvZmZtYW5AdnBuYy5vcmcNCj4gPHBhdWwuaG9mZm1hbkB2 cG5jLm9yZz4gU2VudDogVHVlIE1hciAwMiAxOTo1ODozNSAyMDEwIFN1YmplY3Q6IFJlOg0KPiBb Q2ZyZ10gW0lQc2VjXSBCZWdpbm5pbmcgZGlzY3Vzc2lvbiBvbiBzZWN1cmUgcGFzc3dvcmQtb25s eQ0KPiBhdXRoZW50aWNhdGlvbiBmb3IgSUtFdjINCj4gDQo+IE9uIFR1ZSwgMiBNYXIgMjAxMCAx Njo0ODowNyAtMDgwMCAoUFNUKQ0KPiAiRGFuIEhhcmtpbnMiIDxkaGFya2luc0Bsb3VuZ2Uub3Jn PiB3cm90ZToNCj4gDQo+ID4gDQo+ID4gICBIaSBEYXZpZCwNCj4gPiANCj4gPiANCj4gPiBPbiBU dWUsIE1hcmNoIDIsIDIwMTAgMzo0OSBwbSwgQmxhY2tfRGF2aWRAZW1jLmNvbSB3cm90ZToNCj4g PiBbc25pcF0NCj4gPiA+DQo+ID4gPiBPVE9ILCBJIHRoaW5rIHlvdSd2ZSBvdmVyc2ltcGxpZmll ZCBoZXJlIC4uLg0KPiA+ID4NCj4gPiA+PiAgIFRoZSBjYW5kaWRhdGUgZXhjaGFuZ2VzIGFsbCBy ZWx5IG9uIHRoZSAiaGFyZCBwcm9ibGVtIiBvZg0KPiA+ID4+IGRvaW5nIGEgZGlzY3JldGUgbG9n YXJpdGhtIGluIG9uZSBvZiB0aGUgZGVmaW5lZCBncm91cHMuIEl0J3MNCj4gPiA+PiB0aGUgc2Ft ZSAiaGFyZCBwcm9ibGVtIiB0aGF0IG1ha2VzIHRoZSBEaWZmaWUtSGVsbG1hbiBwb3J0aW9uIG9m DQo+ID4gPj4gSUtFIHNlY3VyZS4gSWYgdGhlIGdyb3VwIG5lZ290aWF0ZWQgb3IgZGVtYW5kZWQg aW4gSUtFIGFsbG93cw0KPiA+ID4+IGZvciBhbiAiZWFzaWVyIGF0dGFjayIgdGhlbiBpdCBzaG91 bGRuJ3QgYmUgdXNlZCBpbiB0aGUgSUtFDQo+ID4gPj4gZXhjaGFuZ2UgdG8gZG8gdGhlIERpZmZp ZS1IZWxsbWFuLg0KPiA+ID4NCj4gPiA+IElmIEkgZm9sbG93IHlvdXIgbG9naWMsIEkgdGhpbmsg eW91J3JlIGFyZ3VpbmcgdGhhdCBiZWNhdXNlIHRoZQ0KPiA+ID4gZXhpc3RpbmcgZ3JvdXBzIGFs bG93IGVhc2llciBhdHRhY2tzIG9uIHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uDQo+ID4gPiAoZS5n LiwgYmFzZWQgb24gY2hlY2tzIG9uIHdoYXQgYSBndWVzc2VkIHBhc3N3b3JkIGRlY3J5cHRzIHRv KQ0KPiA+ID4gdGhlbiB0aGV5IGFsbG93IGVhc2llciBhdHRhY2tzIG9uIElLRSB3aXRoIGV4aXN0 aW5nDQo+ID4gPiBhdXRoZW50aWNhdGlvbiwgKmhlbmNlKiB0aG9zZSBncm91cHMgYXJlIHVuYWNj ZXB0YWJsZSB0byB1c2Ugd2l0aA0KPiA+ID4gSUtFLiAgSSB0aGluayB0aGUgKmhlbmNlKiBpcyBv ZmYgdGhlIG1hcmsgZHVlIHRvIHRoZSBtdWNoIGxhcmdlcg0KPiA+ID4gY2FuZGlkYXRlIHNlYXJj aCBzcGFjZSB3aGVuIG90aGVyIHRlY2huaXF1ZXMgKGUuZy4sDQo+ID4gPiBjZXJ0aWZpY2F0ZS1i YXNlZCkgYXJlIHVzZWQgdG8gYXV0aGVudGljYXRlLg0KPiA+IA0KPiA+ICAgVGhhdCB3YXNuJ3Qg d2hhdCBJIHdhcyBhcmd1aW5nLiBJIHRoaW5rIGFsbCB0aGUgY2FuZGlkYXRlDQo+ID4gZXhjaGFu Z2VzIGFyZSBiYXNlZCBvbiB0aGUgY29tcHV0YXRpb25hbCBEaWZmaWUtSGVsbG1hbiBhc3N1bXB0 aW9uLg0KPiA+IEFuZCB0aGUgd29yayBmYWN0b3IgdG8gYXR0YWNrIHRoZW0gb24gdGhhdCBmcm9u dCBzaG91bGQgYmUgdGhlIHNhbWUNCj4gPiBhcyB0aGUgd29yayBmYWN0b3IgdG8gYXR0YWNrIGEg c3RhbmRhcmQgRGlmZmllLUhlbGxtYW4ga2V5DQo+ID4gZXhjaGFuZ2UuIE9yIGFtIEkgbWlzc2lu ZyBzb21ldGhpbmc/DQo+ID4gDQo+ID4gICBJIGRvbid0IHRoaW5rIGFueSBvZiB0aGUgY3VycmVu dGx5LWRlZmluZWQgZ3JvdXBzIGFyZSB1bmFjY2VwdGFibGUNCj4gPiB0byB1c2Ugd2l0aCBJS0Uu IEJ1dCBoeXBvdGhldGljYWxseSwgaWYgdGhlcmUgd2FzIHNvbWUgZ3JvdXAgZGVmaW5lZA0KPiA+ IHRoYXQgYWxsb3dlZCBhbiBlYXN5IGF0dGFjayAodGhlIG9yZGVyIHdhcyB1bmFjY2VwdGFibHkg c21hbGwsIGZvcg0KPiA+IGluc3RhbmNlKSB0aGVuIGl0IHdvdWxkIGJlIHVuc3VpdGFibGUgZm9y IElLRSBqdXN0IGxpa2UgaXQgd291bGQgYmUNCj4gPiB1bnN1aXRhYmxlIGZvciBhbnkgb2YgdGhl IGNhbmRpZGF0ZSBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzLg0KPiA+IA0KPiA+ICAg Rm9yIHRoZXNlIHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgdG8gYmUgc2VjdXJlLCB0 aGUgb25seQ0KPiA+IG1ldGhvZCBvZiBhdHRhY2sgaXMgcmVwZWF0ZWQgYWN0aXZlIGd1ZXNzaW5n IGF0dGFja3Mgb2YgdGhlIHBhc3N3b3JkDQo+ID4gKHRoZSBhZHZhbnRhZ2UgYW4gYXR0YWNrZXIg Z2FpbnMgaXMgdGhyb3VnaCBpbnRlcmFjdGlvbiwgbm90DQo+ID4gY29tcHV0YXRpb24pLiBBbiAi ZWFzaWVyIGF0dGFjayIgaXMgYW4gb2ZmLWxpbmUgZGljdGlvbmFyeSBhdHRhY2sgdG8NCj4gPiBs ZWFybiB0aGUgcGFzc3dvcmQgKHRoZSBhZHZhbnRhZ2UgZ2FpbmVkIGlzIHRocm91Z2ggY29tcHV0 YXRpb24pIGFuZA0KPiA+IHVzaW5nIGFueSBvZiB0aGUgZ3JvdXBzIGluIElLRSh2MikncyBJQU5B IHJlZ2lzdHJ5IHdpdGggRUtFIHdvdWxkDQo+ID4gZW5hYmxlIGEgZGljdGlvbmFyeSBhdHRhY2su IEJ1dCB0aGUgYXR0YWNrZXIgZG9lc24ndCBsZWFybiB0aGUNCj4gPiBlcGhlbWVyYWwgc2VjcmV0 IHRoYXQgcmVzdWx0cyBmcm9tIEVLRSwgdGhlIENESCBhc3N1bXB0aW9uIHN0aWxsDQo+ID4gYXBw bGllcy4gVGhlIGlzc3VlIGlzbid0IHdpdGggdGhlIGdyb3VwLCBwZXIgc2UsIGl0J3Mgd2l0aCB0 aGUNCj4gPiAobWlzKXVzZSBvZiB0aGUgZ3JvdXAuDQo+ID4gDQo+IFJpZ2h0LiAgSW4gdGhlIG9y aWdpbmFsIEVLRSBwYXBlciwgd2UgY2FsbGVkIHRoaXMgYSAicGFydGl0aW9uDQo+IGF0dGFjayIu ICBUaGVyZSBhcmUgb3RoZXJzIHBvc3NpYmxlOyBpdCdzIGltcG9ydGFudCB0byB0YWtlIGNhcmUg dG8NCj4gYXZvaWQgdGhlbS4gIEZvciBleGFtcGxlLCBzdXBwb3NlIHRoYXQgd2Ugd2FudGVkIGEg fjIwNDgtYml0IC0tIDI1Ng0KPiBieXRlIC0tIG1vZHVsdXMuICBDaG9vc2luZyBhIG1vZHVsdXMg b2YgMjA0MCBiaXRzLCB0aG91Z2ggYWJvdXQgdGhlDQo+IHNhbWUgZGlmZmljdWx0eSB3aGVuIGl0 IGNvbWVzIHRvIHNvbHZpbmcgZGlzY3JldGUgbG9nLCBpcw0KPiB1bmFjY2VwdGFibGUgZm9yIEVL RSwgYmVjYXVzZSBpbiBhIGNvcnJlY3QgZ3Vlc3MgdGhlIGhpZ2gtb3JkZXIgYnl0ZQ0KPiB3b3Vs ZCBiZSBhbGwgemVyb3M7IGFuIGluY29ycmVjdCBndWVzcyB3b3VsZCwgd2l0aCBwcm9iYWJpbGl0 eQ0KPiAyNTUvMjU2LCBsZXQgeW91IHJ1bGUgb3V0IGEgY2FuZGlkYXRlIHBhc3N3b3JkLiAgQSBn b29kIEVLRSBtb2R1bHVzDQo+IHdvdWxkIGJlIGNsb3NlIGVub3VnaCB0byAyXjIwNDggdG8gaGF2 ZSBhIG5lZ2xpZ2libGUgcHJvYmFiaWxpdHkgb2YgYQ0KPiBkZWNyeXB0aW9uIHdpdGggYSBiYWQg Z3Vlc3MgYmVpbmcgaW4gdGhlIHJhbmdlIFtwLCAyXjIwNDgtMV0uICBJbg0KPiBvdGhlciB3b3Jk cywgZ29vZCBtb2R1bGkgZm9yIEVLRSBoYXZlIHNwZWNpYWxpemVkIHByb3BlcnRpZXMuDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENmcmcgbWFp bGluZyBsaXN0DQo+IENmcmdAaXJ0Zi5vcmcNCj4gaHR0cDovL3d3dy5pcnRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NmcmcNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gQ2ZyZyBtYWlsaW5nIGxpc3QNCj4gQ2ZyZ0BpcnRmLm9yZw0KPiBodHRwOi8v d3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0KPiANCg0KDQoNCgkJLS1TdGV2ZSBC ZWxsb3ZpbiwgaHR0cDovL3d3dy5jcy5jb2x1bWJpYS5lZHUvfnNtYg0K From dharkins@lounge.org Wed Mar 3 08:46:18 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01C828C0D6 for ; Wed, 3 Mar 2010 08:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB-JwXQwl717 for ; Wed, 3 Mar 2010 08:46:17 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 2AA563A8B7A for ; Wed, 3 Mar 2010 08:46:17 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8FD64200B2; Wed, 3 Mar 2010 08:46:18 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 3 Mar 2010 08:46:18 -0800 (PST) Message-ID: <5207c52e9253ba5746df774a540c42be.squirrel@www.trepanning.net> Date: Wed, 3 Mar 2010 08:46:18 -0800 (PST) From: "Dan Harkins" To: cfrg@irgt.org 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 Subject: [IPsec] [Fwd: Re: Beginning discussion on secure password-only authentication for IKEv2] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:46:18 -0000 Hi, I did not cc cfrg on a post I made yesterday, Yaron responded to it and I have been asked to forward this to encourage discussion. Sorry for the confusion. Dan. ---------------------------- Original Message ---------------------------- Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 From: "Yaron Sheffer" Date: Tue, March 2, 2010 11:04 pm To: "Dan Harkins" Cc: "IPsecme WG" "Paul Hoffman" -------------------------------------------------------------------------- Hi Dan, I consider reuse of DH groups a minor issue at best. But yes, it's a valid criterion. Thanks, Yaron > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Wednesday, March 03, 2010 0:26 > To: Yaron Sheffer > Cc: Dan Harkins; Paul Hoffman; IPsecme WG > Subject: Re: [IPsec] Beginning discussion on secure password-only > authentication for IKEv2 > > > Hi Yaron, > > The discussion is on the secure password-only authentication work > item > in which a password authenticated key exchange is being added directly > to IKE(v2). It doesn't matter what EAP-EKE does or does not do because > EAP is not being used for this work item. > > Now we can add some sort of negotiation or assertion of the special > group required by EKE (analagous to what EAP-EKE does) but that doesn't > fit well with IKEv2 today. > > Whether the ability to use the existing IANA group registry or > whether > hard-coding special groups into the exchange is less or more important > is a matter of opinion and when we get to that stage we can argue about > it. But right now all I'm saying is that this should be included in the > criteria that we are using to evaluate candidates. Do we need a shoe > horn > or a jack hammer to put the exchange into IKE(v2)? Once in does it > constrain us in any way? These are valid topics to discuss. Don't you > agree? > > regards, > > Dan. > > On Tue, March 2, 2010 12:49 pm, Yaron Sheffer wrote: > > Hi Dan, > > > > EAP-EKE supports negotiation of various algorithms, a.k.a. crypto- > agility. > > One of the negotiated algorithms is in fact the group being used. > EAP-EKE > > does require MODP groups that fulfill certain conditions, and as a > result, > > the document defines one such group (additional ones can be easily > added). > > I believe that crypto-agility is an important criterion. As to reuse > of > > IKEv2 groups, this is probably much less important. > > > > It is a bit early to speculate about IKE+EKE, since to the best of my > > knowledge, it has not been written yet. > > > > By the way, IKEv2 does allow for negotiation of the DH group using > the > > ugly INVALID_KE_PAYLOAD hack. > > > > Thanks, > > Yaron > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >> Of Dan Harkins > >> Sent: Tuesday, March 02, 2010 22:12 > >> To: Paul Hoffman > >> Cc: IPsecme WG; cfrg@irtf.org > >> Subject: Re: [IPsec] Beginning discussion on secure password-only > >> authentication for IKEv2 > >> > >> > >> Hello, > >> > >> There are other criteria that should be evaluated in making a > >> decision, such as how well does the solution fits into IKE(v2) and > >> does it support "crypto agility". > >> > >> RFC 2409 supported negotiation of various parameters, like the > group > >> used for the Diffie-Hellman key exchange. That was removed in RFC > 4306. > >> All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- > >> criteria do some sort of discrete logarithm cryptography and > therefore > >> it would be useful to list whether the candidate algorithm can use > >> any of the groups either negotiated or asserted by IKE(v2). > >> > >> For instance, I do not believe EKE is suitable for any of the > >> groups currently in the IANA registry of groups that can be used > with > >> IKE(v2). The MODP groups have a generator that is a quadratic > residue > >> which enables a passive attacker to eliminate passwords from the > >> dictionary if they do not decrypt to a value that is, itself, a > >> quadratic > >> residue and ECP groups are unsuitable because a passive attacker can > >> eliminate passwords from the group if they do not decrypt to a valid > >> point > >> on the curve. In either case, after seeing a trivial number of > >> exchanges > >> a passive attacker is able to determine the password with high > >> probability. > >> > >> So EKE requires a hard-coded special group to be used for its > >> discrete > >> logarithm operations and since negotiation has been removed in RFC > 4306 > >> it means that the ability to change the group to suit the policy or > >> whim > >> of the user (what is popularly termed "crypto agility") goes away. > EKE > >> also requires specification of the mode of encryption used which may > or > >> may not be the same as the one negotiated or asserted in IKE(v2). It > >> could be hard-coded into the specification, like the group, but this > >> too > >> further limits "crypto agility". > >> > >> The other candidates, I believe, can use the same group, whether > MODP > >> or ECP, that the IKE(v2) exchange is using. I think it would be good > to > >> add these criteria to the draft. > >> > >> Also, the table in section 5 should include IEEE 802.11s under the > >> "standards" column for SPSK. And the phrase "may or may not infringe > on > >> existing patents" applies to all candidates, and frankly, to almost > >> everything in the IETF. It is a meaningless phrase and it would be > >> better > >> to just remove it from the "IPR" column. > >> > >> regards, > >> > >> Dan. > >> > >> On Mon, March 1, 2010 4:34 pm, Paul Hoffman wrote: > >> > Greetings again. This message is cross-posted to both the IPsecME > WG > >> and > >> > the CFRG because it pertains to both groups. > >> > > >> > The recently-revised IPsecME charter has a new work item in it: > >> > > >> > ========== > >> > - IKEv2 supports mutual authentication with a shared secret, but > this > >> > mechanism is intended for "strong" shared secrets. User-chosen > >> > passwords are typically of low entropy and subject to off-line > >> > dictionary attacks when used with this mechanism. Thus, RFC 4306 > >> > recommends using EAP with public-key based authentication of the > >> > responder instead. This approach would be typically used in > >> enterprise > >> > remote access VPN scenarios where the VPN gateway does not usually > >> > even have the actual passwords for all users, but instead > typically > >> > communicates with a back-end RADIUS server. > >> > > >> > However, user-configured shared secrets are still useful for many > >> > other IPsec scenarios, such as authentication between two servers > or > >> > routers. These scenarios are usually symmetric: both peers know > the > >> > shared secret, no back-end authentication servers are involved, > and > >> > either peer can initiate an IKEv2 SA. While it would be possible > to > >> > use EAP in such situations (by having both peers implement both > the > >> > EAP peer and the EAP server roles of an EAP method intended for > >> "weak" > >> > shared secrets) with the mutual EAP-based authentication work item > >> > (above), a simpler solution may be desirable in many situations. > >> > > >> > The WG will develop a standards-track extension to IKEv2 to allow > >> > mutual authentication based on "weak" (low-entropy) shared > >> > secrets. The goal is to avoid off-line dictionary attacks without > >> > requiring the use of certificates or EAP. There are many > >> > already-developed algorithms that can be used, and the WG would > need > >> > to pick one that both is believed to be secure and is believed to > >> have > >> > acceptable intellectual property features. The WG would also need > to > >> > develop the protocol to use the chosen algorithm in IKEv2 in a > secure > >> > fashion. It is noted up front that this work item poses a higher > >> > chance of failing to be completed than other WG work items; this > is > >> > balanced by the very high expected value of the extension if it is > >> > standardized and deployed. > >> > ========== > >> > > >> > As the last paragraph says, there are multiple algorithms to > choose > >> from. > >> > Different algorithms have different properties. Before the WG > decides > >> on > >> > which algorithm to focus on, it needs to at least roughly decide > >> which > >> > properties are important for the new protocol. I have included the > >> CFRG on > >> > this message because they are a good source of expertise on > >> cryptographic > >> > properties. > >> > > >> > Yaron Sheffer has created a short and admittedly biased draft > listing > >> some > >> > desired properties and possible candidate algorithms: > >> > >> criteria-00.txt>. > >> > Other people (and even Yaron) might have different views on which > >> > properties are important, how the properties should be ranked, the > >> > importance of the crypto properties of the listed algorithms, and > so > >> on. > >> > > >> > This message is therefore meant to kick off the discussion. It is > OK > >> for > >> > messages to focus on one or more of the proposed algorithms, but > >> getting a > >> > clearer view of which crypto and non-crypto properties are > important > >> is > >> > probably more important first. > >> > > >> > --Paul Hoffman, Director > >> > --VPN Consortium > >> > _______________________________________________ > >> > 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 > >> > >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From dharkins@lounge.org Wed Mar 3 09:15:08 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEEE28C1A1 for ; Wed, 3 Mar 2010 09:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.79 X-Spam-Level: X-Spam-Status: No, score=-5.79 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7BTbBQp+kvR for ; Wed, 3 Mar 2010 09:15:06 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 5F6D228C19D for ; Wed, 3 Mar 2010 09:15:05 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 98165200B2; Wed, 3 Mar 2010 09:15:06 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 3 Mar 2010 09:15:06 -0800 (PST) Message-ID: In-Reply-To: <20100303164410.E832D200B2@colo.trepanning.net> References: <20100303164410.E832D200B2@colo.trepanning.net> Date: Wed, 3 Mar 2010 09:15:06 -0800 (PST) From: "Dan Harkins" To: "Blumenthal, Uri - 0662 - MITLL" 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: "'cfrg@irtf.org'" , "'paul.hoffman@vpnc.org'" , "'dharkins@lounge.org'" , "'ipsec@ietf.org'" , "'smb@cs.columbia.edu'" , "'Black_David@emc.com'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 17:15:08 -0000 Hi Uri, The exchange described in draft-harkins-ipsecme-spsk-auth does not have the same requirements on groups as EKE. To the best of my knowledge, it can use all of the MODP and ECP groups in the IANA registry. So the same group that is being used to do the DH exchange in IKE(v2) could be used to do the password authentication exchange. regards, Dan. On Wed, March 3, 2010 8:43 am, Blumenthal, Uri - 0662 - MITLL wrote: > Yes I mean other protocols potentially covered by EKE patent. > > Regards, > Uri > > ----- Original Message ----- > From: Steven M. Bellovin > To: Blumenthal, Uri - 0662 - MITLL > Cc: 'dharkins@lounge.org' ; 'ipsec@ietf.org' > ; 'cfrg@irtf.org' ; 'Black_David@emc.com' > ; 'paul.hoffman@vpnc.org' > Sent: Wed Mar 03 11:05:07 2010 > Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only > authentication for IKEv2 > > On Wed, 3 Mar 2010 09:30:53 -0500 > "Blumenthal, Uri - 0662 - MITLL" wrote: > >> A reasonable question is - do all the proposed "EKE variations" have >> the same requirement (and the same weakness)? Or only the original >> EKE does? >> > I'm not sure what you mean by "EKE variants" -- all of the variants in > the original paper except for the main one (which was also the first) > -- are now known to be insecure. Do you mean other PAKE protocols? I > suspect that any PAKE protocol that relies on the lack of verifiable > plaintext would have the same requirement; the form, however, may > differ. The specific example I gave in my original note, quoted below, > is specific to EKE, but it's far from the only conceivable attack. > We're going to have to look at any proposal very carefully, with this > in mind. > >> ----- Original Message ----- >> From: cfrg-bounces@irtf.org >> To: Dan Harkins >> Cc: ipsec@ietf.org ; cfrg@irtf.org ; >> Black_David@emc.com ; paul.hoffman@vpnc.org >> Sent: Tue Mar 02 19:58:35 2010 Subject: Re: >> [Cfrg] [IPsec] Beginning discussion on secure password-only >> authentication for IKEv2 >> >> On Tue, 2 Mar 2010 16:48:07 -0800 (PST) >> "Dan Harkins" wrote: >> >> > >> > Hi David, >> > >> > >> > On Tue, March 2, 2010 3:49 pm, Black_David@emc.com wrote: >> > [snip] >> > > >> > > OTOH, I think you've oversimplified here ... >> > > >> > >> The candidate exchanges all rely on the "hard problem" of >> > >> doing a discrete logarithm in one of the defined groups. It's >> > >> the same "hard problem" that makes the Diffie-Hellman portion of >> > >> IKE secure. If the group negotiated or demanded in IKE allows >> > >> for an "easier attack" then it shouldn't be used in the IKE >> > >> exchange to do the Diffie-Hellman. >> > > >> > > If I follow your logic, I think you're arguing that because the >> > > existing groups allow easier attacks on password authentication >> > > (e.g., based on checks on what a guessed password decrypts to) >> > > then they allow easier attacks on IKE with existing >> > > authentication, *hence* those groups are unacceptable to use with >> > > IKE. I think the *hence* is off the mark due to the much larger >> > > candidate search space when other techniques (e.g., >> > > certificate-based) are used to authenticate. >> > >> > That wasn't what I was arguing. I think all the candidate >> > exchanges are based on the computational Diffie-Hellman assumption. >> > And the work factor to attack them on that front should be the same >> > as the work factor to attack a standard Diffie-Hellman key >> > exchange. Or am I missing something? >> > >> > I don't think any of the currently-defined groups are unacceptable >> > to use with IKE. But hypothetically, if there was some group defined >> > that allowed an easy attack (the order was unacceptably small, for >> > instance) then it would be unsuitable for IKE just like it would be >> > unsuitable for any of the candidate password authentication schemes. >> > >> > For these password authentication schemes to be secure, the only >> > method of attack is repeated active guessing attacks of the password >> > (the advantage an attacker gains is through interaction, not >> > computation). An "easier attack" is an off-line dictionary attack to >> > learn the password (the advantage gained is through computation) and >> > using any of the groups in IKE(v2)'s IANA registry with EKE would >> > enable a dictionary attack. But the attacker doesn't learn the >> > ephemeral secret that results from EKE, the CDH assumption still >> > applies. The issue isn't with the group, per se, it's with the >> > (mis)use of the group. >> > >> Right. In the original EKE paper, we called this a "partition >> attack". There are others possible; it's important to take care to >> avoid them. For example, suppose that we wanted a ~2048-bit -- 256 >> byte -- modulus. Choosing a modulus of 2040 bits, though about the >> same difficulty when it comes to solving discrete log, is >> unacceptable for EKE, because in a correct guess the high-order byte >> would be all zeros; an incorrect guess would, with probability >> 255/256, let you rule out a candidate password. A good EKE modulus >> would be close enough to 2^2048 to have a negligible probability of a >> decryption with a bad guess being in the range [p, 2^2048-1]. In >> other words, good moduli for EKE have specialized properties. >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> > > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From paul.hoffman@vpnc.org Wed Mar 3 09:51:39 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D547A3A8B93 for ; Wed, 3 Mar 2010 09:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.787 X-Spam-Level: X-Spam-Status: No, score=-5.787 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4tkzSBzjnuX for ; Wed, 3 Mar 2010 09:51:39 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 13CE03A87DE for ; Wed, 3 Mar 2010 09:51:38 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o23HpcbT021262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Mar 2010 10:51:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 3 Mar 2010 09:51:37 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 17:51:40 -0000 >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. > > Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 > Author(s) : S. Shen, Y. Mao, S. murthy > Filename : draft-ietf-ipsecme-aes-ctr-ikev2-05.txt > Pages : 10 > Date : 2010-3-2 > >This document describes the usage of Advanced Encryption Standard > Counter Mode (AES-CTR), with an explicit initialization vector, by > IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT > exchange. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05.txt Based on Pasi's AD review, the authors significantly shortened the document. It seems prudent to have the WG review the new, shorter version. In particular, it would be good for developers to look at the new short document and see if it is complete enough to implement from. This review cycle will end in a week, but please do the review early in case problems are found. --Paul Hoffman, Director --VPN Consortium From dharkins@lounge.org Wed Mar 3 10:00:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE6728C36B for ; Wed, 3 Mar 2010 10:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.843 X-Spam-Level: X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnDbodnv9F5A for ; Wed, 3 Mar 2010 10:00:10 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 1E45D28C354 for ; Wed, 3 Mar 2010 10:00:10 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B491D200B2; Wed, 3 Mar 2010 10:00:11 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 3 Mar 2010 10:00:11 -0800 (PST) Message-ID: <2b4a449ce9ef8b01c392d70eda781d36.squirrel@www.trepanning.net> Date: Wed, 3 Mar 2010 10:00:11 -0800 (PST) From: "Dan Harkins" To: cfrg@irtf.org 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 Subject: [IPsec] [Fwd: Re: Beginning discussion on secure password-only authentication for IKEv2] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 18:00:11 -0000 Hi, I did not cc cfrg on a post I made yesterday, Yaron responded to it and I have been asked to forward this to the cfrg list to encourage discussion. Sorry for the confusion. (And if you see multiple copies of this, sorry about that too, I fat-fingered the cfrg list the last time). Dan. ---------------------------- Original Message ---------------------------- Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2 From: "Yaron Sheffer" Date: Tue, March 2, 2010 11:04 pm To: "Dan Harkins" Cc: "IPsecme WG" "Paul Hoffman" -------------------------------------------------------------------------- Hi Dan, I consider reuse of DH groups a minor issue at best. But yes, it's a valid criterion. Thanks, Yaron > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Wednesday, March 03, 2010 0:26 > To: Yaron Sheffer > Cc: Dan Harkins; Paul Hoffman; IPsecme WG > Subject: Re: [IPsec] Beginning discussion on secure password-only > authentication for IKEv2 > > > Hi Yaron, > > The discussion is on the secure password-only authentication work > item > in which a password authenticated key exchange is being added directly > to IKE(v2). It doesn't matter what EAP-EKE does or does not do because > EAP is not being used for this work item. > > Now we can add some sort of negotiation or assertion of the special > group required by EKE (analagous to what EAP-EKE does) but that doesn't > fit well with IKEv2 today. > > Whether the ability to use the existing IANA group registry or > whether > hard-coding special groups into the exchange is less or more important > is a matter of opinion and when we get to that stage we can argue about > it. But right now all I'm saying is that this should be included in the > criteria that we are using to evaluate candidates. Do we need a shoe > horn > or a jack hammer to put the exchange into IKE(v2)? Once in does it > constrain us in any way? These are valid topics to discuss. Don't you > agree? > > regards, > > Dan. > > On Tue, March 2, 2010 12:49 pm, Yaron Sheffer wrote: > > Hi Dan, > > > > EAP-EKE supports negotiation of various algorithms, a.k.a. crypto- > agility. > > One of the negotiated algorithms is in fact the group being used. > EAP-EKE > > does require MODP groups that fulfill certain conditions, and as a > result, > > the document defines one such group (additional ones can be easily > added). > > I believe that crypto-agility is an important criterion. As to reuse > of > > IKEv2 groups, this is probably much less important. > > > > It is a bit early to speculate about IKE+EKE, since to the best of my > > knowledge, it has not been written yet. > > > > By the way, IKEv2 does allow for negotiation of the DH group using > the > > ugly INVALID_KE_PAYLOAD hack. > > > > Thanks, > > Yaron > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >> Of Dan Harkins > >> Sent: Tuesday, March 02, 2010 22:12 > >> To: Paul Hoffman > >> Cc: IPsecme WG; cfrg@irtf.org > >> Subject: Re: [IPsec] Beginning discussion on secure password-only > >> authentication for IKEv2 > >> > >> > >> Hello, > >> > >> There are other criteria that should be evaluated in making a > >> decision, such as how well does the solution fits into IKE(v2) and > >> does it support "crypto agility". > >> > >> RFC 2409 supported negotiation of various parameters, like the > group > >> used for the Diffie-Hellman key exchange. That was removed in RFC > 4306. > >> All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- > >> criteria do some sort of discrete logarithm cryptography and > therefore > >> it would be useful to list whether the candidate algorithm can use > >> any of the groups either negotiated or asserted by IKE(v2). > >> > >> For instance, I do not believe EKE is suitable for any of the > >> groups currently in the IANA registry of groups that can be used > with > >> IKE(v2). The MODP groups have a generator that is a quadratic > residue > >> which enables a passive attacker to eliminate passwords from the > >> dictionary if they do not decrypt to a value that is, itself, a > >> quadratic > >> residue and ECP groups are unsuitable because a passive attacker can > >> eliminate passwords from the group if they do not decrypt to a valid > >> point > >> on the curve. In either case, after seeing a trivial number of > >> exchanges > >> a passive attacker is able to determine the password with high > >> probability. > >> > >> So EKE requires a hard-coded special group to be used for its > >> discrete > >> logarithm operations and since negotiation has been removed in RFC > 4306 > >> it means that the ability to change the group to suit the policy or > >> whim > >> of the user (what is popularly termed "crypto agility") goes away. > EKE > >> also requires specification of the mode of encryption used which may > or > >> may not be the same as the one negotiated or asserted in IKE(v2). It > >> could be hard-coded into the specification, like the group, but this > >> too > >> further limits "crypto agility". > >> > >> The other candidates, I believe, can use the same group, whether > MODP > >> or ECP, that the IKE(v2) exchange is using. I think it would be good > to > >> add these criteria to the draft. > >> > >> Also, the table in section 5 should include IEEE 802.11s under the > >> "standards" column for SPSK. And the phrase "may or may not infringe > on > >> existing patents" applies to all candidates, and frankly, to almost > >> everything in the IETF. It is a meaningless phrase and it would be > >> better > >> to just remove it from the "IPR" column. > >> > >> regards, > >> > >> Dan. > >> > >> On Mon, March 1, 2010 4:34 pm, Paul Hoffman wrote: > >> > Greetings again. This message is cross-posted to both the IPsecME > WG > >> and > >> > the CFRG because it pertains to both groups. > >> > > >> > The recently-revised IPsecME charter has a new work item in it: > >> > > >> > ========== > >> > - IKEv2 supports mutual authentication with a shared secret, but > this > >> > mechanism is intended for "strong" shared secrets. User-chosen > >> > passwords are typically of low entropy and subject to off-line > >> > dictionary attacks when used with this mechanism. Thus, RFC 4306 > >> > recommends using EAP with public-key based authentication of the > >> > responder instead. This approach would be typically used in > >> enterprise > >> > remote access VPN scenarios where the VPN gateway does not usually > >> > even have the actual passwords for all users, but instead > typically > >> > communicates with a back-end RADIUS server. > >> > > >> > However, user-configured shared secrets are still useful for many > >> > other IPsec scenarios, such as authentication between two servers > or > >> > routers. These scenarios are usually symmetric: both peers know > the > >> > shared secret, no back-end authentication servers are involved, > and > >> > either peer can initiate an IKEv2 SA. While it would be possible > to > >> > use EAP in such situations (by having both peers implement both > the > >> > EAP peer and the EAP server roles of an EAP method intended for > >> "weak" > >> > shared secrets) with the mutual EAP-based authentication work item > >> > (above), a simpler solution may be desirable in many situations. > >> > > >> > The WG will develop a standards-track extension to IKEv2 to allow > >> > mutual authentication based on "weak" (low-entropy) shared > >> > secrets. The goal is to avoid off-line dictionary attacks without > >> > requiring the use of certificates or EAP. There are many > >> > already-developed algorithms that can be used, and the WG would > need > >> > to pick one that both is believed to be secure and is believed to > >> have > >> > acceptable intellectual property features. The WG would also need > to > >> > develop the protocol to use the chosen algorithm in IKEv2 in a > secure > >> > fashion. It is noted up front that this work item poses a higher > >> > chance of failing to be completed than other WG work items; this > is > >> > balanced by the very high expected value of the extension if it is > >> > standardized and deployed. > >> > ========== > >> > > >> > As the last paragraph says, there are multiple algorithms to > choose > >> from. > >> > Different algorithms have different properties. Before the WG > decides > >> on > >> > which algorithm to focus on, it needs to at least roughly decide > >> which > >> > properties are important for the new protocol. I have included the > >> CFRG on > >> > this message because they are a good source of expertise on > >> cryptographic > >> > properties. > >> > > >> > Yaron Sheffer has created a short and admittedly biased draft > listing > >> some > >> > desired properties and possible candidate algorithms: > >> > >> criteria-00.txt>. > >> > Other people (and even Yaron) might have different views on which > >> > properties are important, how the properties should be ranked, the > >> > importance of the crypto properties of the listed algorithms, and > so > >> on. > >> > > >> > This message is therefore meant to kick off the discussion. It is > OK > >> for > >> > messages to focus on one or more of the proposed algorithms, but > >> getting a > >> > clearer view of which crypto and non-crypto properties are > important > >> is > >> > probably more important first. > >> > > >> > --Paul Hoffman, Director > >> > --VPN Consortium > >> > _______________________________________________ > >> > 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 > >> > >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From Black_David@emc.com Wed Mar 3 12:35:04 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E088D28C200; Wed, 3 Mar 2010 12:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsbYF0zOoAdR; Wed, 3 Mar 2010 12:35:04 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id E26463A8B9F; Wed, 3 Mar 2010 12:34:57 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o23KYwvw024578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Mar 2010 15:34:58 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 3 Mar 2010 15:34:51 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o23KYNeV030713; Wed, 3 Mar 2010 15:34:50 -0500 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 15:34:17 -0500 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: Wed, 3 Mar 2010 15:34:14 -0500 Message-ID: In-Reply-To: <20100303142553.18DB13A8875@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq6ak8EIGcFtxyYQSa7KHc82fTKJgAcxuY+AAzQ5PA= References: <20100303142553.18DB13A8875@core3.amsl.com> From: To: X-OriginalArrivalTime: 03 Mar 2010 20:34:17.0538 (UTC) FILETIME=[E55C4220:01CABB10] X-EMM-EM: Active Cc: ipsec@ietf.org, cfrg@irtf.org Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 20:35:05 -0000 This IPR disclosure is relevant to this discussion: https://datatracker.ietf.org/ipr/63/ Thanks, --David > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Blumenthal, Uri - 0662 - > MITLL > Sent: Wednesday, March 03, 2010 9:26 AM > To: 'pgut001@cs.auckland.ac.nz' > Cc: 'ipsec@ietf.org'; 'cfrg@irtf.org' > Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 >=20 > You're good! :-) >=20 > On the vendor side - perhaps EKE patent concern was the cause (you implement/sell free SRP and get > slapped with EKE licensing)? And the users found alternative solutions in the meanwhile? >=20 > Do you think weak passwords are too dangerous overall (many other ways of attacking them outside of > direct protocol attempts that we try to defend against), and so we shouldn't entertain them at all? >=20 > Tnx! > Regards, > Uri >=20 > ----- Original Message ----- > From: pgut001 > To: smb@cs.columbia.edu ; Blumenthal, Uri - 0662 - MITLL > Cc: cfrg@irtf.org ; Hannes.Tschofenig@gmx.net ; > ipsec@ietf.org ; paul.hoffman@vpnc.org > Sent: Tue Mar 02 19:41:43 2010 > Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2 >=20 > "Steven M. Bellovin" writes: >=20 > >Note that the EKE patent expires in October 2011. (At least I think it does; > >it was filed in October 1991.) Depending on when you expect implementations > >to appear-- and given how long it takes to produce standards-track documents > >in the IETF -- it might not be a problem. >=20 > Given that SRP implementations have been available and more or less freely > usable for quite some time and TLS-PSK is completely unencumbered anyway, I > think the real issue won't be "when will implementations appear" but "why > isn't anyone using them when they are available"? >=20 > (Mind you that's a layer 8 issue, and therefore not our problem :-). >=20 > Peter. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Wed Mar 3 21:16:41 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B5E3A8AF2 for ; Wed, 3 Mar 2010 21:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kvq2AFzECOFB for ; Wed, 3 Mar 2010 21:16:37 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 766123A88C0 for ; Wed, 3 Mar 2010 21:16:36 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o245Gasd000599; Thu, 4 Mar 2010 07:16:36 +0200 (IST) X-CheckPoint: {4B8F40EB-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 4 Mar 2010 07:16:55 +0200 From: Yoav Nir To: "'Paul Hoffman'" , IPsecme WG Date: Thu, 4 Mar 2010 07:16:55 +0200 Thread-Topic: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt Thread-Index: Acq6+j6wSRRlqDh3QCmrRdSUtJxy6wAX18Dw Message-ID: <006FEB08D9C6444AB014105C9AEB133FB37650C4EA@il-ex01.ad.checkpoint.com> References: In-Reply-To: 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 Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 05:16:42 -0000 Paragraph 5 of section #2: MUST accept any length that results in proper alignment. It should be noticed that the ESP [RFC4303] Encrypted Payload requires Please change "noticed" to "noted". Other than that, the document looks good enough for implementation. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Wednesday, March 03, 2010 7:52 PM To: IPsecme WG Subject: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. > > Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 > Author(s) : S. Shen, Y. Mao, S. murthy > Filename : draft-ietf-ipsecme-aes-ctr-ikev2-05.txt > Pages : 10 > Date : 2010-3-2 >=09 >This document describes the usage of Advanced Encryption Standard > Counter Mode (AES-CTR), with an explicit initialization vector, by > IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT > exchange. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05.tx= t Based on Pasi's AD review, the authors significantly shortened the document= . It seems prudent to have the WG review the new, shorter version. In parti= cular, it would be good for developers to look at the new short document an= d see if it is complete enough to implement from. This review cycle will end in a week, but please do the review early in cas= e problems are found. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From shenshuo@cnnic.cn Wed Mar 3 21:49:57 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5533A83C6 for ; Wed, 3 Mar 2010 21:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt4WM3NGOBKk for ; Wed, 3 Mar 2010 21:49:57 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 665283A67D2 for ; Wed, 3 Mar 2010 21:49:55 -0800 (PST) Received: (eyou send program); Thu, 04 Mar 2010 13:49:56 +0800 Message-ID: <467681796.13887@cnnic.cn> Received: from 169.223.34.211 by mail.cnnic.cn with HTTP; Thu, 04 Mar 2010 13:49:56 +0800 X-WebMAIL-MUA: [169.223.34.211] From: "Sean Shen" To: ipsec@ietf.org Date: Thu, 04 Mar 2010 13:49:56 +0800 X-Priority: 3 Content-Type: text/plain Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Sean Shen List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 05:49:57 -0000 Thank you, Yoav, I will have it fixed, listen to this channel for other suggestions and have the revised version submitted by Mar 8th. Sean In your mail: >From: Yoav Nir >Reply-To: >To: "'Paul Hoffman'" , IPsecme WG >Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt >Date:Thu, 4 Mar 2010 07:16:55 +0200 > >Paragraph 5 of section #2: > MUST accept any length that results in proper alignment. It should > be noticed that the ESP [RFC4303] Encrypted Payload requires > > Please change "noticed" to "noted". > > Other than that, the document looks good enough for implementation. > > >A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. >> >> Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 >> Author(s) : S. Shen, Y. Mao, S. murthy >> Filename : draft-ietf-ipsecme-aes-ctr-ikev2-05.txt >> Pages : 10 >> Date : 2010-3-2 >> >>This document describes the usage of Advanced Encryption Standard >> Counter Mode (AES-CTR), with an explicit initialization vector, by >> IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT >> exchange. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05.txt > >Based on Pasi's AD review, the authors significantly shortened the document. It seems prudent to have the WG review the new, shorter version. In particular, it would be good for developers to look at the new short document and see if it is complete enough to implement from. > >This review cycle will end in a week, but please do the review early in case problems are found. > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > >Scanned by Check Point Total Security Gateway. >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From rsjenwar@gmail.com Wed Mar 3 22:00:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C063A8C78 for ; Wed, 3 Mar 2010 22:00:28 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Drmn9TuQ6N9A for ; Wed, 3 Mar 2010 22:00:26 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 47E3E3A8A05 for ; Wed, 3 Mar 2010 22:00:26 -0800 (PST) Received: by wyb40 with SMTP id 40so1233576wyb.31 for ; Wed, 03 Mar 2010 22:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7Al0xjauFsNUrFEsA3GhTn0dWkx2T3pcNpmC9kky9jQ=; b=nN3WV3jbi6sO8MAQT/H3ZL2yBCB0MsQUPvFfWvYjzO/zp6TQe83y0Y9gAFIatfpkvA mVtEZ/j6vrTPw0mwiqCE0kHuOE33frfXSpaN9S0LH9QVpFKxvzoZnhSq9bitoSJaW+AJ a1Skvf2KD/nVfNPDdRTCGzLotSihXuAFHFQo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GmC6YXsMEaxA36Yi0RvVFzGXqC5EAXzptNlqTcpJRJlfEllrevnlaAFBUK0sok32lx EijsfrCaex6q1Vy/R4cVRdqKw/jN8en/fVr3XSBwxBgxulYup6l4JEkCdYFIyIGzdGC+ VBBr5vpoUDWt2fNxPSWY50PQFSypoOcG+zLxQ= MIME-Version: 1.0 Received: by 10.216.88.71 with SMTP id z49mr2580195wee.90.1267682423620; Wed, 03 Mar 2010 22:00:23 -0800 (PST) In-Reply-To: <467681796.13887@cnnic.cn> References: <467681796.13887@cnnic.cn> Date: Thu, 4 Mar 2010 11:30:23 +0530 Message-ID: <7ccecf671003032200r3e0de9d8te2dcf3aab9dacdea@mail.gmail.com> From: Raj Singh To: Sean Shen Content-Type: multipart/alternative; boundary=0016e6dab0ec8c46930480f35057 Cc: ipsec Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 06:00:28 -0000 --0016e6dab0ec8c46930480f35057 Content-Type: text/plain; charset=UTF-8 Hi Sean, Section 5. IANA Considerations can be reworded in-line with ikev2bis. 5. IANA Considerations IANA has already registered the type and value for AES-CTR. Name Number Defined In -------------------------------------------- ENCR_AES_CTR 13 (RFC3686 ) Best regards, Raj On Thu, Mar 4, 2010 at 11:19 AM, Sean Shen wrote: > Thank you, Yoav, > I will have it fixed, listen to this channel for other suggestions and have > the > revised version submitted by Mar 8th. > > Sean > > > In your mail: > >From: Yoav Nir > >Reply-To: > >To: "'Paul Hoffman'" , IPsecme WG > >Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt > >Date:Thu, 4 Mar 2010 07:16:55 +0200 > > > >Paragraph 5 of section #2: > > MUST accept any length that results in proper alignment. It should > > be noticed that the ESP [RFC4303] Encrypted Payload requires > > > > Please change "noticed" to "noted". > > > > Other than that, the document looks good enough for implementation. > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >>This draft is a work item of the IP Security Maintenance and Extensions > Working > Group of the IETF. > >> > >> Title : Using Advanced Encryption Standard (AES) Counter > Mode with IKEv2 > >> Author(s) : S. Shen, Y. Mao, S. murthy > >> Filename : draft-ietf-ipsecme-aes-ctr-ikev2-05.txt > >> Pages : 10 > >> Date : 2010-3-2 > >> > >>This document describes the usage of Advanced Encryption Standard > >> Counter Mode (AES-CTR), with an explicit initialization vector, by > >> IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT > >> exchange. > >> > >>A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05.txt > > > >Based on Pasi's AD review, the authors significantly shortened the > document. It > seems prudent to have the WG review the new, shorter version. In > particular, it > would be good for developers to look at the new short document and see if > it is > complete enough to implement from. > > > >This review cycle will end in a week, but please do the review early in > case > problems are found. > > > >--Paul Hoffman, Director > >--VPN Consortium > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec > > > >Scanned by Check Point Total Security Gateway. > >_______________________________________________ > >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 > --0016e6dab0ec8c46930480f35057 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sean,

Section=C2=A05. IANA Considerations can be reworded in-line with ikev2bis.

5. IANA Considerations
IANA has already registered the type and value for AES-CTR.
Name                 Number      Defined In
--------------------------------------------
ENCR_AES_CTR         13        =
  (RFC3686)

<= div>Best regards,
Raj
On Thu, Mar 4, 2010 at 11:19 AM, Sean Shen <shenshuo@cnnic.cn> wrote:
Thank you, Yoav,
I will have it fixed, listen to this channel for other suggestions and have= the
revised version submitted by Mar 8th.

Sean


In your mail:
>From: Yoav Nir <ynir@checkpoi= nt.com>
>Reply-To:
>To: "'Paul Hoffman'" <paul.hoffman@vpnc.org>, IPsecme WG <ipsec@ietf.org>
>Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.= txt
>Date:Thu, 4 Mar 2010 07:16:55 +0200
>
>Paragraph 5 of section #2:
> =C2=A0 =C2=A0MUST accept any length that results in proper alignment. = =C2=A0It should
> =C2=A0 =C2=A0be noticed that the ESP [RFC4303] Encrypted Payload requi= res
>
> Please change "noticed" to "noted".
>
> Other than that, the document looks good enough for implementation. >
> >A New Internet-Draft is av= ailable from the on-line Internet-Drafts
>>directories.
>>This draft is a work item of the IP Security Maintenance and Extens= ions Working
Group of the IETF.
>>
>> =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Usi= ng Advanced Encryption Standard (AES) Counter Mode with IKEv2
>> =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : S. Shen, Y. M= ao, S. murthy
>> =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ie= tf-ipsecme-aes-ctr-ikev2-05.txt
>> =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 10<= br> >> =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 2010-3-2
>>
>>This document describes the usage of Advanced Encryption Standard >> =C2=A0 Counter Mode (AES-CTR), with an explicit initialization vec= tor, by
>> =C2=A0 IKEv2 for encrypting the IKEv2 exchanges that follow the IK= E_SA_INIT
>> =C2=A0 exchange.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/= draft-ietf-ipsecme-aes-ctr-ikev2-05.txt
>
>Based on Pasi's AD review, the authors significantly shortened the = document. It
seems prudent to have the WG review the new, shorter version. In particular= , it
would be good for developers to look at the new short document and see if i= t is
complete enough to implement from.
>
>This review cycle will end in a week, but please do the review early in= case
problems are found.
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec
>
>Scanned by Check Point Total Security Gateway.
>_______________________________________________
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec



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

--0016e6dab0ec8c46930480f35057-- From kivinen@iki.fi Thu Mar 4 03:47:23 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB593A8913 for ; Thu, 4 Mar 2010 03:47:23 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5VnhdGgRGRb for ; Thu, 4 Mar 2010 03:47:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1299B3A863F for ; Thu, 4 Mar 2010 03:47:21 -0800 (PST) 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 o24BlIku022491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Mar 2010 13:47:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o24BlH0s019906; Thu, 4 Mar 2010 13:47:17 +0200 (EET) 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: <19343.40389.179402.103424@fireball.kivinen.iki.fi> Date: Thu, 4 Mar 2010 13:47:17 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: IPsecme WG Subject: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 11:47:23 -0000 Paul Hoffman writes: > Based on Pasi's AD review, the authors significantly shortened the > document. It seems prudent to have the WG review the new, shorter > version. In particular, it would be good for developers to look at > the new short document and see if it is complete enough to implement > from. > > This review cycle will end in a week, but please do the review early > in case problems are found. The draft looks good, but I would clarify the security considerations section a bit. Now it says: Security considerations explained in section 7 of [RFC3686] are entirely relevant for this draft also. The security considerations on fresh keys and integrity protection in section 7 of [RFC3686] are totally applicable on using AES-CTR in IKEv2; see [RFC3686] for details. Due to this reasons, static keys are never used for the IKE SA and the IKE_SA always uses integrity protection. The last paragraph is bit misleading, as there is no way static keys can be used in IKE SA at all, and this is not because of the issues of AES-CTR. Also integrity protection is already mandatory for IKEv2 IKE SA regardless whether AES-CTR is used or not. It would be better to replace the last sentence with: As static keys are never used in IKEv2 for IKE_SA and integrity protection is mandatory for IKE_SA, these issues are not applicable for AES-CTR in IKEv2 when protecting IKE_SA. -- kivinen@iki.fi From kivinen@iki.fi Thu Mar 4 03:52:56 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E843A8282 for ; Thu, 4 Mar 2010 03:52:56 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvgC9YW5rQxE for ; Thu, 4 Mar 2010 03:52:55 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7623E3A8407 for ; Thu, 4 Mar 2010 03:52:54 -0800 (PST) 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 o24BqkAX021321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Mar 2010 13:52:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o24BqjG6029361; Thu, 4 Mar 2010 13:52:45 +0200 (EET) 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: <19343.40717.301290.80550@fireball.kivinen.iki.fi> Date: Thu, 4 Mar 2010 13:52:45 +0200 From: Tero Kivinen To: Raj Singh In-Reply-To: <7ccecf671003032200r3e0de9d8te2dcf3aab9dacdea@mail.gmail.com> References: <467681796.13887@cnnic.cn> <7ccecf671003032200r3e0de9d8te2dcf3aab9dacdea@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: ipsec , Sean Shen Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 11:52:56 -0000 Raj Singh writes: > Section 5. IANA Considerations can be reworded in-line with > ikev2bis. It would be better align it with ikev2-parameters iana registry. > 5. IANA Considerations > > IANA has already registered the type and value for AES-CTR. > > Name Number Defined In > -------------------------------------------- > > ENCR_AES_CTR 13 (RFC3686 ) I.e. correct line to be put to the IANA registry will be: Number Name ESP Reference IKEv2 Reference ------------ --------------------- ------------- --------------- 13 ENCR_AES_CTR [RFC3686] [RFC] I.e this document change sthe IKEv2 Reference column of the Transform Type 1 - Encryption Algorithm Transform IDs iana table for number 13 - ENCR_AES_CTR from "-" to refer this document instead. -- kivinen@iki.fi From uri@ll.mit.edu Thu Mar 4 09:08:54 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D6B3A8D4F; Thu, 4 Mar 2010 09:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxaEWaZ613lM; Thu, 4 Mar 2010 09:08:53 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id F34FB3A8B85; Thu, 4 Mar 2010 09:08:52 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id o24H5AO7032437; Thu, 4 Mar 2010 12:08:49 -0500 From: "Blumenthal, Uri - 0662 - MITLL" To: "'pgut001@cs.auckland.ac.nz'" Date: Thu, 4 Mar 2010 12:08:43 -0500 Thread-Topic: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq7KC8PKsqPZeyaS82L9IZwtcsVqQAlSlXs Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003040140 Message-Id: <20100304170852.F34FB3A8B85@core3.amsl.com> Cc: "'ipsec@ietf.org'" , "'cfrg@irtf.org'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:08:54 -0000 V2VsbCwgZHVyaW5nIG15IGxvbmcgYW5kIGZydWl0ZnVsIGNhcmVlciBJJ3ZlIGNvbWUgYWNyb3Nz IG1hbnkgYXNpbmluZSBzdGF0ZW1lbnRzIC0gYnV0IHRoaXMgcGVhcmwgZnJvbSB5b3VyIGNvbGxl Y3Rpb24gb3V0c2hpbmVzIG1pbmUhIEluZGVlZCAic3RyYWlnaHQgZnJvbSB0aGUgaG9yc2UncyIg KG9yIGluIHRoZSBjb250ZXh0IC0gIm11bGUncyI/KSBtb3V0aCAobm8gb2ZmZW5zZSBtZWFudCB0 byB0aG9zZSB3b25kZXJmdWwgZXF1ZXN0cmlhbnMpLg0KDQpJJ20gc3RydWNrIHNwZWVjaGxlc3Mg KHdoaWNoIGlzIHVudXN1YWwsIGFzIGFueWJvZHkgd2hvIGtub3dzIG1lIHdvdWxkIGNvbmZpcm0g Oi0pLg0KDQpSZWdhcmRzLA0KVXJpDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZy b206IHBndXQwMDEgPHBndXQwMDFAd2ludGVybXV0ZTAyLmNzLmF1Y2tsYW5kLmFjLm56Pg0KVG86 IHBndXQwMDFAY3MuYXVja2xhbmQuYWMubnogPHBndXQwMDFAY3MuYXVja2xhbmQuYWMubno+OyBC bHVtZW50aGFsLCBVcmkgLSAwNjYyIC0gTUlUTEwNCkNjOiBjZnJnQGlydGYub3JnIDxjZnJnQGly dGYub3JnPjsgaXBzZWNAaWV0Zi5vcmcgPGlwc2VjQGlldGYub3JnPg0KU2VudDogV2VkIE1hciAw MyAxODoyMDo1MyAyMDEwClN1YmplY3Q6IFJlOiBbQ2ZyZ10gW0lQc2VjXSBCZWdpbm5pbmcgZGlz Y3Vzc2lvbiBvbiBzZWN1cmUgcGFzc3dvcmQtb25seSBhdXRoZW50aWNhdGlvbiBmb3IgSUtFdjIN Cg0KIkJsdW1lbnRoYWwsIFVyaSAtIDA2NjIgLSBNSVRMTCIgPHVyaUBsbC5taXQuZWR1PiB3cml0 ZXM6DQoNCj5PbiB0aGUgdmVuZG9yIHNpZGUgLSBwZXJoYXBzIEVLRSBwYXRlbnQgY29uY2VybiB3 YXMgdGhlIGNhdXNlICh5b3UNCj5pbXBsZW1lbnQvc2VsbCBmcmVlIFNSUCBhbmQgZ2V0IHNsYXBw ZWQgd2l0aCBFS0UgbGljZW5zaW5nKT8gQW5kIHRoZSB1c2Vycw0KPmZvdW5kIGFsdGVybmF0aXZl IHNvbHV0aW9ucyBpbiB0aGUgbWVhbndoaWxlPw0KDQpOb3BlLiAgSXQncyBiZWVuIHN1cHBvcnRl ZCBpbiBPcGVuU1NMIHNpbmNlIDAuOS45LCBidXQgbm90IGluIGFueSBicm93c2VyLg0KVGhlIHJl YXNvbiBmb3Igbm90IHN1cHBvcnRpbmcgaXQgaW4gRmlyZWZveCBpcyBzbyBhc3RvbmlzaGluZ2x5 IGJvbmVoZWFkZWQNCnRoYXQgSSdsbCBxdW90ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSB0byBtYWtl IHN1cmUgdGhhdCBpdCdzIHN0cmFpZ2h0IGZyb20gdGhlDQpob3JzZSdzIG1vdXRoICgiUFNLIGNp cGhlciBzdWl0ZXMiID0gbm9uLXBhdGVudC1lbmN1bWJlcmVkIEVLRSBpbiBUTFMtdGFsayk6DQoN Ci0tIFNuaXAgLS0NCg0KU3ViamVjdDogUmU6IE5TUyBpbXBsZW1lbnRhdGlvbiBvZiBUTFMtUFNL LyBSRkMgNDI3OQ0KRGF0ZTogVHVlLCAxNCBPY3QgMjAwOCAxNDowMToxMCAtMDcwMA0KRnJvbTog TmVsc29uIEIgQm9seWFyZCA8bmVsc29uQGJvbHlhcmQubWU+DQpSZXBseS1UbzogbW96aWxsYSdz IGNyeXB0byBjb2RlIGRpc2N1c3Npb24gbGlzdA0KPGRldi10ZWNoLWNyeXB0b0BsaXN0cy5tb3pp bGxhLm9yZz4NCg0KamVuZ2xlckBiZXJrZWxleS5lZHUgd3JvdGUsIE9uIDIwMDgtMTAtMTQgMTM6 NTIgUERUOg0KPiBJIHdhcyB3b25kZXJpbmcgaWYgaW1wbGVtZW50YXRpb24gb2YgVExTLVBTSyAo UkZDIDQyNzkpIGlzIGN1cnJlbnRseSBpbg0KPiBkZXZlbG9wbWVudC4gSSBkbyBub3Qgc2VlIGl0 IGluIHRoZSBjdXJyZW50IE5TUyBzb3VyY2Ugb3Igcm9hZG1hcC4gVGhhbmsNCj4geW91IGZvciBh bnkgaGVscC4NCj4NCj4gLUpvaG4gRW5nbGVyDQoNCk5vLiAgVGhlcmUgYXJlIG5vIHBsYW5zIHRv IGluY2x1ZGUgYW55IFBTSyBjaXBoZXIgc3VpdGVzIGluIE5TUy4NCkJlY2F1c2Ugb2YgdGhlIGVu b3Jtb3VzIHBvdGVudGlhbCBmb3IgUFNLIGNpcGhlciBzdWl0ZXMgdG8gYmUNCm1pc3VzZWQgYnkg YXBwbGljYXRpb24gZGV2ZWxvcGVycywgdGhlcmUgaXMgc3Ryb25nIHJlc2lzdGFuY2UgdG8NCmlu Y29ycG9yYXRpbmcgdGhlbSBpbnRvIE5TUy4NCg0KLS0gU25pcCAtLQ0KDQpBcyBmb3IgTWljcm9z b2Z0LCBPcGVyYSwgZXRjIHdobyBrbm93cz8gIChJZiB5b3Ugd29yayBvbiwgb3IgaGF2ZSB3b3Jr ZWQgb24sDQphbnkgb2YgdGhlc2UgYnJvd3NlcnMsIEknZCBsaWtlIHRvIGhlYXIgbW9yZSBhYm91 dCB3aHkgaXQgaGFzbid0IGJlZW4NCmNvbnNpZGVyZWQpLiAgSSB0aGluayBpdCdsbCBiZSBhIGNv bWJpbmF0aW9uIG9mIHR3byBmYWN0b3JzOg0KDQoxLiBFdmVyeW9uZSBrbm93cyB0aGF0IHBhc3N3 b3JkcyBhcmUgaW5zZWN1cmUgc28gaXQncyBub3Qgd29ydGggdHJ5aW5nIHRvIGRvDQogICBhbnl0 aGluZyB3aXRoIHRoZW0uDQoNCjIuIElmIHlvdSBhZGQgZmFpbHNhZmUgbXV0dWFsIGF1dGhlbnRp Y2F0aW9uIHZpYSBFS0UgdG8gYnJvd3NlcnMsIENBcyBiZWNvbWUNCiAgIGVudGlyZWx5IHJlZHVu ZGFudC4NCg0KU28gdGhlIGJyb3dzZXIgdmVuZG9ycycgYXBwcm9hY2ggaXMgdG8gaWdub3JlIEVL RSBhbmQga2VlcCBvbiB3YWl0aW5nIGZvciBQS0kNCnRvIHN0YXJ0IHdvcmtpbmcsIGZvcmV2ZXIg aWYgbmVjZXNzYXJ5LiAgIlBLSSBtZXVydCwgZWxsZSBuZSBzZSByZW5kIHBhcyEiIFswXS4NCg0K UGV0ZXIuDQoNClswXSBIYXQgdGlwIHRvIEx1dGhlciBNYXJ0aW4gZm9yIHRoZSBxdW90ZSA6LSku DQo= From wwwrun@core3.amsl.com Thu Mar 4 11:45:13 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C0AB13A8E4C; Thu, 4 Mar 2010 11:45:13 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100304194513.C0AB13A8E4C@core3.amsl.com> Date: Thu, 4 Mar 2010 11:45:13 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] Last Call: draft-ietf-ipsecme-ikev2bis (Internet Key Exchange Protocol: IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 04 Mar 2010 19:45:13 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Internet Key Exchange Protocol: IKEv2 ' as a Proposed Standard 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 2010-03-18. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17667&rfc_flag=0 From yaronf@checkpoint.com Thu Mar 4 12:06:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25A13A8E51; Thu, 4 Mar 2010 12:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rZZqZgZqXAV; Thu, 4 Mar 2010 12:06:04 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5323A3A8E4B; Thu, 4 Mar 2010 12:06:04 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o24K5xsd005078; Thu, 4 Mar 2010 22:05:59 +0200 (IST) X-CheckPoint: {4B901158-2-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 4 Mar 2010 22:06:19 +0200 From: Yaron Sheffer To: "Blumenthal, Uri - 0662 - MITLL" , "'pgut001@cs.auckland.ac.nz'" Date: Thu, 4 Mar 2010 22:05:57 +0200 Thread-Topic: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq7KC8PKsqPZeyaS82L9IZwtcsVqQAlSlXsAAYACsA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB5975@il-ex01.ad.checkpoint.com> References: <20100304170852.F34FB3A8B85@core3.amsl.com> In-Reply-To: <20100304170852.F34FB3A8B85@core3.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: "'ipsec@ietf.org'" , "'cfrg@irtf.org'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 20:06:05 -0000 Can someone please explain the joke to me? Nelson was asked about TLS-PSK (= RFC 4279) and he replied that it can easily be abused. TLS-PSK (similarly t= o IKE-PSK) is vulnerable to dictionary attacks if used with a short secret = (a.k.a. "password"), at least in the presence of an active attacker. So I t= hink his response was entirely appropriate. What am I missing? Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Blumenthal, Uri - 0662 - MITLL > Sent: Thursday, March 04, 2010 19:09 > To: 'pgut001@cs.auckland.ac.nz' > Cc: 'ipsec@ietf.org'; 'cfrg@irtf.org' > Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password- > only authentication for IKEv2 >=20 > Well, during my long and fruitful career I've come across many asinine > statements - but this pearl from your collection outshines mine! Indeed > "straight from the horse's" (or in the context - "mule's"?) mouth (no > offense meant to those wonderful equestrians). >=20 > I'm struck speechless (which is unusual, as anybody who knows me would > confirm :-). >=20 > Regards, > Uri >=20 > ----- Original Message ----- > From: pgut001 > To: pgut001@cs.auckland.ac.nz ; Blumenthal, > Uri - 0662 - MITLL > Cc: cfrg@irtf.org ; ipsec@ietf.org > Sent: Wed Mar 03 18:20:53 2010 > Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password- > only authentication for IKEv2 >=20 > "Blumenthal, Uri - 0662 - MITLL" writes: >=20 > >On the vendor side - perhaps EKE patent concern was the cause (you > >implement/sell free SRP and get slapped with EKE licensing)? And the > users > >found alternative solutions in the meanwhile? >=20 > Nope. It's been supported in OpenSSL since 0.9.9, but not in any > browser. > The reason for not supporting it in Firefox is so astonishingly > boneheaded > that I'll quote the original message to make sure that it's straight > from the > horse's mouth ("PSK cipher suites" =3D non-patent-encumbered EKE in TLS- > talk): >=20 > -- Snip -- >=20 > Subject: Re: NSS implementation of TLS-PSK/ RFC 4279 > Date: Tue, 14 Oct 2008 14:01:10 -0700 > From: Nelson B Bolyard > Reply-To: mozilla's crypto code discussion list > >=20 > jengler@berkeley.edu wrote, On 2008-10-14 13:52 PDT: > > I was wondering if implementation of TLS-PSK (RFC 4279) is currently > in > > development. I do not see it in the current NSS source or roadmap. > Thank > > you for any help. > > > > -John Engler >=20 > No. There are no plans to include any PSK cipher suites in NSS. > Because of the enormous potential for PSK cipher suites to be > misused by application developers, there is strong resistance to > incorporating them into NSS. >=20 > -- Snip -- >=20 > As for Microsoft, Opera, etc who knows? (If you work on, or have > worked on, > any of these browsers, I'd like to hear more about why it hasn't been > considered). I think it'll be a combination of two factors: >=20 > 1. Everyone knows that passwords are insecure so it's not worth trying > to do > anything with them. >=20 > 2. If you add failsafe mutual authentication via EKE to browsers, CAs > become > entirely redundant. >=20 > So the browser vendors' approach is to ignore EKE and keep on waiting > for PKI > to start working, forever if necessary. "PKI meurt, elle ne se rend > pas!" [0]. >=20 > Peter. >=20 > [0] Hat tip to Luther Martin for the quote :-). > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From smoonen@us.ibm.com Thu Mar 4 12:21:07 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD533A8C7E; Thu, 4 Mar 2010 12:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy-+mac+eM2r; Thu, 4 Mar 2010 12:21:03 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id DD67228C0FC; Thu, 4 Mar 2010 12:21:02 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o24KI1Nm019169; Thu, 4 Mar 2010 13:18:01 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o24KKaLg054094; Thu, 4 Mar 2010 13:20:37 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o24DKZQZ021050; Thu, 4 Mar 2010 06:20:35 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o24DKZn9021046; Thu, 4 Mar 2010 06:20:35 -0700 In-Reply-To: References: X-KeepSent: 3C2D6004:1013154C-852576DC:006F1BFA; type=4; name=$KeepSent To: Paul Hoffman X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: Scott C Moonen Date: Thu, 4 Mar 2010 15:20:32 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/04/2010 13:20:34 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFC4FDFFC9D6A8f9e8a93df938690918c0ABBFC4FDFFC9D6A" Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 20:21:07 -0000 --0__=0ABBFC4FDFFC9D6A8f9e8a93df938690918c0ABBFC4FDFFC9D6A Content-type: multipart/alternative; Boundary="1__=0ABBFC4FDFFC9D6A8f9e8a93df938690918c0ABBFC4FDFFC9D6A" --1__=0ABBFC4FDFFC9D6A8f9e8a93df938690918c0ABBFC4FDFFC9D6A Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Caveat: I have not reviewed in detail. But I noticed a typo below line 3020 -- "may hve". Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen |------------> | From: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |Paul Hoffman = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |------------> | To: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |IPsecme WG = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |------------> | Date: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |03/03/2010 12:51 PM = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |------------> | Subject: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |[IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Security Maintenance and Extension= s Working Group of the IETF. > > Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 > Author(s) : S. Shen, Y. Mao, S. murthy > Filename : draft-ietf-ipsecme-aes-ctr-ikev2-05.txt > Pages : 10 > Date : 2010-3-2 > >This document describes the usage of Advanced Encryption Standard > Counter Mode (AES-CTR), with an explicit initialization vector, by > IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INI= T > exchange. > >A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05= .txt Based on Pasi's AD review, the authors significantly shortened the document. It seems prudent to have the WG review the new, shorter versi= on. In particular, it would be good for developers to look at the new short= document and see if it is complete enough to implement from. This review cycle will end in a week, but please do the review early in= case problems are found. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFC4FDFFC9D6A8f9e8a93df938690918c0ABBFC4FDFFC9D6A Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Caveat: I have not reviewed in detail.

But I noticed a typo below line 3020 -- "may hve".


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactivePaul Hoffman ---0= 3/03/2010 12:51:54 PM--->A New Internet-Draft is available from the = on-line Internet-Drafts

= =
3D=
From:		= 3D""
Paul Hoffman <paul.hoffman@vpnc.org>
3D=
To:
IPsecme WG <ipsec@ietf.org>
3D=
Date:		= 3D""
03/03/2010 12:51 PM
3D=
Subject:		3D""
[IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2= -05.txt




>A New Internet-Draft is available from the on-line Internet-Dra= fts
>directories.
>This draft is a work item of the IP Security Maintenance and Extens= ions Working Group of the IETF.
>
> Title : Using Advanced Encryption Standard (AES) Counter Mo= de with IKEv2
> Author(s) : S. Shen, Y. Mao, S. murthy
> Filename : draft-ietf-ipsecme-aes-ctr-ikev2-05.txt
> Pages : 10
> Date : 2010-3-2
>
>This document describes the usage of Advanced Encryption Standard >   Counter Mode (AES-CTR), with an explicit initialization vec= tor, by
>   IKEv2 for encrypting the IKEv2 exchanges that follow the IK= E_SA_INIT
>   exchange.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft= -ietf-ipsecme-aes-ctr-ikev2-05.txt

Based on Pasi's AD review, the authors significantly shortened the docu= ment. It seems prudent to have the WG review the new, shorter version. = In particular, it would be good for developers to look at the new short= document and see if it is complete enough to implement from.

This review cycle will end in a week, but please do the review early in= case problems are found.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec


= --1__=0ABBFC4FDFFC9D6A8f9e8a93df938690918c0ABBFC4FDFFC9D6A-- --0__=0ABBFC4FDFFC9D6A8f9e8a93df938690918c0ABBFC4FDFFC9D6A Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFC4FDFFC9D6A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFC4FDFFC9D6A8f9e8a93df938690918c0ABBFC4FDFFC9D6A Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBFC4FDFFC9D6A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFC4FDFFC9D6A8f9e8a93df938690918c0ABBFC4FDFFC9D6A-- From ynir@checkpoint.com Thu Mar 4 14:45:31 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518A528C0DE; Thu, 4 Mar 2010 14:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EQi33pf+zeD; Thu, 4 Mar 2010 14:45:30 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id ED04D3A8714; Thu, 4 Mar 2010 14:45:29 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o24MjMsd020439; Fri, 5 Mar 2010 00:45:22 +0200 (IST) X-CheckPoint: {4B9036B2-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 5 Mar 2010 00:45:42 +0200 From: Yoav Nir To: Yaron Sheffer , "Blumenthal, Uri - 0662 - MITLL" , "'pgut001@cs.auckland.ac.nz'" Date: Fri, 5 Mar 2010 00:44:50 +0200 Thread-Topic: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq7KC8PKsqPZeyaS82L9IZwtcsVqQAlSlXsAAYACsAABbz49Q== Message-ID: <006FEB08D9C6444AB014105C9AEB133FB3764FB9FA@il-ex01.ad.checkpoint.com> References: <20100304170852.F34FB3A8B85@core3.amsl.com>, <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB5975@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB5975@il-ex01.ad.checkpoint.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: "'ipsec@ietf.org'" , "'cfrg@irtf.org'" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 22:45:31 -0000 Explaining a joke spoils all the fun, but here goes: It's not like PKI is working out better for user authentication. And password-in-https-form is also vulnerable to online dictionary attacks. Now if they were using TLS-EAP.... But that, of course, suffers from excessive layering. ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Yaron Sh= effer [yaronf@checkpoint.com] Sent: Thursday, March 04, 2010 22:05 To: Blumenthal, Uri - 0662 - MITLL; 'pgut001@cs.auckland.ac.nz' Cc: 'ipsec@ietf.org'; 'cfrg@irtf.org' Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only au= thentication for IKEv2 Can someone please explain the joke to me? Nelson was asked about TLS-PSK (= RFC 4279) and he replied that it can easily be abused. TLS-PSK (similarly t= o IKE-PSK) is vulnerable to dictionary attacks if used with a short secret = (a.k.a. "password"), at least in the presence of an active attacker. So I t= hink his response was entirely appropriate. What am I missing? Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Blumenthal, Uri - 0662 - MITLL > Sent: Thursday, March 04, 2010 19:09 > To: 'pgut001@cs.auckland.ac.nz' > Cc: 'ipsec@ietf.org'; 'cfrg@irtf.org' > Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password- > only authentication for IKEv2 > > Well, during my long and fruitful career I've come across many asinine > statements - but this pearl from your collection outshines mine! Indeed > "straight from the horse's" (or in the context - "mule's"?) mouth (no > offense meant to those wonderful equestrians). > > I'm struck speechless (which is unusual, as anybody who knows me would > confirm :-). > > Regards, > Uri > > ----- Original Message ----- > From: pgut001 > To: pgut001@cs.auckland.ac.nz ; Blumenthal, > Uri - 0662 - MITLL > Cc: cfrg@irtf.org ; ipsec@ietf.org > Sent: Wed Mar 03 18:20:53 2010 > Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password- > only authentication for IKEv2 > > "Blumenthal, Uri - 0662 - MITLL" writes: > > >On the vendor side - perhaps EKE patent concern was the cause (you > >implement/sell free SRP and get slapped with EKE licensing)? And the > users > >found alternative solutions in the meanwhile? > > Nope. It's been supported in OpenSSL since 0.9.9, but not in any > browser. > The reason for not supporting it in Firefox is so astonishingly > boneheaded > that I'll quote the original message to make sure that it's straight > from the > horse's mouth ("PSK cipher suites" =3D non-patent-encumbered EKE in TLS- > talk): > > -- Snip -- > > Subject: Re: NSS implementation of TLS-PSK/ RFC 4279 > Date: Tue, 14 Oct 2008 14:01:10 -0700 > From: Nelson B Bolyard > Reply-To: mozilla's crypto code discussion list > > > jengler@berkeley.edu wrote, On 2008-10-14 13:52 PDT: > > I was wondering if implementation of TLS-PSK (RFC 4279) is currently > in > > development. I do not see it in the current NSS source or roadmap. > Thank > > you for any help. > > > > -John Engler > > No. There are no plans to include any PSK cipher suites in NSS. > Because of the enormous potential for PSK cipher suites to be > misused by application developers, there is strong resistance to > incorporating them into NSS. > > -- Snip -- > > As for Microsoft, Opera, etc who knows? (If you work on, or have > worked on, > any of these browsers, I'd like to hear more about why it hasn't been > considered). I think it'll be a combination of two factors: > > 1. Everyone knows that passwords are insecure so it's not worth trying > to do > anything with them. > > 2. If you add failsafe mutual authentication via EKE to browsers, CAs > become > entirely redundant. > > So the browser vendors' approach is to ignore EKE and keep on waiting > for PKI > to start working, forever if necessary. "PKI meurt, elle ne se rend > pas!" [0]. > > Peter. > > [0] Hat tip to Luther Martin for the quote :-). > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway.= From paul.hoffman@vpnc.org Thu Mar 4 15:01:42 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A99B3A8CAF for ; Thu, 4 Mar 2010 15:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.904 X-Spam-Level: X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DxGR8r9+MOx for ; Thu, 4 Mar 2010 15:01:39 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id BCA713A8994 for ; Thu, 4 Mar 2010 15:01:38 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o24N1cwm029803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Mar 2010 16:01:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 4 Mar 2010 15:01:36 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2bis (Internet Key Exchange Protocol: IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 23:01:42 -0000 Of definite interest to the WG: >X-Original-To: ietf-announce@ietf.org >Delivered-To: ietf-announce@core3.amsl.com >X-idtracker: yes >To: IETF-Announce >From: The IESG >Subject: Last Call: draft-ietf-ipsecme-ikev2bis (Internet Key Exchange > Protocol: IKEv2) to Proposed Standard >Date: Thu, 4 Mar 2010 11:45:13 -0800 (PST) >Cc: ipsec@ietf.org >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.9 >Reply-To: ietf@ietf.org >List-Id: "IETF announcement list. No discussions." >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: ietf-announce-bounces@ietf.org > >The IESG has received a request from the IP Security Maintenance and >Extensions WG (ipsecme) to consider the following document: > >- 'Internet Key Exchange Protocol: IKEv2 ' > as a Proposed Standard > >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 2010-03-18. 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. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-08.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17667&rfc_flag=0 > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From yaronf@checkpoint.com Thu Mar 4 22:28:02 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236873A8EDE; Thu, 4 Mar 2010 22:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.088 X-Spam-Level: X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxwHkNjnXzY7; Thu, 4 Mar 2010 22:27:58 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id B0B773A8ED9; Thu, 4 Mar 2010 22:27:42 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o256Rcsd024136; Fri, 5 Mar 2010 08:27:38 +0200 (IST) X-CheckPoint: {4B90A306-1-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 5 Mar 2010 08:27:57 +0200 From: Yaron Sheffer To: Peter Gutmann , "uri@ll.mit.edu" Date: Fri, 5 Mar 2010 08:27:36 +0200 Thread-Topic: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 Thread-Index: Acq799nyB6tDKbUBQ6KNUclA+FHs/QANAOjA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB5981@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05CB5975@il-ex01.ad.checkpoint.com> In-Reply-To: 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: "ipsec@ietf.org" , "cfrg@irtf.org" Subject: Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 06:28:02 -0000 Hi Peter, I completely agree with the rest of the argument. But I don't know of a rea= listic way to do it with TLS-PSK (people will *always* use short passwords,= it's not like it's the exception to the rule). TLS-SRP is one possible sol= ution. Or, as Yoav suggests, TLS-EAP with several alternatives, including E= AP-PWD and EAP-EKE. In some interesting cases, EAP-AKA might also be approp= riate. Unfortunately the IAB thinks that TLS-EAP is Bad Bad Bad (http://tools.ietf= .org/html/draft-iab-auth-mech-07#section-10.2.4). So it's back to PKI. Sigh= . Thanks, Yaron > -----Original Message----- > From: pgut001 [mailto:pgut001@wintermute02.cs.auckland.ac.nz] On Behalf > Of Peter Gutmann > Sent: Friday, March 05, 2010 2:07 > To: pgut001@cs.auckland.ac.nz; uri@ll.mit.edu; Yaron Sheffer > Cc: cfrg@irtf.org; ipsec@ietf.org > Subject: RE: [IPsec] [Cfrg] Beginning discussion on secure password- > only authentication for IKEv2 >=20 > Yaron Sheffer writes: >=20 > >Can someone please explain the joke to me? Nelson was asked about TLS- > PSK > >(RFC 4279) and he replied that it can easily be abused. TLS-PSK > (similarly to > >IKE- PSK) is vulnerable to dictionary attacks if used with a short > secret > >(a.k.a. "password"), at least in the presence of an active attacker. > So I > >think his response was entirely appropriate. What am I missing? >=20 > Thinking through the rest of the argument, which is: >=20 > - We currently have a (supposedly) multi-billion dollar global industry > built > around the total failure of the existing browser authentication > model. >=20 > - Mutual authentication, in which the server has to prove knowledge of > the > user's credentials before the user can connect, would cause a serious > headache for phishers. >=20 > - The FF developers have chosen not to implement this because, in the > special- > case situation where it's done really badly, it could theoretically > be > abused (note the special-case qualification of "if used with a short > secret", for which the answer is "well don't do that, then"). >=20 > This is balanced against the currently-used model which pretty much > doesn't > work at all right out of the box, no matter what you do with it. >=20 > - Phishers the world over breathe a sigh of relief, and business > continues as > usual. >=20 > Peter. >=20 > Scanned by Check Point Total Security Gateway. From Pasi.Eronen@nokia.com Sat Mar 6 03:56:18 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D74A3A90BF; Sat, 6 Mar 2010 03:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc0T8M1E3Af0; Sat, 6 Mar 2010 03:56:17 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id BF7E63A8F5C; Sat, 6 Mar 2010 03:56:16 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o26Bu14j029255; Sat, 6 Mar 2010 13:56:16 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 13:55:49 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 13:55:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 13:55:39 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Sat, 6 Mar 2010 12:55:39 +0100 From: To: , Date: Sat, 6 Mar 2010 12:55:37 +0100 Thread-Topic: IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 Thread-Index: Acq9I+7uRCNmSYuURFeQHnq6luW6uw== Message-ID: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.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 X-OriginalArrivalTime: 06 Mar 2010 11:55:39.0924 (UTC) FILETIME=[F10E6D40:01CABD23] X-Nokia-AV: Clean Subject: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 11:56:18 -0000 I've gone through changes from 06 to 07/08, and my earlier comments, and found one minor bug and couple of small editorial suggestions/nits. The bug first: - Section 3.3.6 says "If one of the proposals offered is for the Diffie-Hellman group of NONE, the responder MUST ignore the initiator's KE payload and omit the KE payload from the response." This seems wrong: it seems to say that if the initiator proposes DH group NONE, the responder must select it. However, negotiation of DH groups and KE payload is already well described in Sections 1.2 and 1.3 (paragraphs mentioning INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is completely redundant. Thus, I'd propose just deleting the whole paragraph. Editorial suggestions/nits: - Section 2.7, last paragraph, is in wrong place; rest of 2.7 has nothing to do with this topic, which is in 2.6. Suggested place: 2.6, end of paragraph starting with "In the first message". Also, "the responder's SPI will be zero" should be "the responder's=20 SPI will be zero also in the response message" (since the responder's=20 SPI is always zero in the IKE_SA_INIT request, but that's not what=20 this paragraph is about). =20 - One of the changes is listed in Section 1.7 twice. I'd suggest combining In section 1.3.2, changed "The KEi payload SHOULD be included" to be "The KEi payload MUST be included". This also led to changes in section 2.18. and Section 2.18 requires doing a Diffie-Hellman exchange when rekeying the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- Hellman exchange was optional, but this was not useful (or appropriate) when rekeying the IKE_SA. as follows: This document requires doing a Diffie-Hellman exchange when rekeying the IKE_SA (and thus requires including the KEi/KEr payloads). In theory, RFC 4306 allowed a policy where the Diffie-Hellman exchange was optional (and KEi/KEr payloads could be omitted), this was not useful (or appropriate) when rekeying the IKE_SA. - Section 2.8.2, last paragraph: it's not quite obvious why this should be negotiated (the reason is that this notification was not included in RFC 4306, but this section never says that). Suggested rephrasing The TEMPORARY_FAILURE notification was not included in RFC 4306, and support of the TEMPORARY_FAILURE notification is not negotiated. Thus, older peers (implementing RFC 4306) may receive [... rest of the paragraph unchanged...] - Section 2.23, paragraph starting: "An initiator can use...". IKEv2 packets are always over UDP, so IMHO the text would benefit from some more precision when talking about UDP encapsulation. Suggested edits: OLD: An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE. When either side is using port 4500, sending with UDP encapsulation is not required, but understanding received IKE and ESP packets with UDP encapsulation is required. UDP encapsulation MUST NOT be done on port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. Either side can decide whether or not to use UDP encapsulation irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST send UDP encapsulated packets. NEW: An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE. When either side is using port 4500, sending ESP with UDP encapsulation is not required, but understanding received UDP encapsulated ESP packets is required. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated ESP and non-UDP encapsulated ESP packets at any time. Either side can decide whether or not to use UDP encapsulation for ESP irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST use UDP encapsulation for ESP. - Section 3.5: "ID_IPV6_ADDR instead of ID_IPV6_ADDR" should be "...instead of ID_IPV4_ADDR"? - Reference [PKIX] should be updated from RFC 3280 to 5280. - Section 2.23.1, "hve" -> "have" Best regards, Pasi From paul.hoffman@vpnc.org Sat Mar 6 17:27:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A8E28C227; Sat, 6 Mar 2010 17:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.919 X-Spam-Level: X-Spam-Status: No, score=-5.919 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ueKNvSvxvt0; Sat, 6 Mar 2010 17:27:33 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 37E6428C226; Sat, 6 Mar 2010 17:27:33 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o271RYHE081831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Mar 2010 18:27:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com> Date: Sat, 6 Mar 2010 17:27:32 -0800 To: , , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 01:27:34 -0000 At 12:55 PM +0100 3/6/10, wrote: >Editorial suggestions/nits: > >- Section 2.7, last paragraph, is in wrong place; rest of 2.7 has >nothing to do with this topic, which is in 2.6. Suggested place: 2.6, >end of paragraph starting with "In the first message". >Also, "the responder's SPI will be zero" should be "the responder's >SPI will be zero also in the response message" (since the responder's >SPI is always zero in the IKE_SA_INIT request, but that's not what >this paragraph is about). Agree. >- One of the changes is listed in Section 1.7 twice. I'd suggest >combining > > In section 1.3.2, changed "The KEi payload SHOULD be included" to be > "The KEi payload MUST be included". This also led to changes in > section 2.18. > >and > > Section 2.18 requires doing a Diffie-Hellman exchange when rekeying > the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- > Hellman exchange was optional, but this was not useful (or > appropriate) when rekeying the IKE_SA. > >as follows: > > This document requires doing a Diffie-Hellman exchange when > rekeying the IKE_SA (and thus requires including the KEi/KEr > payloads). In theory, RFC 4306 allowed a policy where the > Diffie-Hellman exchange was optional (and KEi/KEr payloads could be > omitted), this was not useful (or appropriate) when rekeying the > IKE_SA. Disagree. Where possible, I tried to list the actual sections where changes were made, and your proposed rewording loses the two places. The current text is more explicit than the proposed change. >- Section 2.8.2, last paragraph: it's not quite obvious why this >should be negotiated (the reason is that this notification was not >included in RFC 4306, but this section never says that). Suggested >rephrasing > > The TEMPORARY_FAILURE notification was not included in RFC 4306, > and support of the TEMPORARY_FAILURE notification is not negotiated. > Thus, older peers (implementing RFC 4306) may receive [... rest > of the paragraph unchanged...] Agree. >- Section 2.23, paragraph starting: "An initiator can use...". >IKEv2 packets are always over UDP, so IMHO the text would benefit >from some more precision when talking about UDP encapsulation. >Suggested edits: > >OLD: > An initiator can use port 4500 for both IKE and ESP, regardless of > whether or not there is a NAT, even at the beginning of IKE. When > either side is using port 4500, sending with UDP encapsulation is not > required, but understanding received IKE and ESP packets with UDP > encapsulation is required. UDP encapsulation MUST NOT be done on > port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP > payloads were exchanged during IKE_SA_INIT), all devices MUST be able > to receive and process both UDP encapsulated and non-UDP encapsulated > packets at any time. Either side can decide whether or not to use > UDP encapsulation irrespective of the choice made by the other side. > However, if a NAT is detected, both devices MUST send UDP > encapsulated packets. >NEW: > An initiator can use port 4500 for both IKE and ESP, regardless of > whether or not there is a NAT, even at the beginning of IKE. When > either side is using port 4500, sending ESP with UDP encapsulation > is not required, but understanding received UDP encapsulated ESP > packets is required. If NAT-T is supported (that is, if > NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all > devices MUST be able to receive and process both UDP encapsulated > ESP and non-UDP encapsulated ESP packets at any time. Either side > can decide whether or not to use UDP encapsulation for ESP > irrespective of the choice made by the other side. However, if a > NAT is detected, both devices MUST use UDP encapsulation for ESP. Yes, that's clearer. >- Section 3.5: "ID_IPV6_ADDR instead of ID_IPV6_ADDR" should >be "...instead of ID_IPV4_ADDR"? Yep. >- Reference [PKIX] should be updated from RFC 3280 to 5280. Sure. >- Section 2.23.1, "hve" -> "have" Done. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sat Mar 6 17:52:06 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC293A9034 for ; Sat, 6 Mar 2010 17:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.93 X-Spam-Level: X-Spam-Status: No, score=-5.93 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9UXbgHRQw0Q for ; Sat, 6 Mar 2010 17:52:05 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5728F3A860E for ; Sat, 6 Mar 2010 17:52:05 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o271RYHG081831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Mar 2010 18:27:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sat, 6 Mar 2010 17:11:39 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: Pasi Eronen Subject: [IPsec] Issue #176: What to do with a proposal of NONE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 01:52:06 -0000 Pasi says: Section 3.3.6 says "If one of the proposals offered is for the Diffie-Hellman group of NONE, the responder MUST ignore the initiator's KE payload and omit the KE payload from the response." This seems wrong: it seems to say that if the initiator proposes DH group NONE, the responder must select it. However, negotiation of DH groups and KE payload is already well described in Sections 1.2 and 1.3 (paragraphs mentioning INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is completely redundant. Thus, I'd propose just deleting the whole paragraph. Paul says: That whole paragraph has been there since -00. Only the last sentence was added in -03 almost a year ago. It was added to fix , but I can easily believe that fix was not correct. However, sections 1.2 and 1.3 don't address the issue in the sentence quoted. --Paul Hoffman, Director --VPN Consortium From Pasi.Eronen@nokia.com Sun Mar 7 23:17:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24D23A692A; Sun, 7 Mar 2010 23:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8i2K-C5l643; Sun, 7 Mar 2010 23:17:25 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6EFE93A677D; Sun, 7 Mar 2010 23:17:24 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o287GZwM029515; Mon, 8 Mar 2010 01:17:26 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 09:17:04 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 09:17:00 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 8 Mar 2010 08:16:59 +0100 From: To: , , Date: Mon, 8 Mar 2010 08:16:58 +0100 Thread-Topic: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 Thread-Index: Acq9lWOKOw0+7fnFRxOPZH8X6ltvlwA+WIlg Message-ID: <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: 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 X-OriginalArrivalTime: 08 Mar 2010 07:17:00.0097 (UTC) FILETIME=[5816CB10:01CABE8F] X-Nokia-AV: Clean Subject: Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 07:17:28 -0000 Paul Hoffman wrote: > >- One of the changes is listed in Section 1.7 twice. I'd suggest > >combining > > > > In section 1.3.2, changed "The KEi payload SHOULD be included" to > > be "The KEi payload MUST be included". This also led to changes in > > section 2.18. > > > >and > > > > Section 2.18 requires doing a Diffie-Hellman exchange when rekeying > > the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- > > Hellman exchange was optional, but this was not useful (or > > appropriate) when rekeying the IKE_SA. > > > >as follows: > > > > This document requires doing a Diffie-Hellman exchange when > > rekeying the IKE_SA (and thus requires including the KEi/KEr > > payloads). In theory, RFC 4306 allowed a policy where the > > Diffie-Hellman exchange was optional (and KEi/KEr payloads could be > > omitted), this was not useful (or appropriate) when rekeying the > > IKE_SA. >=20 > Disagree. Where possible, I tried to list the actual sections where > changes were made, and your proposed rewording loses the two places. > The current text is more explicit than the proposed change. Well, this depends on whether you think Section 1.7 should list textual changes in the document, or clarification/changes to the protocol. IMHO, it should be the latter, but I see that currently it's really listing the textual changes (even when they clearly don't have any impact on the protocol); so perhaps listing these separately is consistent with that... Best regards, Pasi From shenshuo@cnnic.cn Mon Mar 8 00:19:31 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959CF3A6781 for ; Mon, 8 Mar 2010 00:19:28 -0800 (PST) X-Quarantine-ID: <6oxvc2SQqQNI> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.42 X-Spam-Level: *** X-Spam-Status: No, score=3.42 tagged_above=-999 required=5 tests=[AWL=2.502, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oxvc2SQqQNI for ; Mon, 8 Mar 2010 00:19:27 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 25EDE3A63EB for ; Mon, 8 Mar 2010 00:19:26 -0800 (PST) Received: (eyou send program); Mon, 08 Mar 2010 16:18:51 +0800 Message-ID: <468036331.20323@cnnic.cn> Received: from unknown (HELO shen) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 08 Mar 2010 16:18:51 +0800 Message-ID: <00af01cabe97$f8de0740$cb7d2dc4@SHEN> From: =?utf-8?Q?Sean_Shen_=E6=B2=88=E7=83=81?= To: "IPsecme WG" References: <467703256.20935@cnnic.cn> Date: Mon, 8 Mar 2010 15:39:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 08:19:31 -0000 PiAgIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDcgb2YgW1JG QzM2ODZdIGFyZQ0KPiAgIGVudGlyZWx5IHJlbGV2YW50IGZvciB0aGlzIGRyYWZ0IGFsc28uICBU aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4gICBvbiBmcmVzaCBrZXlzIGFuZCBpbnRlZ3Jp dHkgcHJvdGVjdGlvbiBpbiBzZWN0aW9uIDcgb2YgW1JGQzM2ODZdIGFyZQ0KPiAgIHRvdGFsbHkg YXBwbGljYWJsZSBvbiB1c2luZyBBRVMtQ1RSIGluIElLRXYyOyBzZWUgW1JGQzM2ODZdIGZvcg0K PiAgIGRldGFpbHMuICBEdWUgdG8gdGhpcyByZWFzb25zLCBzdGF0aWMga2V5cyBhcmUgbmV2ZXIg dXNlZCBmb3IgdGhlIElLRQ0KPiAgIFNBIGFuZCB0aGUgSUtFX1NBIGFsd2F5cyB1c2VzIGludGVn cml0eSBwcm90ZWN0aW9uLg0KPiANCj4gVGhlIGxhc3QgcGFyYWdyYXBoIGlzIGJpdCBtaXNsZWFk aW5nLCBhcyB0aGVyZSBpcyBubyB3YXkgc3RhdGljIGtleXMNCj4gY2FuIGJlIHVzZWQgaW4gSUtF IFNBIGF0IGFsbCwgYW5kIHRoaXMgaXMgbm90IGJlY2F1c2Ugb2YgdGhlIGlzc3VlcyBvZg0KPiBB RVMtQ1RSLiBBbHNvIGludGVncml0eSBwcm90ZWN0aW9uIGlzIGFscmVhZHkgbWFuZGF0b3J5IGZv ciBJS0V2MiBJS0UNCj4gU0EgcmVnYXJkbGVzcyB3aGV0aGVyIEFFUy1DVFIgaXMgdXNlZCBvciBu b3QuIEl0IHdvdWxkIGJlIGJldHRlciB0bw0KPiByZXBsYWNlIHRoZSBsYXN0IHNlbnRlbmNlIHdp dGg6DQo+IA0KPiAgIEFzIHN0YXRpYyBrZXlzIGFyZSBuZXZlciB1c2VkIGluIElLRXYyIGZvciBJ S0VfU0EgYW5kIGludGVncml0eQ0KPiAgIHByb3RlY3Rpb24gaXMgbWFuZGF0b3J5IGZvciBJS0Vf U0EsIHRoZXNlIGlzc3VlcyBhcmUgbm90IGFwcGxpY2FibGUNCj4gICBmb3IgQUVTLUNUUiBpbiBJ S0V2MiB3aGVuIHByb3RlY3RpbmcgSUtFX1NBLg0KDQpBZ3JlZSwgSSB3aWxsIHJld29yZCB0aGlz IHBhcnQuIA0KDQpTZWFu From shenshuo@cnnic.cn Mon Mar 8 00:20:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08FB3A67D3 for ; Mon, 8 Mar 2010 00:20:34 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.962 X-Spam-Level: X-Spam-Status: No, score=0.962 tagged_above=-999 required=5 tests=[AWL=2.458, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2aXfotiQDDC for ; Mon, 8 Mar 2010 00:20:33 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 439C93A6781 for ; Mon, 8 Mar 2010 00:20:30 -0800 (PST) Received: (eyou send program); Mon, 08 Mar 2010 16:18:53 +0800 Message-ID: <468036333.20323@cnnic.cn> Received: from unknown (HELO shen) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 08 Mar 2010 16:18:53 +0800 Message-ID: <00b001cabe97$fa18d130$cb7d2dc4@SHEN> From: =?utf-8?Q?Sean_Shen_=E6=B2=88=E7=83=81?= To: "ipsec" References: <467681796.13887@cnnic.cn><7ccecf671003032200r3e0de9d8te2dcf3aab9dacdea@mail.gmail.com> <467703594.20935@cnnic.cn> Date: Mon, 8 Mar 2010 16:08:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 08:20:34 -0000 DQoNCj4gUmFqIFNpbmdoIHdyaXRlczoNCj4+IFNlY3Rpb24gNS4gSUFOQSBDb25zaWRlcmF0aW9u cyBjYW4gYmUgcmV3b3JkZWQgaW4tbGluZSB3aXRoDQo+PiBpa2V2MmJpcy4gDQo+IA0KPiBJdCB3 b3VsZCBiZSBiZXR0ZXIgYWxpZ24gaXQgd2l0aCBpa2V2Mi1wYXJhbWV0ZXJzIGlhbmEgcmVnaXN0 cnkuIA0KPiANCj4+IDUuIElBTkEgQ29uc2lkZXJhdGlvbnMNCj4+IA0KPj4gSUFOQSBoYXMgYWxy ZWFkeSByZWdpc3RlcmVkIHRoZSB0eXBlIGFuZCB2YWx1ZSBmb3IgQUVTLUNUUi4NCj4+IA0KPj4g TmFtZSAgICAgICAgICAgICAgICAgTnVtYmVyICAgICAgRGVmaW5lZCBJbg0KPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IA0KPj4gRU5DUl9BRVNfQ1RS ICAgICAgICAgMTMgICAgICAgICAgKFJGQzM2ODYgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzM2ODY+KQ0KPiANCj4gSS5lLiBjb3JyZWN0IGxpbmUgdG8gYmUgcHV0IHRvIHRoZSBJQU5B IHJlZ2lzdHJ5IHdpbGwgYmU6DQo+IA0KPiANCj4gTnVtYmVyICAgICAgICBOYW1lICAgICAgICAg ICAgICAgICAgIEVTUCBSZWZlcmVuY2UgIElLRXYyIFJlZmVyZW5jZQ0KPiAtLS0tLS0tLS0tLS0g IC0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgLS0tLS0tLS0tLS0tLSAgLS0tLS0tLS0tLS0tLS0tDQo+ IDEzICAgICAgICAgICAgRU5DUl9BRVNfQ1RSICAgICAgICAgICBbUkZDMzY4Nl0gICAgICBbUkZD PHRoaXMgcmZjPl0NCj4gDQo+IA0KPiBJLmUgdGhpcyBkb2N1bWVudCBjaGFuZ2Ugc3RoZSBJS0V2 MiBSZWZlcmVuY2UgY29sdW1uIG9mIHRoZSANCj4gVHJhbnNmb3JtIFR5cGUgMSAtIEVuY3J5cHRp b24gQWxnb3JpdGhtIFRyYW5zZm9ybSBJRHMgaWFuYSB0YWJsZSBmb3INCj4gbnVtYmVyIDEzIC0g RU5DUl9BRVNfQ1RSIGZyb20gIi0iIHRvIHJlZmVyIHRoaXMgZG9jdW1lbnQgaW5zdGVhZC4NCg0K SWYgd2UgbmVlZCB0byBnaXZlIGNsZWFyIGV4cHJlc3Npb24gb2Ygd2hhdCBhIElBTkEgcmVmZXJl bmNlIHNob3VsZCBiZSwgSSBiZWxpZXZlIHRoZSBpYW5hIHJlZ2lzdHJ5IGlzIHRoZSBwcm9wZXIg Zm9ybWF0IGFzIHNob3dlZCBhYm92ZSAoYWxzbyBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL2lrZXYyLXBhcmFtZXRlcnMpLiANCg0KU2Vhbg== From kivinen@iki.fi Mon Mar 8 07:08:04 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A723A69C5; Mon, 8 Mar 2010 07:08:04 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw6HaQh0s6Uy; Mon, 8 Mar 2010 07:08:02 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 661D73A69C0; Mon, 8 Mar 2010 07:08:02 -0800 (PST) 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 o28F84CJ018689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 17:08:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o28F83Pl009239; Mon, 8 Mar 2010 17:08:03 +0200 (EET) 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: <19349.4819.856265.175704@fireball.kivinen.iki.fi> Date: Mon, 8 Mar 2010 17:08:03 +0200 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 8 min Cc: ipsec@ietf.org, paul.hoffman@vpnc.org, ietf@ietf.org Subject: Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:08:04 -0000 Pasi.Eronen@nokia.com writes: > Paul Hoffman wrote: > > > >- One of the changes is listed in Section 1.7 twice. I'd suggest > > >combining > > > > > > In section 1.3.2, changed "The KEi payload SHOULD be included" to > > > be "The KEi payload MUST be included". This also led to changes in > > > section 2.18. > > > > > >and > > > > > > Section 2.18 requires doing a Diffie-Hellman exchange when rekeying > > > the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- > > > Hellman exchange was optional, but this was not useful (or > > > appropriate) when rekeying the IKE_SA. > > > > > >as follows: > > > > > > This document requires doing a Diffie-Hellman exchange when > > > rekeying the IKE_SA (and thus requires including the KEi/KEr > > > payloads). In theory, RFC 4306 allowed a policy where the > > > Diffie-Hellman exchange was optional (and KEi/KEr payloads could be > > > omitted), this was not useful (or appropriate) when rekeying the > > > IKE_SA. > > > > Disagree. Where possible, I tried to list the actual sections where > > changes were made, and your proposed rewording loses the two places. > > The current text is more explicit than the proposed change. > > Well, this depends on whether you think Section 1.7 should list > textual changes in the document, or clarification/changes to the > protocol. > > IMHO, it should be the latter, but I see that currently it's really > listing the textual changes (even when they clearly don't have any > impact on the protocol); so perhaps listing these separately is > consistent with that... I agree with you that it should be listing actual clarifications and changes, not just textual changes. For implementor it does not really matter what paragraphs were changed, he is interested what changes he need to do for his implementation and for that the text saying that Diffie-Hellman is now mandatory when rekeying IKE SA is much more important than the fact that this changed text in section 1.3.2 and 2.18. I proposed multiple such changes (including the one you pointed out) in my email (http://www.ietf.org/mail-archive/web/ipsec/current/msg05766.html) but Paul didn't want to make those changes (http://www.ietf.org/mail-archive/web/ipsec/current/msg05769.html). As nobody else seemed to care, I didn't continue complaining about the issue. -- kivinen@iki.fi From kivinen@iki.fi Mon Mar 8 07:10:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FB513A69DD for ; Mon, 8 Mar 2010 07:10:25 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jy4WZuuxutH for ; Mon, 8 Mar 2010 07:10:20 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D95BD3A6904 for ; Mon, 8 Mar 2010 07:10:19 -0800 (PST) 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 o28FAMwn006867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 17:10:22 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o28FAMWZ012506; Mon, 8 Mar 2010 17:10:22 +0200 (EET) 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: <19349.4958.130660.415650@fireball.kivinen.iki.fi> Date: Mon, 8 Mar 2010 17:10:22 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: IPsecme WG , Pasi Eronen Subject: [IPsec] Issue #176: What to do with a proposal of NONE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:10:25 -0000 Paul Hoffman writes: > > > Pasi says: > > Section 3.3.6 says "If one of the proposals offered is for the > Diffie-Hellman group of NONE, the responder MUST ignore the > initiator's KE payload and omit the KE payload from the response." > > This seems wrong: it seems to say that if the initiator proposes DH group NONE, the responder must select it. > > However, negotiation of DH groups and KE payload is already well > described in Sections 1.2 and 1.3 (paragraphs mentioning > INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is > completely redundant. Thus, I'd propose just deleting the whole > paragraph. > > Paul says: > > That whole paragraph has been there since -00. Only the last > sentence was added in -03 almost a year ago. It was added to fix > , but I can > easily believe that fix was not correct. However, sections 1.2 and > 1.3 don't address the issue in the sentence quoted. The last sentence is the one that is misleading. All of the rest of the paragraph is just repeation of the text from elsewhere. The last sentence should be saying: If one of the proposals offered is for the Diffie-Hellman group of NONE, and the responder selects that Diffie-Hellman group, then it MUST ignore the initiator's KE payload and omit the KE payload from the response. I.e. the MUST ignore, and omit the KE payload is only applicable if responder actually selects the Diffie-Hellman group NONE. -- kivinen@iki.fi From paul.hoffman@vpnc.org Mon Mar 8 07:17:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FDB3A6A0A; Mon, 8 Mar 2010 07:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.94 X-Spam-Level: X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrBJr9RsvrEA; Mon, 8 Mar 2010 07:17:32 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D2B343A6A06; Mon, 8 Mar 2010 07:17:31 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o28FHXuC089998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 08:17:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com> Date: Mon, 8 Mar 2010 07:17:33 -0800 To: , , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:17:34 -0000 At 8:16 AM +0100 3/8/10, wrote: >Well, this depends on whether you think Section 1.7 should list >textual changes in the document, or clarification/changes to the >protocol. > >IMHO, it should be the latter, but I see that currently it's really >listing the textual changes (even when they clearly don't have any >impact on the protocol); so perhaps listing these separately is >consistent with that... The problem with making this list more conceptual (as both you and Tero have requested) is that doing so may help future implementers but can miss context that is important to a current implementer who needs to change their implementation. In this particular example, we have one change that affects two very different parts of the document, and someone who implemented by reading RFC 4306 (instead of knowing it instinctively like you and Tero) might really need to see exactly which bits *of the spec* are changing to decide which bits of their code is changing. I will try to come up with a way to cover the conceptual change as well, but really am loath to remove the section references in the change description. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Mar 8 07:20:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51BA3A6A03 for ; Mon, 8 Mar 2010 07:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5D8bPO0TvL8 for ; Mon, 8 Mar 2010 07:20:19 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 583633A69AE for ; Mon, 8 Mar 2010 07:20:05 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o28FK7s8090103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 08:20:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19349.4958.130660.415650@fireball.kivinen.iki.fi> References: <19349.4958.130660.415650@fireball.kivinen.iki.fi> Date: Mon, 8 Mar 2010 07:20:06 -0800 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG , Pasi Eronen Subject: Re: [IPsec] Issue #176: What to do with a proposal of NONE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:20:29 -0000 At 5:10 PM +0200 3/8/10, Tero Kivinen wrote: >Paul Hoffman writes: >> >> >> Pasi says: >> >> Section 3.3.6 says "If one of the proposals offered is for the >> Diffie-Hellman group of NONE, the responder MUST ignore the >> initiator's KE payload and omit the KE payload from the response." >> >> This seems wrong: it seems to say that if the initiator proposes DH group NONE, the responder must select it. >> >> However, negotiation of DH groups and KE payload is already well >> described in Sections 1.2 and 1.3 (paragraphs mentioning >> INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is >> completely redundant. Thus, I'd propose just deleting the whole >> paragraph. >> >> Paul says: >> >> That whole paragraph has been there since -00. Only the last >> sentence was added in -03 almost a year ago. It was added to fix >> , but I can >> easily believe that fix was not correct. However, sections 1.2 and >> 1.3 don't address the issue in the sentence quoted. > >The last sentence is the one that is misleading. All of the rest of >the paragraph is just repeation of the text from elsewhere. > >The last sentence should be saying: > > If one of the proposals offered is for the > Diffie-Hellman group of NONE, and the responder selects that > Diffie-Hellman group, then it MUST ignore the initiator's KE > payload and omit the KE payload from the response. > >I.e. the MUST ignore, and omit the KE payload is only applicable if >responder actually selects the Diffie-Hellman group NONE. That makes good sense to me, and seems like less of a change to 4306 than the current wording. Do others agree? --Paul Hoffman, Director --VPN Consortium From kivinen@iki.fi Mon Mar 8 07:43:14 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689DB3A6A24; Mon, 8 Mar 2010 07:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toUTtJZWCRLN; Mon, 8 Mar 2010 07:43:13 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF743A6A1F; Mon, 8 Mar 2010 07:43:12 -0800 (PST) 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 o28FhCNI000387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 17:43:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o28FhBfB015673; Mon, 8 Mar 2010 17:43:11 +0200 (EET) 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: <19349.6926.978794.772035@fireball.kivinen.iki.fi> Date: Mon, 8 Mar 2010 17:43:10 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7758482FF391@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, ietf@ietf.org Subject: Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:43:14 -0000 Paul Hoffman writes: > At 8:16 AM +0100 3/8/10, wrote: > >Well, this depends on whether you think Section 1.7 should list > >textual changes in the document, or clarification/changes to the > >protocol. > > > >IMHO, it should be the latter, but I see that currently it's really > >listing the textual changes (even when they clearly don't have any > >impact on the protocol); so perhaps listing these separately is > >consistent with that... > > The problem with making this list more conceptual (as both you and > Tero have requested) is that doing so may help future implementers > but can miss context that is important to a current implementer who > needs to change their implementation. As an implementor I disagree with you on that. > In this particular example, we have one change that affects two very > different parts of the document, and someone who implemented by > reading RFC 4306 (instead of knowing it instinctively like you and > Tero) might really need to see exactly which bits *of the spec* are > changing to decide which bits of their code is changing. Yes that change changes two locations of the text, but only one location in the implementation. Thus for someone who is doing this change for their implementation it would be important to understand that this change is actually just one code change, not two. Also the change is most likely going to be in the policy enforing part than in the actual exchange handling code (1.3.2) or the SKEYSEED calculation part. The implementation simply needs to enforce the IKE SA rekey policy so that Diffie-Hellman is not optional and that is only change they need to do in the code. They already have to calculate the SKEYSEED (most likely with or without the g^ir (new)), and they already have the code to parse KEi and KEr (generic code). > I will try to come up with a way to cover the conceptual change as > well, but really am loath to remove the section references in the > change description. -- kivinen@iki.fi From welterk@us.ibm.com Mon Mar 8 08:17:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2783A6A2B for ; Mon, 8 Mar 2010 08:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD2mSXYqnKYt for ; Mon, 8 Mar 2010 08:17:41 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 7290A3A69FE for ; Mon, 8 Mar 2010 08:17:40 -0800 (PST) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e8.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o28G9YgP004085 for ; Mon, 8 Mar 2010 11:09:34 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o28GHZcu113776 for ; Mon, 8 Mar 2010 11:17:35 -0500 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o289HWKR006517 for ; Mon, 8 Mar 2010 02:17:32 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o289HVwE006492 for ; Mon, 8 Mar 2010 02:17:31 -0700 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: E95BCCD7:8E4A6F0F-882576E0:00590B57; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 03/08/2010 08:17:29 AM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 03/08/2010 08:17:29 AM, Serialize complete at 03/08/2010 08:17:29 AM, S/MIME Sign failed at 03/08/2010 08:17:29 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/08/2010 09:17:31, Serialize complete at 03/08/2010 09:17:31 Message-ID: Date: Mon, 8 Mar 2010 08:17:30 -0800 Content-Type: multipart/alternative; boundary="=_alternative 00597E12882576E0_=" Subject: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:17:52 -0000 This is a multipart message in MIME format. --=_alternative 00597E12882576E0_= Content-Type: text/plain; charset="US-ASCII" Section 2.23, paragraph starting: "An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE.". What does, "even at the beginning of IKE" mean? Does it mean, "even when sending an IKE_SA_INIT request" or "even at any point during the initial exchanges"? Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 00597E12882576E0_= Content-Type: text/html; charset="US-ASCII"
Section 2.23, paragraph starting:
"An initiator can use port 4500 for both IKE and ESP, regardless of
 whether or not there is a NAT, even at the beginning of IKE.".

What does, "even at the beginning of IKE" mean?

Does it mean,
  "even when sending an IKE_SA_INIT request"
or
  "even at any point during the initial exchanges"?

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 00597E12882576E0_=-- From mcgrew@cisco.com Mon Mar 8 08:33:26 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F2D3A6A85 for ; Mon, 8 Mar 2010 08:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.75 X-Spam-Level: X-Spam-Status: No, score=-8.75 tagged_above=-999 required=5 tests=[AWL=1.849, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30huqBWTKXew for ; Mon, 8 Mar 2010 08:33:23 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BEB823A69C0 for ; Mon, 8 Mar 2010 08:33:20 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABK1lEurRN+K/2dsb2JhbACbKHOhcJgVhHgEgxc X-IronPort-AV: E=Sophos;i="4.49,603,1262563200"; d="scan'208";a="215953318" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2010 16:33:25 +0000 Received: from stealth-10-32-254-212.cisco.com (stealth-10-32-254-212.cisco.com [10.32.254.212]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o28GXN0r007073; Mon, 8 Mar 2010 16:33:24 GMT Message-Id: <5E118307-CA36-4182-B5B0-A6431487899F@cisco.com> From: David McGrew To: Paul Hoffman , sean.s.shen@gmail.com, yumao9@gmail.com, ssmurthy.nittala@freescale.com In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 08:33:23 -0800 References: X-Mailer: Apple Mail (2.936) Cc: IPsecme WG Subject: [IPsec] comments on draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:33:26 -0000 The statement that "Although the [RFC4307] specifies that the AES-CTR encryption algorithm feature SHOULD be supported by IKEv2, no existing document specifies how IKEv2 can support the feature" is not completely correct. RFC 5282 specifies how to use AES in the Galois Counter Mode (GCM) and Counter and CBC-MAC (CCM) modes of operation. Neither this draft nor RFC 4307 provides any rationale for why or when AES-CTR should be used. If it is considered useful because CTR can be pipelined or implemented in parallel, then the considerations of http://tools.ietf.org/html/draft-mcgrew-esp-ah-algo-update-00#section-3 would apply. What value is there is promoting the use of AES-CTR when better technical alternatives exist and are on standards track? If the sole motivation for this standard is to correct the inconsistency between RFC 4307 and RFC 3686, then the draft should include a statement to that effect, and mention the IKEv2 transforms that have all of the advantages of AES-CTR already exist. The draft is not very clear on how AES-CTR is supposed to be implemented. What is the counter format and what is the increment function? If the intent is to copy RFC 3686 then this needs to be made more explicit. David On Mar 3, 2010, at 9:51 AM, Paul Hoffman wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IP Security Maintenance and >> Extensions Working Group of the IETF. >> >> Title : Using Advanced Encryption Standard (AES) Counter Mode >> with IKEv2 >> Author(s) : S. Shen, Y. Mao, S. murthy >> Filename : draft-ietf-ipsecme-aes-ctr-ikev2-05.txt >> Pages : 10 >> Date : 2010-3-2 >> >> This document describes the usage of Advanced Encryption Standard >> Counter Mode (AES-CTR), with an explicit initialization vector, by >> IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT >> exchange. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05.txt > > Based on Pasi's AD review, the authors significantly shortened the > document. It seems prudent to have the WG review the new, shorter > version. In particular, it would be good for developers to look at > the new short document and see if it is complete enough to implement > from. > > This review cycle will end in a week, but please do the review early > in case problems are found. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From wierbows@us.ibm.com Mon Mar 8 09:55:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306913A6A57; Mon, 8 Mar 2010 09:55:33 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ErLxu5H638y; Mon, 8 Mar 2010 09:55:32 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 39FCB3A6ABF; Mon, 8 Mar 2010 09:55:32 -0800 (PST) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o28HlWXw021105; Mon, 8 Mar 2010 12:47:32 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o28HtXWW2056378; Mon, 8 Mar 2010 12:55:33 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o28HtX0H000970; Mon, 8 Mar 2010 12:55:33 -0500 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o28HtXXl000963; Mon, 8 Mar 2010 12:55:33 -0500 In-Reply-To: References: <19349.4958.130660.415650@fireball.kivinen.iki.fi> X-KeepSent: 1C9B8C8E:54DA023C-002576E0:00623226; type=4; name=$KeepSent To: Paul Hoffman X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Mon, 8 Mar 2010 12:55:32 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 03/08/2010 12:55:32 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Issue #176: What to do with a proposal of NONE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 17:55:33 -0000 I agree. From: Paul Hoffman To: Tero Kivinen Cc: IPsecme WG , Pasi Eronen Date: 03/08/2010 10:22 AM Subject: Re: [IPsec] Issue #176: What to do with a proposal of NONE Sent by: ipsec-bounces@ietf.org At 5:10 PM +0200 3/8/10, Tero Kivinen wrote: >Paul Hoffman writes: >> >> >> Pasi says: >> >> Section 3.3.6 says "If one of the proposals offered is for the >> Diffie-Hellman group of NONE, the responder MUST ignore the >> initiator's KE payload and omit the KE payload from the response." >> >> This seems wrong: it seems to say that if the initiator proposes DH group NONE, the responder must select it. >> >> However, negotiation of DH groups and KE payload is already well >> described in Sections 1.2 and 1.3 (paragraphs mentioning >> INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is >> completely redundant. Thus, I'd propose just deleting the whole >> paragraph. >> >> Paul says: >> >> That whole paragraph has been there since -00. Only the last >> sentence was added in -03 almost a year ago. It was added to fix >> , but I can >> easily believe that fix was not correct. However, sections 1.2 and >> 1.3 don't address the issue in the sentence quoted. > >The last sentence is the one that is misleading. All of the rest of >the paragraph is just repeation of the text from elsewhere. > >The last sentence should be saying: > > If one of the proposals offered is for the > Diffie-Hellman group of NONE, and the responder selects that > Diffie-Hellman group, then it MUST ignore the initiator's KE > payload and omit the KE payload from the response. > >I.e. the MUST ignore, and omit the KE payload is only applicable if >responder actually selects the Diffie-Hellman group NONE. That makes good sense to me, and seems like less of a change to 4306 than the current wording. Do others agree? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From sheila.frankel@nist.gov Mon Mar 8 10:10:01 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5F33A6A34 for ; Mon, 8 Mar 2010 10:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yZmgz3X0Sal for ; Mon, 8 Mar 2010 10:09:59 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 19F723A69E1 for ; Mon, 8 Mar 2010 10:09:58 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o28I9lam003456; Mon, 8 Mar 2010 13:09:47 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Mon, 8 Mar 2010 13:09:47 -0500 From: "Frankel, Sheila E." To: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" Date: Mon, 8 Mar 2010 13:05:14 -0500 Thread-Topic: Response to Pasi's AD comments on the roadmap draft Thread-Index: AQHKvuqB0s+eXspKVkaiyQLdLNk5WQ== Message-ID: 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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: Paul Hoffman Subject: [IPsec] Response to Pasi's AD comments on the roadmap draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 18:10:01 -0000 Here are our responses to Pasi's AD comments on the roadmap doc. We have in= dicated which changes we plan to make, and which ones we would prefer to ha= ndle somewhat differently. We would appreciate hearing from the list, both those who agree and those w= ho don't. We will send a separate email listing those RFCs that Pasi wants = us to delete from the roadmap and those he would like us to add. Sheila and Suresh > - I'm not very happy about the use of MUST, SHOULD, etc. in this > document. This is supposed to be a purely informational guide to other > documents, not something that sets requirements (of any level) for > anyone. The only places these words are used is in re-phrasing requirements specifi= ed=20 in RFCs. So it doesn't set any requirements, just re-states them. > =20 > For cryptographic algorithms, we already have separate documents that > specify the requirement levels. IMHO repeating them here just means > the two places will soon be inconsistent (which is not helpful for the > audience here). If the WG has considered this and decided the > repeating them here is useful, I would strongly suggest just having > the tables in Appendix B (with explicit note that they're probably out > of date by the time the reader finds them), and removing them from > Section 5.x. There is a lot of confusion in the vendor and user community about this iss= ue,=20 and that is why we felt it would help to have a central repository with thi= s=20 information. Obviously, any docs that come after the roadmap could change t= hings,=20 but even knowing that this is a snapshot as of a specific date is helpful -= then=20 you just have to examine docs that come after this to see what has changed. We feel that it is useful to state the requirements together with the relev= ant=20 RFCs, along with explanations (e.g. no RFC, no IANA #) for those that are u= ndefined.=20 In addition, if new RFCs and/or IANA #'s come along, it will be clear what = is=20 responsible for a potential change in that algorithm's applicability. We th= ink that=20 the summary table is a useful reference tool, but it's hard to read without= being=20 able to check back to the relevant RFC requirements. It does make sense to state, in the 2 places that we describe these require= ment=20 levels, that this is a snapshot as of March 2010 (or a later publication da= te) and=20 is subject to change in future. > =20 > For things other than cryptographic algorithms, I'm not sure if > talking about "requirements levels" even makes that much > sense. Consider, for example, Section 4.2.4.2 (IKEv2 redirect): > =20 > Requirements levels for RFC5685: > IKEv1 - N/A > IKEv2 - optional > =20 > This is not really specifying any requirement level; a phrasing > like "This extension applies only to IKEv2, not IKEv1" would IMHO > be more accurate. Text in most other sections (than crypto algs) > could be rephrased similarly. > =20 Originally, we just had req levels for algs - someone in the WG requested t= hat=20 we extend it to include all of the basic IKE and IPsec docs, the WG chairs = concurred,=20 and we added them. We would like to see the req levels remain for the algs,= but we=20 don't feel equally strongly about the other docs. Adding text to the RFC de= scriptions=20 would be fine. Do you have any objection to the summary table for these doc= s? > - Appendix B: I'm trying to match table B against RFC 4307/4835 and > I can't quite get them to match. For example, RFC 4307 lists > AUTH_AES_XCBC_96 as "SHOULD+", while the column "IKEv2" here says > "optional". This suggests that perhaps even including this table > isn't such a good idea... > =20 RFC 4307 is a very problematic RFC. There are 2 lists of required algorithm= s for=20 IKEv2. Section 3.1.1 (Encrypted Payload Algorithms) has 1 list, which speci= fies=20 the MUST and SHOULD algs for encryption and integrity, but does not mention= =20 AES-XCBC. Then there are different lists in section 3.1.3 (encryption) and= =20 3.1.5 (integrity). I (Sheila) had originally assumed that section 3.1.1 per= tained=20 to IKEv2 payloads and the other sections pertained to algorithms that IKEv2= =20 negotiated for IPsec. The WG chairs and others disagreed, feeling that this= RFC=20 was hastily written and contradictory. We took section 3.1.1 to be definiti= ve.=20 I guess we should explain this in the roadmap. But it's problems like this = that=20 led us to include the requirements levels in the roadmap. > - Section 5.4: "Since combined mode algorithms are not a feature > of IPsec-v2, these IKEv1 implementations are used in conjunction with > IPsec-v3." I'm not sure if this is really a good way to describe > the situation; after all, GCM-for-ESP (RFC 4106) predates IPsec-v3... > =20 > I'd suggest something like "Although IPsec-v2 ESP [RFC2406] did not > originally include combined mode algorithms, some IKEv1 > implementations have added the capability to negotiate combined mode > algorithms for use in IPsec SAs; these implementations do not include > the capability to use combined mode algorithms to protect IKE SAs." > =20 > Analogous changes are needed in 5.4.1, 5.4.2, 5.4.3, and 5.6.2. > =20 OK > - Section 5.4.1: "[RFC4309] includes IANA values for use in ESP-v3"; > ESP doesn't have any IANA registries; IKEv1 and IKEv2 do. RFC 4309 > is included in both. > =20 Suggested new wording: "[RFC4309] includes IANA values that IKE can use to= =20 negotiate ESP-v3 SAs." > - Quite many IETF protocols use (or can use) IPsec to protect their > traffic, so we have *lot* of RFCs that specify how to configure IPsec > for use X (ranging from RADIUS and Diameter to iSCSI and TGREP).=20 > I don't think these belong in the IPsec document roadmap, unless they > modify/extend how IPsec works (e.g. define new payloads/something > for IKEv1/v2, or change the IPsec processing somehow). > =20 > With this in mind, I'd suggest deleting 8.1.1, 8.1.2, and 8.2; > rephrasing 8.1.3 and 8.1.4 to explain their impact on IPsec; > deleting 8.1.5/8.1.6/8.1.7 and adding RFC 5026 (text below). > =20 > Proposed new text for 8.1.3: > =20 > This document specifies the use of IPsec in securing Mobile IPv6 > traffic between mobile nodes and home agents. Mobile IPv6 requires > considering the Home Address destination option and Routing Header > in IPsec processing. Also, IPsec and IKE security association > addresses can be updated by Mobile IPv6 signaling messages. > =20 > Proposed new text for 8.1.4: > =20 > This document updates [RFC3776] in order to work with the revised > IPsec architecture [RFC4301]. Since the revised IPsec architecture > expands the list of selectors to include the Mobility Header message > type, it becomes much easier to differentiate between different > mobility header messages. This document also specifies the use > of IKEv2 configuration payloads for dynamic home address configuratio= n. > =20 > Proposed text for RFC 5026: > =20 > This document extends [RFC4877] to support dynamic discovery of > home agents and the home network prefix; for the latter purpose, it > specifies a new IKEv2 configuration attribute and notification. > =20 New text and adding RFC 5026: OK Deleting other Mobile IP and OSPF RFCs: We feel there's value in summarizin= g=20 RFCs that use IPsec, even though they don't make any modifications. For exa= mple,=20 in extending and/or re-defining features of IPsec, it can be useful to see= =20 dependencies and feature use in other protocols. We would prefer to add a=20 statement that these RFCs use IKE/IPsec without any modifications or extens= ions. > - Section 5.x: IMHO lines like "ESP-v2 - undefined (no IANA #)" > are a bit confusing, because ESP does not have any IANA registries; > the registries are specific to a key management protocol (IKEv1, > IKEv2, Photuris, KINK, HIP, ...). > =20 Suggested new wording: "The IANA registries for IKEv1 and IKEv2 include IAN= A=20 values for various cryptographic algorithms. IKE uses these values to negot= iate=20 IPsec SAs that will provide protection using those algorithms. If a specifi= c=20 algorithm lacks a value for IKEv1 and/or IKEv2, that algorithm's use is cla= ssified=20 as "undefined (no IANA #) within IPsec-v2 and/or IPsec-v3." > - Section 5.7.4: "It also includes 3 EC DH groups (groups 19-21) that > were previously defined in [RFC4753]". The normative specification > for groups 19-21 in IKE is still 4753/5753bis, so I would propose > just omitting this sentence. > =20 OK - but won't people be confused if they look at RFC 5114 and see that the= re=20 are additional groups defined there? > - I would suggest moving 3.2/3.3 somewhere later in the document -- as > the document already says, this is not really deployed stuff, and > might fit better in e.g. Section 7. > =20 OK - Policy and MIBs will be moved to Section 7 (Outgrowths of IPsec/IKE). > - IMHO MOBIKE would belong together with other IKEv2 remote > access extensions in Section 4.2.4? > =20 OK - MOBIKE will be moved to 4.2.4 (Remote Access) under the Section "IKE=20 Additions and Extensions" > - Should RFC 2521 be mentioned? (it's largely obsolete, I guess, but > for completeness..) > =20 No strong opinion. > - What about RFC 2709? (it's definitely obsolete, but things like > this influenced the design of the current IPsec NAT-T, like > using a different port number to avoid any 2709-like stuff :-) > =20 No strong opinion. > - Should we include RFC 3329? It does (partly) specify the > "3gpp-ipsec" mechanism for setting up IPsec SAs (basically, a simple > key management protocol instead of IKE), and this is something that is > actually implemented (however, some of the details needed to implement > this are not actually in 3329, but only in 3GPP specs...) > =20 OK > - Section 8.5.1: this has an IKE extension (to pretty core > part of IKE), so might belong in Section 4.2 instead. > =20 RFC 3554, On the Use of SCTP with IPsec: Since it's a product of another WG= for=20 another protocol, we would prefer to leave it where it is. > - RFC 4322 probably should be mentioned somewhere (near BTNS and/or > IPSECKEY). > =20 RFC 4322, Opportunistic Encryption using the Internet Key Exchange (IKE) - = OK,=20 that's one we totally missed. > - Section 8.8.1: suggest adding something like "It also defines how > public key fingerprints (hashes) are distributed via BGP, and used > later to authenticate IKEv2 exchange between the tunnel endpoints." > =20 OK > - Section 6: MIKEY (as specified in IETF RFCs) creates security > associations for SRTP, not IPsec -- so it's not really relevant for > this document (some other SDOs have extended MIKEY to create IPsec > SAs, but that's an area we IMHO don't need to cover in this roadmap). > So Sections 6.(7,8,9,10,12,13) should be dropped. > =20 OK with us - we'll submit the list of RFCs to be deleted/added to the WG, i= n case=20 anyone else has strong opinions on this metter. > - Section 6.1: RFC 3740 barely mentions IPsec, so the description > should probably point out that 3740 isn't really about IPsec. > =20 OK > - I'm not sure what 4534/4535 have to do with IPsec; it doesn't > look like it supports creating IPsec SAs, for example. > =20 Do you think these should be removed? If so, we'll run it past the WG > - Sections 6.(14,15,16) are not about IPsec, but non-IPsec > approaches to securing multicast; so they don't really belong here. > =20 Do you think these should be removed? If so, we'll run it past the WG > - Section 8.6 and 8.4.1 are not about IPsec, but adapting IKEv2 to > non-IPsec uses. Perhaps these (and RFC 4705, which is missing from the > list) should be grouped under "Non-IPsec Protocols Related to IKE" or > something? (and Section 8.4.1 doesn't really belong under title "EMU"; > it did not come from the EMU WG). > =20 Section 8 is titled: "Other Protocols that use IPsec/IKE". We would prefer = to=20 change/expand this title, rather than adding another new major section. Other proposed changes:=20 Add a new sub-section, "Wireless" or "Wireless Security" to include RFC 47= 05.=20 Change the heading of the section that includes RFC 5106 (EAP-IKEv2) from= =20 "Extensible Authentication Protocol (EAP) Method Update (EMU)" to=20 "Extensible Authentication Protocol (EAP)" > - Section 7.4: would it be useful to mention that some vendors > have proprietary extensions for Kerberos in IKEv1 (not KINK)? > (since these are really deployed and used, unlike KINK...) > =20 OK > - Section 7.1: I would suggest not having separate sections for all > IPComp compression algorithms. Perhaps a one-sentence summary like: > "Compression algorithms for IPcomp include DEFLATE [RFC 2394], LZS > [RFC2395], and LZJH [RFC 3051]." would be sufficient? > =20 OK > - Section 1: "The usage of terms in this document conforms to > definitions in [RFC4949]." No, it does not; just remove this sentence. > Here's what Sam wrote back then for his ABSTAIN ballot for 4949: > =20 > "However there is a lot left in the glossary that is the author's > personal opinion. We found a number of instances where the author > was trying to use this glossary to establish normative meanings for > words based on his belief of how those words should be > used--sometimes in direct conflict with common practice." > =20 > (For example, 4949 considers terms like "MAC (message authentication > code)" and "initialization vector" to be wrong; the "correct" terms > would be "keyed hash"/"protected checksum" and "initialization > value"). > =20 OK > - Section 4.2.4.3: now RFC 5739. > =20 OK > - Section 1 and 5: "MUST, SHALL or MAY" should probably be > "MUST, SHOULD or MAY"? > =20 OK > - I'd suggest swapping the order of 7.2.1 and 7.2.2. > =20 OK > - Section 7.6 and 7.6.1: I'd suggest combining this to a single > section. No strong opinion on this - but this would be the only RFC that doesn't hav= e its=20 own section #, separate from its introductory section. From sheila.frankel@nist.gov Mon Mar 8 10:14:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F983A6A72 for ; Mon, 8 Mar 2010 10:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coRAx+N5NmOs for ; Mon, 8 Mar 2010 10:14:46 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id F12733A6AC9 for ; Mon, 8 Mar 2010 10:14:39 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o28IEWK0012927; Mon, 8 Mar 2010 13:14:32 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Mon, 8 Mar 2010 13:14:31 -0500 From: "Frankel, Sheila E." To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Mon, 8 Mar 2010 13:13:14 -0500 Thread-Topic: Pasi's AD comments on roadmap doc - RFCs to add/delete Thread-Index: AQHKvusE+jx8Z70hfUiXz6G+jjaU5g== Message-ID: 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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: Paul Hoffman Subject: [IPsec] Pasi's AD comments on roadmap doc - RFCs to add/delete X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 18:14:58 -0000 Here are the RFCs that Pasi suggested adding/removing from the roadmap doc.= If anyone has any strong opinions either pro or con, now's the time to spe= ak up. Sheila and Suresh ---------------------------------------------------------------------------= - several groups of RFCs that Pasi wants us to remove: 1) RFCs that define how to configure IPsec for use in other protocols, but = don't=20 modify/extend how IPsec works (We would prefer to keep these in the road= map): 8.1.1. RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual Priv= ate=20 Network (VPN) Gateways 8.1.2. RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways 8.1.5. RFC 5213, Proxy Mobile IPv6 8.1.6. RFC 5268, Mobile IPv6 Fast Handovers 8.1.7. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management 8.2.1. RFC 4552, Authentication/Confidentiality for OSPFv3 2) MIKEY: creates security associations for SRTP, not IPsec -- so it's not = really=20 relevant for this document 6.7. RFC 3830, MIKEY: Multimedia Internet KEYing 6.8. RFC 4738, MIKEY-RSA-R: An Additional Mode of Key Distribution in=20 Multimedia Internet KEYing (MIKEY) 6.9. RFC 5197, On the Applicability of Various Multimedia Internet KEYing= =20 (MIKEY) Modes and Extensions 6.10. RFC 4563, The Key ID Information Type for the General Extension Pay= load=20 in Multimedia Internet KEYing (MIKEY) 6.12. RFC 4650, HMAC-Authenticated Diffie-Hellman for Multimedia Internet= =20 KEYing (MIKEY) 6.13. RFC 5410, Multimedia Internet KEYing (MIKEY) General Extension Payl= oad=20 for Open Mobile Alliance BCAST 1.0 3) I'm not sure what 4534/4535 have to do with IPsec; it doesn't look like = it supports=20 creating IPsec SAs, for example. 6.5. RFC 4535, GSAKMP: Group Secure Association Key Management Protocol 6.6. RFC 4534, Group Security Policy Token v1 4) not about IPsec, but non-IPsec approaches to securing multicast; so they= don't=20 really belong here. 6.14. RFC 4082, Timed Efficient Stream Loss-Tolerant Authentication (TESL= A):=20 Multicast Source Authentication Transform Introduction 6.15. RFC 4442, Bootstrapping Timed Efficient Stream Loss-Tolerant=20 Authentication (TESLA) 6.16. RFC 4383, The Use of Timed Efficient Stream Loss-Tolerant Authentic= ation=20 (TESLA) in the Secure Real-time Transport Protocol ---------------------------------------------------------------------------= - RFCs that Pasi suggests adding: RFC 2521, ICMP Security Failures Messages (E, Mar 1999) RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains (I, Oct 19= 99) RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol= =20 (SIP) (S, Jan 2003) RFC 4322, Opportunistic Encryption using the Internet Key Exchange (IKE) (I, Dec 2005) RFC 4705, GigaBeam High-Speed Radio Link Encryption (I, Oct 2006) RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario (S, Oct 2007) From paul.hoffman@vpnc.org Mon Mar 8 10:31:24 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D1F3A6AA7 for ; Mon, 8 Mar 2010 10:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.961 X-Spam-Level: X-Spam-Status: No, score=-5.961 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKwNvDI0hwuk for ; Mon, 8 Mar 2010 10:31:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5C0263A6AC2 for ; Mon, 8 Mar 2010 10:31:20 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o28IVIl0003070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 11:31:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5E118307-CA36-4182-B5B0-A6431487899F@cisco.com> References: <5E118307-CA36-4182-B5B0-A6431487899F@cisco.com> Date: Mon, 8 Mar 2010 10:31:16 -0800 To: David McGrew , sean.s.shen@gmail.com, yumao9@gmail.com, ssmurthy.nittala@freescale.com From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] comments on draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 18:31:24 -0000 At 8:33 AM -0800 3/8/10, David McGrew wrote: >The statement that "Although the [RFC4307] specifies that the AES-CTR encryption algorithm feature SHOULD be supported by IKEv2, no existing document specifies how IKEv2 can support the feature" is not completely correct. RFC 5282 specifies how to use AES in the Galois Counter Mode (GCM) and Counter and CBC-MAC (CCM) modes of operation. David, that sounds like you are saying that GCM and CCM modes are the same at the CTR mode, which we all know is not true. The statement in the current draft is true, and I would not want to muddy it by saying ", but other RFCs specify how IKEv2 can support other modes". >Neither this draft nor RFC 4307 provides any rationale for why or when AES-CTR should be used. If it is considered useful because CTR can be pipelined or implemented in parallel, then the considerations of http://tools.ietf.org/html/draft-mcgrew-esp-ah-algo-update-00#section-3 would apply. What value is there is promoting the use of AES-CTR when better technical alternatives exist and are on standards track? Because implementers might do it anyway, regardless of whether there might be better alternatives. We have already heard that some have. >If the sole motivation for this standard is to correct the inconsistency between RFC 4307 and RFC 3686, then the draft should include a statement to that effect, Agree, but... > and mention the IKEv2 transforms that have all of the advantages of AES-CTR already exist. Disagree. GCM and CCM have the disadvantage of being more complex than CTR, and that complexity brings more safety. Instead, this draft can point to RFC 5282 as another way to do *similar* things. >The draft is not very clear on how AES-CTR is supposed to be implemented. What is the counter format and what is the increment function? If the intent is to copy RFC 3686 then this needs to be made more explicit. A sentence on each of those would be good additions to section 2. --Paul Hoffman, Director --VPN Consortium From dharkins@lounge.org Mon Mar 8 11:17:32 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E37D3A6B68 for ; Mon, 8 Mar 2010 11:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.18 X-Spam-Level: X-Spam-Status: No, score=-6.18 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqer8gprEIwG for ; Mon, 8 Mar 2010 11:17:31 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 0EB3B3A6B75 for ; Mon, 8 Mar 2010 11:17:14 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6D740200B2; Mon, 8 Mar 2010 11:17:00 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 8 Mar 2010 11:17:00 -0800 (PST) Message-ID: <252364a0022a7cb64107ecdd2f64134f.squirrel@www.trepanning.net> In-Reply-To: <5E118307-CA36-4182-B5B0-A6431487899F@cisco.com> References: <5E118307-CA36-4182-B5B0-A6431487899F@cisco.com> Date: Mon, 8 Mar 2010 11:17:00 -0800 (PST) From: "Dan Harkins" To: "David McGrew" 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: sean.s.shen@gmail.com, IPsecme WG , ssmurthy.nittala@freescale.com, Paul Hoffman , yumao9@gmail.com Subject: Re: [IPsec] comments on draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 19:17:32 -0000 Hi, Let me take this opportunity to point out that RFC 5297 describes an AES-CTR variant that does not have the performance benefits that GCM has but provides nonce misuse/abuse resistance. It is a much more robust alternative than CCM because security is not voided if the nonce/counter happens to get reused. The robustness properties would work well for SA failover because you don't need to worry about the counter being reused. If you're not already using CCM there's really no reason to start. It's slow and fragile and alternatives exist to address both of those shortcomings, GCM and SIV respectively. regards, Dan. On Mon, March 8, 2010 8:33 am, David McGrew wrote: > > The statement that "Although the [RFC4307] specifies that the AES-CTR > encryption algorithm feature SHOULD be supported by IKEv2, no existing > document specifies how IKEv2 can support the feature" is not > completely correct. RFC 5282 specifies how to use AES in the Galois > Counter Mode (GCM) and Counter and CBC-MAC (CCM) modes of operation. > > Neither this draft nor RFC 4307 provides any rationale for why or when > AES-CTR should be used. If it is considered useful because CTR can > be pipelined or implemented in parallel, then the considerations of > http://tools.ietf.org/html/draft-mcgrew-esp-ah-algo-update-00#section-3 > would apply. What value is there is promoting the use of AES-CTR > when better technical alternatives exist and are on standards track? > If the sole motivation for this standard is to correct the > inconsistency between RFC 4307 and RFC 3686, then the draft should > include a statement to that effect, and mention the IKEv2 transforms > that have all of the advantages of AES-CTR already exist. > > The draft is not very clear on how AES-CTR is supposed to be > implemented. What is the counter format and what is the increment > function? If the intent is to copy RFC 3686 then this needs to be > made more explicit. > > David > > On Mar 3, 2010, at 9:51 AM, Paul Hoffman wrote: > >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the IP Security Maintenance and >>> Extensions Working Group of the IETF. >>> >>> Title : Using Advanced Encryption Standard (AES) Counter Mode >>> with IKEv2 >>> Author(s) : S. Shen, Y. Mao, S. murthy >>> Filename : draft-ietf-ipsecme-aes-ctr-ikev2-05.txt >>> Pages : 10 >>> Date : 2010-3-2 >>> >>> This document describes the usage of Advanced Encryption Standard >>> Counter Mode (AES-CTR), with an explicit initialization vector, by >>> IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT >>> exchange. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05.txt >> >> Based on Pasi's AD review, the authors significantly shortened the >> document. It seems prudent to have the WG review the new, shorter >> version. In particular, it would be good for developers to look at >> the new short document and see if it is complete enough to implement >> from. >> >> This review cycle will end in a week, but please do the review early >> in case problems are found. >> >> --Paul Hoffman, Director >> --VPN Consortium >> _______________________________________________ >> 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 paul.hoffman@vpnc.org Mon Mar 8 11:47:32 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3F23A69EA for ; Mon, 8 Mar 2010 11:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.966 X-Spam-Level: X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuO08objngbX for ; Mon, 8 Mar 2010 11:47:31 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id ABBE33A6B9D for ; Mon, 8 Mar 2010 11:47:31 -0800 (PST) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o28JlYQe007172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 12:47:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <252364a0022a7cb64107ecdd2f64134f.squirrel@www.trepanning.net> References: <5E118307-CA36-4182-B5B0-A6431487899F@cisco.com> <252364a0022a7cb64107ecdd2f64134f.squirrel@www.trepanning.net> Date: Mon, 8 Mar 2010 11:47:32 -0800 To: "Dan Harkins" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] comments on draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 19:47:32 -0000 At 11:17 AM -0800 3/8/10, Dan Harkins wrote: > Let me take this opportunity to point out that RFC 5297 describes >an AES-CTR variant that does not have the performance benefits that >GCM has but provides nonce misuse/abuse resistance. It feels like your comment is unrelated to this thread, unless you are proposing that draft-ietf-ipsecme-aes-ctr-ikev2 needs to reference every single variant, even those that are not on standards track. If that is what you are saying, please propose wording for the WG to look at. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Mon Mar 8 12:54:37 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271973A69BA; Mon, 8 Mar 2010 12:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WD+XiFH43Wi; Mon, 8 Mar 2010 12:54:36 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id CD50B3A69A2; Mon, 8 Mar 2010 12:54:35 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o28Ksbsd013325; Mon, 8 Mar 2010 22:54:37 +0200 (IST) X-CheckPoint: {4B956291-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 8 Mar 2010 22:54:57 +0200 From: Yoav Nir To: David Wierbowski , Paul Hoffman Date: Mon, 8 Mar 2010 22:54:52 +0200 Thread-Topic: [IPsec] Issue #176: What to do with a proposal of NONE Thread-Index: Acq+6J7HR+WKcjbMS7OLALbjUnXW5wAGPq10 Message-ID: <006FEB08D9C6444AB014105C9AEB133FB3764FBA18@il-ex01.ad.checkpoint.com> References: <19349.4958.130660.415650@fireball.kivinen.iki.fi> , In-Reply-To: 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 , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Issue #176: What to do with a proposal of NONE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 20:54:37 -0000 Me too. ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of David Wi= erbowski [wierbows@us.ibm.com] Sent: Monday, March 08, 2010 19:55 To: Paul Hoffman Cc: IPsecme WG; ipsec-bounces@ietf.org Subject: Re: [IPsec] Issue #176: What to do with a proposal of NONE I agree. From: Paul Hoffman To: Tero Kivinen Cc: IPsecme WG , Pasi Eronen Date: 03/08/2010 10:22 AM Subject: Re: [IPsec] Issue #176: What to do with a proposal of NONE Sent by: ipsec-bounces@ietf.org At 5:10 PM +0200 3/8/10, Tero Kivinen wrote: >Paul Hoffman writes: >> >> >> Pasi says: >> >> Section 3.3.6 says "If one of the proposals offered is for the >> Diffie-Hellman group of NONE, the responder MUST ignore the >> initiator's KE payload and omit the KE payload from the response." >> >> This seems wrong: it seems to say that if the initiator proposes DH group NONE, the responder must select it. >> >> However, negotiation of DH groups and KE payload is already well >> described in Sections 1.2 and 1.3 (paragraphs mentioning >> INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is >> completely redundant. Thus, I'd propose just deleting the whole >> paragraph. >> >> Paul says: >> >> That whole paragraph has been there since -00. Only the last >> sentence was added in -03 almost a year ago. It was added to fix >> , but I can >> easily believe that fix was not correct. However, sections 1.2 and >> 1.3 don't address the issue in the sentence quoted. > >The last sentence is the one that is misleading. All of the rest of >the paragraph is just repeation of the text from elsewhere. > >The last sentence should be saying: > > If one of the proposals offered is for the > Diffie-Hellman group of NONE, and the responder selects that > Diffie-Hellman group, then it MUST ignore the initiator's KE > payload and omit the KE payload from the response. > >I.e. the MUST ignore, and omit the KE payload is only applicable if >responder actually selects the Diffie-Hellman group NONE. That makes good sense to me, and seems like less of a change to 4306 than the current wording. Do others agree? --Paul Hoffman, Director --VPN Consortium _______________________________________________ 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 Scanned by Check Point Total Security Gateway. From syedah@huawei.com Tue Mar 9 03:44:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001F53A680B for ; Tue, 9 Mar 2010 03:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrPyazkNSIS9 for ; Tue, 9 Mar 2010 03:44:51 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 15BBB3A67FC for ; Tue, 9 Mar 2010 03:44:51 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZ000ESXJAKET@szxga04-in.huawei.com> for ipsec@ietf.org; Tue, 09 Mar 2010 19:44:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZ0006K5JAK2C@szxga04-in.huawei.com> for ipsec@ietf.org; Tue, 09 Mar 2010 19:44:44 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZ000758JAKP5@szxml04-in.huawei.com> for ipsec@ietf.org; Tue, 09 Mar 2010 19:44:44 +0800 (CST) Date: Tue, 09 Mar 2010 17:14:43 +0530 From: Syed Ajim Hussain In-reply-to: To: ipsec@ietf.org Message-id: <000901cabf7d$e9cb1c20$1f01120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acq++rFZZF8TWUcGTpiSdMcG2cIlIQAgbLwg References: Subject: [IPsec] IPsec easy VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 11:44:52 -0000 Hi All Many IPSec vendor support Easy VPN Clients, As I want to know , there is no separate RFC for Easy VPN, How this clients compatible with IPSEC Easy VPN Server? Easy VPN Client uses Mode-Configuration to get IP- Address, DNS Server Address, IPSEC proposal information , ACL information from Server, Where as Mode-Configuration does not have any Easy-VPN Specific Attributes. So does these Easy VPN Mode-Configuration attributes privately defined? Does any company have patent on Easy-VPN Technology. The following attributes are currently defined: Attribute Value Type Length ========================= ======= ========== ===================== RESERVED 0 INTERNAL_IP4_ADDRESS 1 Variable 0 or 4 octets INTERNAL_IP4_NETMASK 2 Variable 0 or 4 octets INTERNAL_IP4_DNS 3 Variable 0 or 4 octets INTERNAL_IP4_NBNS 4 Variable 0 or 4 octets INTERNAL_ADDRESS_EXPIRY 5 Variable 0 or 4 octets INTERNAL_IP4_DHCP 6 Variable 0 or 4 octets APPLICATION_VERSION 7 Variable 0 or more INTERNAL_IP6_ADDRESS 8 Variable 0 or 16 octets INTERNAL_IP6_NETMASK 9 Variable 0 or 16 octets INTERNAL_IP6_DNS 10 Variable 0 or 16 octets INTERNAL_IP6_NBNS 11 Variable 0 or 16 octets INTERNAL_IP6_DHCP 12 Variable 0 or 16 octets INTERNAL_IP4_SUBNET 13 Variable 0 or 4 octets SUPPORTED_ATTRIBUTES 14 Variable 0 or multiples of 2 Reserved for future use 15-16383 Reserved for private use 16384-32767 **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** From Pasi.Eronen@nokia.com Tue Mar 9 03:52:47 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11A43A68EA for ; Tue, 9 Mar 2010 03:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iap9BRtxX2RJ for ; Tue, 9 Mar 2010 03:52:46 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D1F353A68D7 for ; Tue, 9 Mar 2010 03:52:46 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o29BqQsU023652; Tue, 9 Mar 2010 05:52:50 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 13:52:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 13:52:44 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 9 Mar 2010 12:52:43 +0100 From: To: Date: Tue, 9 Mar 2010 12:52:43 +0100 Thread-Topic: [IPsec] Issue #176: What to do with a proposal of NONE Thread-Index: Acq+0YCnP5qtDPWVS9anDVmYrxWrMAArXX+Q Message-ID: <808FD6E27AD4884E94820BC333B2DB77584836B95D@NOK-EUMSG-01.mgdnok.nokia.com> References: <19349.4958.130660.415650@fireball.kivinen.iki.fi> In-Reply-To: <19349.4958.130660.415650@fireball.kivinen.iki.fi> 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 X-OriginalArrivalTime: 09 Mar 2010 11:52:44.0474 (UTC) FILETIME=[07B821A0:01CABF7F] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #176: What to do with a proposal of NONE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 11:52:47 -0000 Tero Kivinen wrote: > The last sentence is the one that is misleading. All of the rest of > the paragraph is just repeation of the text from elsewhere. >=20 > The last sentence should be saying: >=20 > If one of the proposals offered is for the > Diffie-Hellman group of NONE, and the responder selects that > Diffie-Hellman group, then it MUST ignore the initiator's KE > payload and omit the KE payload from the response. >=20 > I.e. the MUST ignore, and omit the KE payload is only applicable if > responder actually selects the Diffie-Hellman group NONE. This looks correct to me. Best regards, Pasi From ynir@checkpoint.com Tue Mar 9 03:54:17 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A12B3A68C9 for ; Tue, 9 Mar 2010 03:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq5fcgYPoke0 for ; Tue, 9 Mar 2010 03:53:36 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A70AB3A68EA for ; Tue, 9 Mar 2010 03:53:35 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o29Brcsd027194; Tue, 9 Mar 2010 13:53:38 +0200 (IST) X-CheckPoint: {4B96353F-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 9 Mar 2010 13:53:58 +0200 From: Yoav Nir To: "'Keith Welter'" , "ipsec@ietf.org" Date: Tue, 9 Mar 2010 13:53:58 +0200 Thread-Topic: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 Thread-Index: Acq+2vthQ2usCBK4RzON7JP7wa5ZgQApBw7g Message-ID: <006FEB08D9C6444AB014105C9AEB133FB37650C505@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 11:54:17 -0000 To me it=92s pretty obviously the former, although the latter is also true. ________________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of K= eith Welter Sent: Monday, March 08, 2010 6:18 PM To: ipsec@ietf.org Subject: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 Section 2.23, paragraph starting:=20 "An initiator can use port 4500 for both IKE and ESP, regardless of=20 =A0whether or not there is a NAT, even at the beginning of IKE.".=20 What does, "even at the beginning of IKE" mean?=20 Does it mean,=20 =A0 "even when sending an IKE_SA_INIT request"=20 or=20 =A0 "even at any point during the initial exchanges"?=20 =20 From paul.hoffman@vpnc.org Tue Mar 9 09:37:24 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847FD3A683E for ; Tue, 9 Mar 2010 09:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiBkK-d00DZd for ; Tue, 9 Mar 2010 09:37:23 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8D8323A6830 for ; Tue, 9 Mar 2010 09:37:22 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o29HbPIb080832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Mar 2010 10:37:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 9 Mar 2010 09:37:12 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] IPR statement for draft-detienne-ikev2-recovery X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 17:37:24 -0000 Greetings again. Cisco has recently posted an IPR statement that is relevant to our charter. Please see . You can see the patent application referenced in the IPR statement at . Before reacting to this announcement, please review the IETF's IPR policy at , and please read the specific IPR statement carefully. You may wish to inform any legal counsel you have about this. On a personal note, I believe that it would have been much more appropriate for Cisco to have let the WG know about this IPR before we put the draft by name in our charter. I also note that at least one of the co-authors on the named draft was not informed of the IPR; in my opinion, this is particularly inappropriate. We will begin the discussion of which secure crash discovery protocol the WG wants to adopt in the next few days, and this IPR statement might or might not affect the outcome, based on what the WG desires. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Mar 9 10:34:10 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1313A6924 for ; Tue, 9 Mar 2010 10:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HowvOKU4lZP for ; Tue, 9 Mar 2010 10:34:09 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CD6DF3A6819 for ; Tue, 9 Mar 2010 10:34:09 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o29IYDIY084327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Mar 2010 11:34:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 9 Mar 2010 10:31:10 -0800 To: "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Response to Pasi's AD comments on the roadmap draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 18:34:10 -0000 I would like to see much more comment from the WG on this thread. In general, I agree with Sheila and Suresh's reply to Pasi, but others should chime in as well. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Mar 9 10:37:09 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E64D3A69F0 for ; Tue, 9 Mar 2010 10:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.919 X-Spam-Level: X-Spam-Status: No, score=-5.919 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+oiNR9NRNGb for ; Tue, 9 Mar 2010 10:37:08 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 361093A6A08 for ; Tue, 9 Mar 2010 10:37:08 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o29IYDIa084327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Mar 2010 11:34:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 9 Mar 2010 10:34:11 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Pasi's AD comments on roadmap doc - RFCs to add/delete X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 18:37:09 -0000 At 1:13 PM -0500 3/8/10, Frankel, Sheila E. wrote: >Here are the RFCs that Pasi suggested adding/removing from the roadmap doc. If anyone has any strong opinions either pro or con, now's the time to speak up. > >Sheila and Suresh > >---------------------------------------------------------------------------- > >several groups of RFCs that Pasi wants us to remove: > >1) RFCs that define how to configure IPsec for use in other protocols, but don't > modify/extend how IPsec works (We would prefer to keep these in the roadmap): > 8.1.1. RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual Private > Network (VPN) Gateways > 8.1.2. RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways > 8.1.5. RFC 5213, Proxy Mobile IPv6 > 8.1.6. RFC 5268, Mobile IPv6 Fast Handovers > 8.1.7. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management > 8.2.1. RFC 4552, Authentication/Confidentiality for OSPFv3 I agree with Sheila and Suresh, and disagree with Pasi: these should stay in the roadmap. IPsec implementers should be aware that these other IETF protocols have specific profiles for IPsec. > >2) MIKEY: creates security associations for SRTP, not IPsec -- so it's not really > relevant for this document > 6.7. RFC 3830, MIKEY: Multimedia Internet KEYing > 6.8. RFC 4738, MIKEY-RSA-R: An Additional Mode of Key Distribution in > Multimedia Internet KEYing (MIKEY) > 6.9. RFC 5197, On the Applicability of Various Multimedia Internet KEYing > (MIKEY) Modes and Extensions > 6.10. RFC 4563, The Key ID Information Type for the General Extension Payload > in Multimedia Internet KEYing (MIKEY) > 6.12. RFC 4650, HMAC-Authenticated Diffie-Hellman for Multimedia Internet > KEYing (MIKEY) > 6.13. RFC 5410, Multimedia Internet KEYing (MIKEY) General Extension Payload > for Open Mobile Alliance BCAST 1.0 > >3) I'm not sure what 4534/4535 have to do with IPsec; it doesn't look like it supports > creating IPsec SAs, for example. > 6.5. RFC 4535, GSAKMP: Group Secure Association Key Management Protocol > 6.6. RFC 4534, Group Security Policy Token v1 > >4) not about IPsec, but non-IPsec approaches to securing multicast; so they don't > really belong here. > 6.14. RFC 4082, Timed Efficient Stream Loss-Tolerant Authentication (TESLA): > Multicast Source Authentication Transform Introduction > 6.15. RFC 4442, Bootstrapping Timed Efficient Stream Loss-Tolerant > Authentication (TESLA) > 6.16. RFC 4383, The Use of Timed Efficient Stream Loss-Tolerant Authentication > (TESLA) in the Secure Real-time Transport Protocol I'm fine with removing all of those. > >---------------------------------------------------------------------------- >RFCs that Pasi suggests adding: > RFC 2521, ICMP Security Failures Messages (E, Mar 1999) > RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains (I, Oct 1999) > RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol > (SIP) (S, Jan 2003) > RFC 4322, Opportunistic Encryption using the Internet Key Exchange (IKE) > (I, Dec 2005) > RFC 4705, GigaBeam High-Speed Radio Link Encryption (I, Oct 2006) > RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario (S, Oct 2007) I agree about adding 3329, 4322, and 5026. The others seem superfluous. --Paul Hoffman, Director --VPN Consortium From B22245@freescale.com Tue Mar 9 22:47:17 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438E03A69D8 for ; Tue, 9 Mar 2010 22:47:17 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLMK1ESYModG for ; Tue, 9 Mar 2010 22:47:16 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 170C93A6B2C for ; Tue, 9 Mar 2010 22:47:15 -0800 (PST) Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id o2A6l5u9004630 for ; Tue, 9 Mar 2010 23:47:10 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id o2A6rvfC024743 for ; Wed, 10 Mar 2010 00:53:58 -0600 (CST) 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, 10 Mar 2010 12:17:02 +0530 Message-ID: <402621A7D69DDA458D0E12F070D1E55F71588C@zin33exm29.fsl.freescale.net> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C505@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 Thread-Index: Acq+2vthQ2usCBK4RzON7JP7wa5ZgQApBw7gACb+XZA= References: <006FEB08D9C6444AB014105C9AEB133FB37650C505@il-ex01.ad.checkpoint.com> From: "V Jyothi-B22245" To: "Yoav Nir" , "Keith Welter" , Subject: Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 06:47:17 -0000 =20 An initiator can use port 4500 for both IKE packets even while sending = IKE_SA_INIT request. I think responder can also use port 4500 for sending IKE_SA_INIT = response. But IKE packets sending on port 4500 should be encapsulated with = NON-ESP-MARKER. Thanks Jyothi -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Yoav Nir Sent: Tuesday, March 09, 2010 5:24 PM To: 'Keith Welter'; ipsec@ietf.org Subject: Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 To me it's pretty obviously the former, although the latter is also = true. ________________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Keith Welter Sent: Monday, March 08, 2010 6:18 PM To: ipsec@ietf.org Subject: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08 Section 2.23, paragraph starting:=20 "An initiator can use port 4500 for both IKE and ESP, regardless of =A0whether or not there is a NAT, even at the beginning of IKE.".=20 What does, "even at the beginning of IKE" mean?=20 Does it mean, =A0 "even when sending an IKE_SA_INIT request"=20 or =A0 "even at any point during the initial exchanges"?=20 =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Wed Mar 10 11:12:40 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ECA23A6956 for ; Wed, 10 Mar 2010 11:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.914 X-Spam-Level: X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyEOCFYEg6LE for ; Wed, 10 Mar 2010 11:12:37 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D89433A696D for ; Wed, 10 Mar 2010 11:12:36 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2AJCeR0068351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Mar 2010 12:12:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 10 Mar 2010 11:12:38 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Agenda for Anaheim X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 19:12:40 -0000 Greetings again. The first draft of the agenda for the Anaheim meeting is now up at . It currently reads: 0900 Agenda bash 0905 Brief review of document status 0915 IPsec HA - Yoav Nir 0930 EAP-only authentication - Yaron Sheffer 0945 Failure detection discussion - Paul Hoffman 1015 PAKE authentication discussion - Paul Hoffman 1100 Roadmap discussion, if issues are still open 1130 Adjourn Discussion is welcome. (But even more welcome would be comments on the Roadmap documents...) --Paul Hoffman, Director --VPN Consortium From seonghan.shin@aist.go.jp Wed Mar 10 19:03:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212623A6B8A for ; Wed, 10 Mar 2010 19:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.669 X-Spam-Level: * X-Spam-Status: No, score=1.669 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIB9EfBo9l2J for ; Wed, 10 Mar 2010 19:03:27 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id C29343A6B22 for ; Wed, 10 Mar 2010 19:03:26 -0800 (PST) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id o2B33SLR015518; Thu, 11 Mar 2010 12:03:28 +0900 (JST) env-from (seonghan.shin@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1268276608; bh=U01T+dG71AwNN06KKYHJkmPYZpoE/D7bG2VD6nCynSQ=; h=From:Date:Message-ID; b=YKBw7Cuuc11d3UTbVglGJBTI/fYx5G2TkjlR2OZpN0oa8wa7rD7fB3mvUGPsmXWOA QPFRiSiz4ISeOClA4Dgy0bIUm4a5QutXhQPuc9+HBrEFMGdUCw94UnzJ+7ZORxiGLv EjLv7bi5+GxvyIT5RF4+HkFOxxCVc7gMZz18Fzcc= Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id o2B33Rv9007262; Thu, 11 Mar 2010 12:03:27 +0900 (JST) env-from (seonghan.shin@aist.go.jp) Received: by smtp2.aist.go.jp with ESMTP id o2B33Mak007075; Thu, 11 Mar 2010 12:03:25 +0900 (JST) env-from (seonghan.shin@aist.go.jp) From: "SeongHan Shin" To: "'Paul Hoffman'" References: In-Reply-To: Date: Thu, 11 Mar 2010 12:03:08 +0900 Message-ID: <001901cac0c7$607d74e0$21785ea0$@shin@aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrAhbHS/lLPruZWRTWvd7BSK9+WDQAQLoZw Content-Language: ja Cc: 'IPsecme WG' , 'Kazukuni Kobara' , 'SeongHan Shin' Subject: Re: [IPsec] Agenda for Anaheim X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 03:03:28 -0000 Dear Paul Hoffman, I'm Shin. I submitted the below I-D (00) and have just finished the IPR disclosure one hour ago. Could you please let me know if it is possible for me to present our work in IPsecme WG? Filename: draft-shin-augmented-pake Revision: 00 Title: Most Efficient Augmented Password-Only Authentication and Key Exchange Creation_date: 2010-03-01 WG ID: Independent Submission Number_of_pages: 14 Abstract: This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary whose space is within the off-line dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). Best regards, Shin > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Thursday, March 11, 2010 4:13 AM > To: IPsecme WG > Subject: [IPsec] Agenda for Anaheim > > Greetings again. The first draft of the agenda for the Anaheim meeting is > now up at . It > currently reads: > > 0900 Agenda bash > 0905 Brief review of document status > 0915 IPsec HA - Yoav Nir > 0930 EAP-only authentication - Yaron Sheffer > 0945 Failure detection discussion - Paul Hoffman > 1015 PAKE authentication discussion - Paul Hoffman > 1100 Roadmap discussion, if issues are still open > 1130 Adjourn > > Discussion is welcome. (But even more welcome would be comments on the > Roadmap documents...) > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Wed Mar 10 20:02:27 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338E83A6A35 for ; Wed, 10 Mar 2010 20:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.923 X-Spam-Level: X-Spam-Status: No, score=-5.923 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHWHEaMFyOg9 for ; Wed, 10 Mar 2010 20:02:26 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6493F3A6801 for ; Wed, 10 Mar 2010 20:02:26 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2B42Qap094229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Mar 2010 21:02:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <001901cac0c7$607d74e0$21785ea0$@shin@aist.go.jp> References: <001901cac0c7$607d74e0$21785ea0$@shin@aist.go.jp> Date: Wed, 10 Mar 2010 20:02:25 -0800 To: "SeongHan Shin" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: 'IPsecme WG' , 'Kazukuni Kobara' , 'SeongHan Shin' Subject: Re: [IPsec] Agenda for Anaheim X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 04:02:27 -0000 At 12:03 PM +0900 3/11/10, SeongHan Shin wrote: >I submitted the below I-D (00) and have just finished the IPR disclosure one >hour ago. >Could you please let me know if it is possible for me to present >our work in IPsecme WG? We are not focusing on specific presentations, but instead on the criteria that the WG should be using to use to choose which proposal, or variant of a proposal, we want to go forward with. Please see the earlier discussion on those criteria, and feel free to say how you feel this proposal fits into those criteria, as well as the criteria for which you think your proposal is strong. --Paul Hoffman, Director --VPN Consortium From seonghan.shin@aist.go.jp Wed Mar 10 22:23:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED03B3A6B2A for ; Wed, 10 Mar 2010 22:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.591 X-Spam-Level: * X-Spam-Status: No, score=1.591 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TNLw2rtbC+w for ; Wed, 10 Mar 2010 22:22:59 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id 40CB13A6850 for ; Wed, 10 Mar 2010 22:18:17 -0800 (PST) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o2B6IIKt008297; Thu, 11 Mar 2010 15:18:18 +0900 (JST) env-from (seonghan.shin@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1268288299; bh=MhrCz6E2Uu36hpQ3stQtLjnGDR3lP/kA6fjpa4Jy/S4=; h=From:Date:Message-ID; b=h79P8bXOvIc2vNGPtN4IFc4TS/E/6gOPNAIxl+ylIVxd1cm9wAwBmwow6mpfOhWCD vzx6wf/PFkrFGite6X6HfZYeBa12jXQxY90ue4TBKdIyEsyraOiusPfot4Fu12zHjK tNMFJWG7jBfEqdHH0pDhUi7jVt96e/5MR8KCCZzI= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o2B6IIxw000066; Thu, 11 Mar 2010 15:18:18 +0900 (JST) env-from (seonghan.shin@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id o2B6IEDa027814; Thu, 11 Mar 2010 15:18:16 +0900 (JST) env-from (seonghan.shin@aist.go.jp) From: "SeongHan Shin" To: "'Paul Hoffman'" References: <001901cac0c7$607d74e0$21785ea0$@shin@aist.go.jp> In-Reply-To: Date: Thu, 11 Mar 2010 15:17:59 +0900 Message-ID: <001b01cac0e2$98bc0040$ca3400c0$@shin@aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrAz7m2rMcKVWGSQHykz7mEnRRhGwAElnZQ Content-Language: ja Cc: 'IPsecme WG' , 'Kazukuni Kobara' , 'SeongHan Shin' Subject: Re: [IPsec] Agenda for Anaheim X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 06:23:11 -0000 Dear Paul Hoffman, Thank you for your quick response. Below is the summary. This draft describes AugPAKE. For simplicity, I discuss some criteria (written in and appeared in IPsecme WG mailing list). If I miss something, please let me know. For references of EKE, SRP, SPSK, SPEKE and PAK, see . ---------------------------------------------------------------- 1. Security PAKE can be divided into balanced PAKE and augmented PAKE. Balanced PAKE provides security against only active attacks (including off-line dictionary attacks). Examples: EKE, SPSK, SPEKE, PAK Augmented PAKE provides security of balanced PAKE + "resistance to server compromise" (see our draft for this security property) Examples: SRP, AugPAKE 2. Underlying groups AugPAKE over any groups (e.g., MODP, ECP) where the Diffie-Hellman problem holds. EKE, SRP and PAK need a care when selecting groups because of ideal cipher, protocol structure or FDH (Full-Domain Hash). FDH maps a hashed value to a group element. 3. Implementation Because of the above reason, AugPAKE can be easily implemented. We already implemented AugPAKE. 4. Efficiency 1) AugPAKE requires less modular exponentiation than SRP and SPSK. It is almost same as EKE, SPEKE and PAK. 2) Number of rounds of AugPAKE is same as SRP (4 rounds). 3 rounds: EKE, SPSK (can be adjusted), SPEKE, PAK 5. Intellectual property AIST will provide a royalty-free license for implementations of AugPAKE. We think that AugPAKE is not involved to other patents. (But, I am not a patent lawyer) ---------------------------------------------------------------- Best regards, Shin > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Thursday, March 11, 2010 1:02 PM > To: SeongHan Shin > Cc: 'IPsecme WG'; 'Kazukuni Kobara'; 'SeongHan Shin' > Subject: Re: [IPsec] Agenda for Anaheim > > At 12:03 PM +0900 3/11/10, SeongHan Shin wrote: > >I submitted the below I-D (00) and have just finished the IPR disclosure > one > >hour ago. > >Could you please let me know if it is possible for me to present > >our work in IPsecme WG? > > We are not focusing on specific presentations, but instead on the criteria > that the WG should be using to use to choose which proposal, or variant > of a proposal, we want to go forward with. Please see the earlier discussion > on those criteria, and feel free to say how you feel this proposal fits > into those criteria, as well as the criteria for which you think your > proposal is strong. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf@checkpoint.com Thu Mar 11 01:17:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE9B3A6B2E for ; Thu, 11 Mar 2010 01:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX4LaoDAltN1 for ; Thu, 11 Mar 2010 01:17:00 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 488C93A6A62 for ; Thu, 11 Mar 2010 01:16:51 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2B9Gqsd012689 for ; Thu, 11 Mar 2010 11:16:52 +0200 (IST) X-CheckPoint: {4B98B36C-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 11 Mar 2010 11:17:13 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Thu, 11 Mar 2010 11:17:12 +0200 Thread-Topic: New criteria draft Thread-Index: AQHKwPuiAvfxHY47Q0ec2sguMackgQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889ilex01adche_" MIME-Version: 1.0 Subject: [IPsec] New criteria draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 09:17:11 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889ilex01adche_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Based on mailing list comments, I have posted a revision of draft-sheffer-i= psecme-pake-criteria here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/= TempDocs. I will submit it as usual when the submission window reopens. Thanks, Yaron --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889ilex01adche_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Based on mailing list com= ments, I have posted a revision of draft-sheffer-ipsecme-pake-criteria here: http://trac.tools.ietf.org/wg/ips= ecme/trac/wiki/TempDocs. I will submit it as usual when the subm= ission window reopens.
 
Thanks,
     = Yaron
--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889ilex01adche_-- From alper.yegin@yegin.org Thu Mar 11 08:58:41 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A9B3A6ACD for ; Thu, 11 Mar 2010 08:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWTHwyx6IIwe for ; Thu, 11 Mar 2010 08:58:38 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 222393A6951 for ; Thu, 11 Mar 2010 08:50:57 -0800 (PST) Received: from ibm ([193.153.155.170]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MO6v6-1NmRgL3rDo-005Vqy; Thu, 11 Mar 2010 11:51:02 -0500 From: "Alper Yegin" To: "'ipsec'" Date: Thu, 11 Mar 2010 18:50:42 +0200 Message-ID: <00e601cac13a$feeed790$fccc86b0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01CAC14B.C277A790" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrBOvbDlhuTO80ORuqQSKbz1CMwSg== Content-Language: en-us x-cr-hashedpuzzle: AEEt BLNG Bpwj C6hW DFNs D0v/ EewH Fox1 FyYL GGo4 H74X IPzT Id5Y IkUN IoY9 LQOX; 1; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {34496911-DD1C-4CE9-B89B-A8E777AD9D50}; YQBsAHAAZQByAC4AeQBlAGcAaQBuAEAAeQBlAGcAaQBuAC4AbwByAGcA; Thu, 11 Mar 2010 16:50:32 GMT; SQBLAEUAdgAyACAAdgBlAG4AZABvAHIALQBzAHAAZQBjAGkAZgBpAGMAIABwAGEAeQBsAG8AYQBkAA== x-cr-puzzleid: {34496911-DD1C-4CE9-B89B-A8E777AD9D50} X-Provags-ID: V01U2FsdGVkX197ynoOX5XDOM7yp66DokjTcVgiQNiDV/4OaSB WDfbjAqffdEhtbAvpscTEJtLcASSPmuz9s2mrvoOT0zGK+fgnk W7Y3ziVqizX6ogRa4c2cRJdjDiWmNZ+ Subject: [IPsec] IKEv2 vendor-specific payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 16:58:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E7_01CAC14B.C277A790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, What is the recommended approach for defining vendor-specific configuration payload with IKEv2? According to my reading of RFC 4306, there is a bit of a room there. Vendor ID payload is not mandatory to use in such a case. And even when it is used, the VID can be anything (there is no mandate for using Enterprise ID, or anything that is globally managed). Other protocols I'm familiar with are more strict about defining vendor-specific options/payloads. So, it makes me wonder if there are some current practices that we should use when defining new payloads. Thank you. Alper ------=_NextPart_000_00E7_01CAC14B.C277A790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

What is the recommended approach for defining vendor-specific configuration payload with IKEv2?

 

According to my reading of RFC 4306, there is a bit = of a room there. Vendor ID payload is not mandatory to use in such a case. = And even when it is used, the VID can be anything (there is no mandate for using = Enterprise ID, or anything that is globally managed).

 

Other protocols I’m familiar with are more = strict about defining vendor-specific options/payloads.

 

So, it makes me wonder if there are some current = practices that we should use when defining new payloads.

 

Thank you.

 

Alper

 

 

 

 

------=_NextPart_000_00E7_01CAC14B.C277A790-- From dharkins@lounge.org Thu Mar 11 09:57:42 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892E43A6DD2 for ; Thu, 11 Mar 2010 09:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjooGZoMBRRN for ; Thu, 11 Mar 2010 09:57:41 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 973B83A6922 for ; Thu, 11 Mar 2010 09:35:37 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D56911022404A; Thu, 11 Mar 2010 09:35:42 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 11 Mar 2010 09:35:43 -0800 (PST) Message-ID: <39fb97c8009b2eefcbed01b9f77d9cea.squirrel@www.trepanning.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889@il-ex01.ad.checkpoint.com> Date: Thu, 11 Mar 2010 09:35:43 -0800 (PST) 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: "ipsec@ietf.org" Subject: Re: [IPsec] New criteria draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 17:57:42 -0000 Hi Yaron, One comment you might've missed was this: Also, the table in section 5 should include IEEE 802.11s under the "standards" column for SPSK. And the phrase "may or may not infringe on existing patents" applies to all candidates, and frankly, to almost everything in the IETF. It is a meaningless phrase and it would be better to just remove it from the "IPR" column. That comment also received a "+1" from another commenter on the list. Also, I think this takes us down a particularly bad path: o Ideally, the proposal should be unencumbered. This property is very difficult to prove, and each WG participant should attempt to review the applicable patents and determine whether in fact they do not apply to the proposal. Remember that independently invented technology might still infringe a patent. o In some cases the IPR situation is clear: if the protocol relies on a specific patent, and believed to not require the use of any other. This is mostly useful if the patent's licensing terms (whether free or not) are known, and/or the patent's expiration date is near. So while we start off our criteria grandly with "it should be unencumbered" we immediately then dismiss that by saying we can't forget it might still be patented by some unknown patent. So "ideally" is just one of those states we cannot achieve because even if it's "unencumbered" it might not be. So that's off, what's next? If the IPR situation is clear, it relies on a specific patent and the patent's expiration date is near. So I guess we're just supposed to stop here, right? It is unwise for anyone to say what another IP holder will say with respect to his or her IPR. And there might be a patent that covers everything done in the IETF, we just don't know and it's not our job to prove a negative. So I think it would be very unfortunate if the discussion of candidates jumped down this rathole. We would have "I'm not a lawyer but..." followed by a contentious statement and 8 people jumping up to the queue on the mic to precede their comments with "I'm not a lawyer but..." and then make other contentious statements. I think the IPR content in this draft should be as simple as possible: o We live in a litigious world and patents are used as both a club and a shield. o Patents might or might not exist on every technology we discuss. o We should not attempt to prove or disprove whether this or that patent might or might not cover some technology. o It is not our job to prove that no patents apply to some technology. It would be great to choose a technology that does not require any licensing but as we've seen in the last couple days even the most straightforward and innocent of protocols that we choose to adopt can still be encumbered. regards, Dan. On Thu, March 11, 2010 1:17 am, Yaron Sheffer wrote: > Hi, > > Based on mailing list comments, I have posted a revision of > draft-sheffer-ipsecme-pake-criteria here: > http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs. I will submit it > as usual when the submission window reopens. > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf@checkpoint.com Thu Mar 11 10:59:01 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292253A6988 for ; Thu, 11 Mar 2010 10:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdhZD1Kw3e0j for ; Thu, 11 Mar 2010 10:58:59 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id EEF683A6ACD for ; Thu, 11 Mar 2010 10:33:13 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2BIXHsd012411; Thu, 11 Mar 2010 20:33:17 +0200 (IST) X-CheckPoint: {4B9935D1-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 11 Mar 2010 20:33:38 +0200 From: Yaron Sheffer To: Dan Harkins Date: Thu, 11 Mar 2010 20:33:37 +0200 Thread-Topic: [IPsec] New criteria draft Thread-Index: AcrBQVVtzbfQ9T6/TJSE5bqhCbzq/AABYQyc Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889@il-ex01.ad.checkpoint.com>, <39fb97c8009b2eefcbed01b9f77d9cea.squirrel@www.trepanning.net> In-Reply-To: <39fb97c8009b2eefcbed01b9f77d9cea.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89Cilex01adche_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New criteria draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 18:59:01 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89Cilex01adche_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dan, thanks for your comments. Please see my response inline. Yaron ________________________________________ From: Dan Harkins [dharkins@lounge.org] Sent: Thursday, March 11, 2010 7:35 PM To: Yaron Sheffer Cc: ipsec@ietf.org Subject: Re: [IPsec] New criteria draft Hi Yaron, One comment you might've missed was this: Also, the table in section 5 should include IEEE 802.11s under the "standards" column for SPSK. And the phrase "may or may not infringe on existing patents" applies to all candidates, and frankly, to almost everything in the IETF. It is a meaningless phrase and it would be better to just remove it from the "IPR" column. That comment also received a "+1" from another commenter on the list. In fact, I did not miss these two comments. I did not list 802.11s because = I prefer to list only standards that are primarily vetted by the security c= ommunity. Hence the "Securty Standards" column in -01. Regarding the second comment, while in principle I agree that it could appl= y to anything done at the IETF, unfortunately in our case it does apply. It= applies because of two reasons: - Spurious (whether legitimate or not, I cannot say) IPR statements made ag= aist SRP. - The sheer amount of patents in this area that must be analysed to ensure,= with a high level of confidence, that you will not be sued for implementin= g X. And I disagree with your statement below, "It is not our job to prove that = no patents apply to some technology." As individuals, and for many of us, a= s employees, it is our job to ensure ourselves that we (or our company) wil= l not be getting into legal/financial trouble by making this choice. And I don't think this is "proving a negative". We can think of a process t= o get this level of confidence. But just shouting at one another will not g= et us there. Please see http://tools.ietf.org/html/draft-mcgrew-fundamental= -ecc-01 for a creative approach to deal with IPR in another, somewhat relat= ed, contentious area. Having said that, if you read -01 carefully, you will see that I'd rather f= ocus our energies on discussing the security aspects rather than endlessly = discussing IPR. And by the way, which protocol are you referring to in the last paragraph? Also, I think this takes us down a particularly bad path: o Ideally, the proposal should be unencumbered. This property is very difficult to prove, and each WG participant should attempt to review the applicable patents and determine whether in fact they do not apply to the proposal. Remember that independently invented technology might still infringe a patent. o In some cases the IPR situation is clear: if the protocol relies on a specific patent, and believed to not require the use of any other. This is mostly useful if the patent's licensing terms (whether free or not) are known, and/or the patent's expiration date is near. So while we start off our criteria grandly with "it should be unencumbered" we immediately then dismiss that by saying we can't forget it might still be patented by some unknown patent. So "ideally" is just one of those states we cannot achieve because even if it's "unencumbered" it might not be. So that's off, what's next? If the IPR situation is clear, it relies on a specific patent and the patent's expiration date is near. So I guess we're just supposed to stop here, right? It is unwise for anyone to say what another IP holder will say with respect to his or her IPR. And there might be a patent that covers everything done in the IETF, we just don't know and it's not our job to prove a negative. So I think it would be very unfortunate if the discussion of candidates jumped down this rathole. We would have "I'm not a lawyer but..." followed by a contentious statement and 8 people jumping up to the queue on the mic to precede their comments with "I'm not a lawyer but..." and then make other contentious statements. I think the IPR content in this draft should be as simple as possible: o We live in a litigious world and patents are used as both a club and a shield. o Patents might or might not exist on every technology we discuss. o We should not attempt to prove or disprove whether this or that patent might or might not cover some technology. o It is not our job to prove that no patents apply to some technology. It would be great to choose a technology that does not require any licensing but as we've seen in the last couple days even the most straightforward and innocent of protocols that we choose to adopt can still be encumbered. regards, Dan. On Thu, March 11, 2010 1:17 am, Yaron Sheffer wrote: > Hi, > > Based on mailing list comments, I have posted a revision of > draft-sheffer-ipsecme-pake-criteria here: > http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs. I will submit i= t > as usual when the submission window reopens. > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > Scanned by Check Point Total Security Gateway. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89Cilex01adche_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dan,

 

thanks for your comments. Please see my r= esponse inline.

 

   Yaron

________________________________________
From: Dan Harkins [dharkins@lounge.org]
Sent: Thursday, March 11, 2010 7:35 PM
To: Yaron Sheffer
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New criteria draft

  Hi Yaron,

  One comment you might've missed was this:

     Also, the table in section 5 should include IEEE 8= 02.11s under the
     "standards" column for SPSK. And the phr= ase "may or may not infringe
     on existing patents" applies to all candidate= s, and frankly, to
     almost everything in the IETF. It is a meaningless= phrase and it
     would be better to just remove it from the "I= PR" column.

That comment also received a "+1" from another commenter on t= he list.

<YS>

In fact, I did not miss these two comment= s. I did not list 802.11s because I prefer to list only standards that are = primarily vetted by the security community. Hence the "Securty Standar= ds" column in -01.

 

Regarding the second comment, while in pr= inciple I agree that it could apply to anything done at the IETF, unfortuna= tely in our case it does apply. It applies because of two reasons:

- Spurious (whether legitimate or not, I = cannot say) IPR statements made agaist SRP.

- The sheer amount of patents in this are= a that must be analysed to ensure, with a high level of confidence, that yo= u will not be sued for implementing X.

 

And I disagree with your statement below,= "It is not our job to prove that no patents apply to some technology.= " As individuals, and for many of us, as employees, it is our job to e= nsure ourselves that we (or our company) will not be getting into legal/financial trouble by making this choice.<= /p>

 

And I don't think this is "proving a= negative". We can think of a process to get this level of confidence.= But just shouting at one another will not get us there. Please see http= ://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01 for a creat= ive approach to deal with IPR in another, somewhat related, contentious are= a.

 

Having said that, if you read -01 carefully, you will see that I'd rathe= r focus our energies on discussing the security aspects rather than endless= ly discussing IPR.

 

And by the way, which protocol are you re= ferring to in the last paragraph?

</YS>


  Also, I think this takes us down a particularly bad path:

   o  Ideally, the proposal should be unencumbered.  Th= is property is
      very difficult to prove, and each WG partici= pant should attempt to
      review the applicable patents and determine = whether in fact they
      do not apply to the proposal.  Remember= that independently
      invented technology might still infringe a p= atent.
   o  In some cases the IPR situation is clear: if the proto= col relies
      on a specific patent, and believed to not re= quire the use of any
      other.  This is mostly useful if the pa= tent's licensing terms
      (whether free or not) are known, and/or the = patent's expiration
      date is near.

  So while we start off our criteria grandly with "it should be unencumbered" we immediately then dismiss that by saying we can't forg= et
it might still be patented by some unknown patent. So "ideally" i= s just
one of those states we cannot achieve because even if it's "unencumber= ed"
it might not be. So that's off, what's next? If the IPR situation is clear,=
it relies on a specific patent and the patent's expiration date is near. So I guess we're just supposed to stop here, right?

  It is unwise for anyone to say what another IP holder will say
with respect to his or her IPR. And there might be a patent that covers
everything done in the IETF, we just don't know and it's not our job to
prove a negative. So I think it would be very unfortunate if the discussion=
of candidates jumped down this rathole. We would have "I'm not a lawye= r
but..." followed by a contentious statement and 8 people jumping up to=
the queue on the mic to precede their comments with "I'm not a lawyer<= br> but..." and then make other contentious statements.

  I think the IPR content in this draft should be as simple as possibl= e:

    o We live in a litigious world and patents are used as b= oth a club
      and a shield.
    o Patents might or might not exist on every technology w= e discuss.
    o We should not attempt to prove or disprove whether thi= s or that
      patent might or might not cover some technol= ogy.
    o It is not our job to prove that no patents apply to so= me technology.

  It would be great to choose a technology that does not require any licensing but as we've seen in the last couple days even the most
straightforward and innocent of protocols that we choose to adopt can
still be encumbered.

  regards,

  Dan.

On Thu, March 11, 2010 1:17 am, Yaron Sheffer wrote:
> Hi,
>
> Based on mailing list comments, I have posted a revision of
> draft-sheffer-ipsecme-pake-criteria here:
> http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs. I will submi= t it
> as usual when the submission window reopens.
>
> Thanks,
>      Yaron
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



Scanned by Check Point Total Security Gateway.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89Cilex01adche_-- From thomwu@cisco.com Thu Mar 11 11:57:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FEF3A6B50 for ; Thu, 11 Mar 2010 11:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs9lj18UNJqI for ; Thu, 11 Mar 2010 11:57:30 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 982B53A6BCF for ; Thu, 11 Mar 2010 11:41:14 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4GAFbWmEurR7H+/2dsb2JhbACBRIQ3lAxYAnOkZJh4hHsEgxeIDw X-IronPort-AV: E=Sophos;i="4.49,622,1262563200"; d="scan'208,217";a="307873751" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 11 Mar 2010 19:41:14 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2BJfE9a000934; Thu, 11 Mar 2010 19:41:14 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Mar 2010 11:41:14 -0800 Received: from 171.69.140.225 ([171.69.140.225]) by xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Mar 2010 19:41:14 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 11 Mar 2010 11:43:06 -0800 From: thomwu To: Yaron Sheffer , "ipsec@ietf.org" Message-ID: Thread-Topic: [IPsec] New criteria draft Thread-Index: AQHKwPuiAvfxHY47Q0ec2sguMackgZHtJCxc In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3351152586_176878917" X-OriginalArrivalTime: 11 Mar 2010 19:41:14.0833 (UTC) FILETIME=[CFA00410:01CAC152] Subject: Re: [IPsec] New criteria draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 19:57:33 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3351152586_176878917 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Yaron, Under the =B3Security Standards=B2 column, ISO IEC 11770-4 =B3Mechanisms based on weak secrets=B2 should be mentioned. SPEKE is ISO IEC 11770-4 KAM1 SRP is ISO IEC 11770-4 KAM2 KAM stands for =B3Key Agreement Method=B2 in the context of the ISO document. Tom On 3/11/10 1:17 AM, "Yaron Sheffer" wrote: > Hi, > =20 > Based on mailing list comments, I have posted a revision of > draft-sheffer-ipsecme-pake-criteria here: > http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs > . I will submi= t it > as usual when the submission window reopens. > =20 > Thanks, > Yaron >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --B_3351152586_176878917 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [IPsec] New criteria draft Yaron,

Under the “Security Standards” column, ISO IEC 11770-4 “M= echanisms based on weak secrets” should be mentioned.

SPEKE is ISO IEC 11770-4 KAM1
SRP is ISO IEC 11770-4 KAM2

KAM stands for “Key Agreement Method” in the context of the ISO= document.

Tom

On 3/11/10 1:17 AM, "Yaron Sheffer" <yaronf@checkpoint.com> wrote:

Hi,
Based on mailing list= comments, I have posted a revision of draft-sheffer-ipsecme-pa= ke-criteria here: http://trac.tools.ietf.org/wg/ipsec= me/trac/wiki/TempDocs <http://trac.tools.ietf.org/wg/ipse= cme/trac/wiki/TempDocs> . I will submit it as usual when the submissi= on window reopens.
Thanks,
     Yaron

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/= mailman/listinfo/ipsec
--B_3351152586_176878917-- From dharkins@lounge.org Thu Mar 11 11:59:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F373A68B9 for ; Thu, 11 Mar 2010 11:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiHlEW-Tiey1 for ; Thu, 11 Mar 2010 11:59:33 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id CD32D3A6985 for ; Thu, 11 Mar 2010 11:45:10 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 320091022404A; Thu, 11 Mar 2010 11:45:16 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 11 Mar 2010 11:45:16 -0800 (PST) Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89C@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889@il-ex01.ad.checkpoint.com>, <39fb97c8009b2eefcbed01b9f77d9cea.squirrel@www.trepanning.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89C@il-ex01.ad.checkpoint.com> Date: Thu, 11 Mar 2010 11:45:16 -0800 (PST) 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: "ipsec@ietf.org" , Dan Harkins Subject: Re: [IPsec] New criteria draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 19:59:34 -0000 Hi Yaron, On Thu, March 11, 2010 10:33 am, Yaron Sheffer wrote: [snip] > > In fact, I did not miss these two comments. I did not list 802.11s because > I prefer to list only standards that are primarily vetted by the security > community. Hence the "Securty Standards" column in -01. Then neither draft-sheffer-emu-eap-eke nor draft-harkins-emu-eap-pwd should be listed since EMU is no more "the security community" than 802.11 is and an individual submission is not necessarily vetted by anybody, security or otherwise. I fail to see a rationale for only having "security standards" anyway. The table is illustrative, it's showing where the underlying exchange is used. > Regarding the second comment, while in principle I agree that it could > apply to anything done at the IETF, unfortunately in our case it does > apply. It applies because of two reasons: > > - Spurious (whether legitimate or not, I cannot say) IPR statements made > agaist SRP. > > - The sheer amount of patents in this area that must be analysed to > ensure, with a high level of confidence, that you will not be sued for > implementing X. Yes, it's true for our case. And, as I said, it's true for every case! Statements of "it may or may not..." apply to everything. You could just as easily, and correctly, said, "it may or may not be blue", or "it may or may not be carbon-based". Since the statement applies to everything it provides no meaning. It does mean something, though, when you selectively apply a statement that is true for everything. Which is further justification to remove it. > And I disagree with your statement below, "It is not our job to prove that > no patents apply to some technology." As individuals, and for many of us, > as employees, it is our job to ensure ourselves that we (or our company) > will not be getting into legal/financial trouble by making this choice. This is an IETF mailing list so I'm not using the 1st person plural to mean collective individuals or employees of various companies. I'm using it to mean people doing IETF business. It is not the function of the IETF to provide legal opinion on the validity of patents to prevent collections of individuals or various companies from "getting into legal/financial trouble". So it is not our job _as IETFers_ to prove whether patents do or do not exist and whether they apply to some technology or not. You can provide your opinion to your company all you want, that is eminently appropriate. I'll do the same to my company. And collectively you and I as individuals can sit around a bar somewhere and hash out IPR all we want. But getting into a "this applies and this doesn't apply and there's the evil specter of the unknown that might also apply" in the context of IETF work is not really approprate, and it's a rathole that we would be better off avoiding. > And I don't think this is "proving a negative". We can think of a process > to get this level of confidence. But just shouting at one another will not > get us there. Please see > http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01 for a creative > approach to deal with IPR in another, somewhat related, contentious area. There doesn't have to be shouting to have a rathole. Yes, David's Fundamental ECC draft is creative and useful. There are statements we can make regarding technology and the dates in which it was brought to the public's attention and that can be used by the WG when selecting a candidate. Let's take this as an example moving forward. We can make statements like: o "this technology was made public on "; and, o "this technology is covered by "; and, o "a patent has been applied for this technology on "; and, o "when this technology was made public it was stated that no known patents applied and no patent applications were filed" And since IPR has a time limit and we all acknowledge that something "may or may not apply" to everything under the sun then we can then make up our own minds on the topic. We don't need to get into the business of arguing about whether a patent applies or not, or whether unknown patents may or may not exist. > Having said that, if you read -01 carefully, you will see that I'd rather > focus our energies on discussing the security aspects rather than > endlessly discussing IPR. Yes, but unfortunately you have written a criteria draft that will ensure protracted and pointless IPR discussions when we get around to evaluating the candidates. regards, Dan. From Pasi.Eronen@nokia.com Fri Mar 12 05:48:55 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1C73A6B40 for ; Fri, 12 Mar 2010 05:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgfcLAFVUIdp for ; Fri, 12 Mar 2010 05:48:54 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 238923A691E for ; Fri, 12 Mar 2010 05:43:00 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2CDgTiS008973; Fri, 12 Mar 2010 15:43:03 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 15:42:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 15:42:18 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 12 Mar 2010 14:42:18 +0100 From: To: , Date: Fri, 12 Mar 2010 14:42:17 +0100 Thread-Topic: [IPsec] IKEv2 vendor-specific payload Thread-Index: AcrBOvbDlhuTO80ORuqQSKbz1CMwSgArOxNg Message-ID: <808FD6E27AD4884E94820BC333B2DB77584840C633@NOK-EUMSG-01.mgdnok.nokia.com> References: <00e601cac13a$feeed790$fccc86b0$@yegin@yegin.org> In-Reply-To: <00e601cac13a$feeed790$fccc86b0$@yegin@yegin.org> 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 X-OriginalArrivalTime: 12 Mar 2010 13:42:18.0722 (UTC) FILETIME=[D5840420:01CAC1E9] X-Nokia-AV: Clean Subject: Re: [IPsec] IKEv2 vendor-specific payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 13:48:55 -0000 Hi Alper I guess the preferred route is *not* defining vendor-specific configuration attributes, but instead publishing the spec and getting=20 an IANA-allocated number :-) (note that this doesn't absolutely require publishing it as RFC, or going through the whole IETF process) But if you use numbers from the "private use" range, you need to=20 use the Vendor ID payload. I guess the approach would be something like: - pick a vendor ID; often specs have used e.g. the MD5 hash of some unique string (like "draft-foo-05" or "http://intranet.example.com/ some/spec/" -- you don't have to tell what the string was) to avoid collisions with others. Something like a 16-byte random value would=20 work well, too. - peer A needs to send this VID to B before B can send any of the vendor-specific configuration attributes to A. Concretely,=20 (1) if the vendor-specific attribute can be included in CFG_REQUESTs (usually they can), the VPN gateway needs to=20 include this VID in IKE_SA_INIT response. (2) the client needs to include this VID either in the =20 IKE_SA_INIT request or 1st IKE_AUTH request (latter is=20 probably preferred) - pick random number(s) from the "private use" range (16384-32767) for your configuration attributes. Best regards, Pasi (not wearing any hats) -----Original Message----- > From: Alper Yegin > Sent: 11 March, 2010 18:51 > To: 'ipsec' > Subject: [IPsec] IKEv2 vendor-specific payload >=20 > Hello, >=20 > What is the recommended approach for defining vendor-specific > configuration payload with IKEv2? > > According to my reading of RFC 4306, there is a bit of a room > there. Vendor ID payload is not mandatory to use in such a case. And > even when it is used, the VID can be anything (there is no mandate > for using Enterprise ID, or anything that is globally managed). > > Other protocols I'm familiar with are more strict about defining > vendor-specific options/payloads. > > So, it makes me wonder if there are some current practices that we > should use when defining new payloads. >=20 > Thank you. >=20 > Alper From Pasi.Eronen@nokia.com Mon Mar 15 05:03:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432673A6B76 for ; Mon, 15 Mar 2010 05:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.263 X-Spam-Level: X-Spam-Status: No, score=-5.263 tagged_above=-999 required=5 tests=[AWL=-1.264, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2UmERyRidgL for ; Mon, 15 Mar 2010 05:03:31 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E63AD3A67A3 for ; Mon, 15 Mar 2010 04:36:46 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2FBaP2k003122; Mon, 15 Mar 2010 13:36:43 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 13:36:29 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 13:36:28 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 13:36:24 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 15 Mar 2010 12:36:16 +0100 From: To: , Date: Mon, 15 Mar 2010 12:36:15 +0100 Thread-Topic: Response to Pasi's AD comments on the roadmap draft Thread-Index: AQHKvuqB0s+eXspKVkaiyQLdLNk5WZHy3v6Q Message-ID: <808FD6E27AD4884E94820BC333B2DB775848477F15@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: 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 X-OriginalArrivalTime: 15 Mar 2010 11:36:24.0146 (UTC) FILETIME=[BDE07320:01CAC433] X-Nokia-AV: Clean Cc: paul.hoffman@vpnc.org Subject: Re: [IPsec] Response to Pasi's AD comments on the roadmap draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 12:03:33 -0000 Sheila Frankel wrote: > > - I'm not very happy about the use of MUST, SHOULD, etc. in this > > document. This is supposed to be a purely informational guide to > > other documents, not something that sets requirements (of any > > level) for anyone. >=20 > The only places these words are used is in re-phrasing requirements > specified in RFCs. So it doesn't set any requirements, just > re-states them. Currently, it very much reads like it's setting requirements. If we keep the 2119 keywords for algorithms, at the very least we need to say that this documnent is just repeating requirements from elsewhere, and if there's a conflict between this RFC and any other RFC, then the other RFC is takes precedence. > > For cryptographic algorithms, we already have separate documents > > that specify the requirement levels. IMHO repeating them here > > just means the two places will soon be inconsistent (which is not > > helpful for the audience here). If the WG has considered this and > > decided the repeating them here is useful, I would strongly > > suggest just having the tables in Appendix B (with explicit note > > that they're probably out of date by the time the reader finds > > them), and removing them from Section 5.x. >=20 > There is a lot of confusion in the vendor and user community about > this issue, and that is why we felt it would help to have a central > repository with this information. Obviously, any docs that come > after the roadmap could change things, but even knowing that this is > a snapshot as of a specific date is helpful - then you just have to > examine docs that come after this to see what has changed. >=20 > We feel that it is useful to state the requirements together with > the relevant RFCs, along with explanations (e.g. no RFC, no IANA #) > for those that are undefined. In addition, if new RFCs and/or IANA > #'s come along, it will be clear what is responsible for a potential > change in that algorithm's applicability. We think that the summary > table is a useful reference tool, but it's hard to read without > being able to check back to the relevant RFC requirements. >=20 > It does make sense to state, in the 2 places that we describe these > requirement levels, that this is a snapshot as of March 2010 (or a > later publication date) and is subject to change in future. > > For things other than cryptographic algorithms, I'm not sure if > > talking about "requirements levels" even makes that much > > sense. Consider, for example, Section 4.2.4.2 (IKEv2 redirect): > > > > Requirements levels for RFC5685: > > IKEv1 - N/A > > IKEv2 - optional > > > > This is not really specifying any requirement level; a phrasing > > like "This extension applies only to IKEv2, not IKEv1" would IMHO > > be more accurate. Text in most other sections (than crypto algs) > > could be rephrased similarly. >=20 > Originally, we just had req levels for algs - someone in the WG > requested that we extend it to include all of the basic IKE and > IPsec docs, the WG chairs concurred, and we added them. We would > like to see the req levels remain for the algs, but we don't feel > equally strongly about the other docs. Adding text to the RFC > descriptions would be fine. Do you have any objection to the summary > table for these docs? I don't think the summary table is really adding much for the non-algorithm documents (since it's not even using the requirement levels SHOULD/MAY/etc. that are used for algorithms). > > - Appendix B: I'm trying to match table B against RFC 4307/4835 > > and I can't quite get them to match. For example, RFC 4307 lists > > AUTH_AES_XCBC_96 as "SHOULD+", while the column "IKEv2" here says > > "optional". This suggests that perhaps even including this table > > isn't such a good idea... >=20 > RFC 4307 is a very problematic RFC. There are 2 lists of required > algorithms for IKEv2. Section 3.1.1 (Encrypted Payload Algorithms) > has 1 list, which specifies the MUST and SHOULD algs for encryption > and integrity, but does not mention AES-XCBC. > > Then there are different lists in section 3.1.3 (encryption) and > 3.1.5 (integrity). I (Sheila) had originally assumed that section > 3.1.1 pertained to IKEv2 payloads and the other sections pertained > to algorithms that IKEv2 negotiated for IPsec. The WG chairs and > others disagreed, feeling that this RFC was hastily written and > contradictory. We took section 3.1.1 to be definitive. I guess we > should explain this in the roadmap. But it's problems like this that > led us to include the requirements levels in the roadmap. I don't disagree that RFC 4307 is somewhat confusing. But if this roadmap document tries to fix the situation (rather than just describing it), it needs to update RFC 4307 (which I would prefer not to do). > > - Quite many IETF protocols use (or can use) IPsec to protect > > their traffic, so we have *lot* of RFCs that specify how to > > configure IPsec for use X (ranging from RADIUS and Diameter to > > iSCSI and TGREP). I don't think these belong in the IPsec > > document roadmap, unless they modify/extend how IPsec works > > (e.g. define new payloads/something for IKEv1/v2, or change the > > IPsec processing somehow). > > Deleting other Mobile IP and OSPF RFCs: We feel there's value in > summarizing RFCs that use IPsec, even though they don't make any > modifications. For example, in extending and/or re-defining features > of IPsec, it can be useful to see dependencies and feature use in > other protocols. We would prefer to add a statement that these RFCs > use IKE/IPsec without any modifications or extensions. I'm still wondering what's the criteria for including these particular RFCs, but not others that use IPSEC (like Diameter, RADIUS, iSCSI, TGREP, etc).... Including *some* of the Mobile IP specs (those that may change IPsec processing) certainly makes sense, but when it comes to various minor MIP extensions, what's the criteria for including these in particular, and not several other MIP extensions? > > - Section 5.x: IMHO lines like "ESP-v2 - undefined (no IANA #)" > > are a bit confusing, because ESP does not have any IANA > > registries; the registries are specific to a key management > > protocol (IKEv1, IKEv2, Photuris, KINK, HIP, ...). >=20 > Suggested new wording: "The IANA registries for IKEv1 and IKEv2 > include IANA values for various cryptographic algorithms. IKE uses > these values to negotiate IPsec SAs that will provide protection > using those algorithms. If a specific algorithm lacks a value for > IKEv1 and/or IKEv2, that algorithm's use is classified as "undefined > (no IANA #) within IPsec-v2 and/or IPsec-v3." Well, it's not necessarily undefined for ESP-v2/ESP-v3, since=20 that algorithm could still be used with manual keying (and other key management protocols than IKEv1/IKEv2). I would suggest something like "ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKEv1)". > > - Section 5.7.4: "It also includes 3 EC DH groups (groups 19-21) > > that were previously defined in [RFC4753]". The normative > > specification for groups 19-21 in IKE is still 4753/5753bis, so I > > would propose just omitting this sentence. >=20 > OK - but won't people be confused if they look at RFC 5114 and see > that there are additional groups defined there? The situation of RFC 5114 is quite confusing, I agree (because it's IMHO not totally clear whether the errata for RFC 4753 would apply to RFC 5114 too). Perhaps "It also includes 3 EC DH groups (groups 19-21) for information; however, the normative specification for these groups=20 is [4753bis]."? > > - Section 8.6 and 8.4.1 are not about IPsec, but adapting IKEv2 > > to non-IPsec uses. Perhaps these (and RFC 4705, which is missing > > from the list) should be grouped under "Non-IPsec Protocols > > Related to IKE" or something? (and Section 8.4.1 doesn't really > > belong under title "EMU"; it did not come from the EMU WG). >=20 > Section 8 is titled: "Other Protocols that use IPsec/IKE". We would > prefer to change/expand this title, rather than adding another new > major section. I do not consider 8.6 and 8.4.1 to be "protocols that use IPsec/IKE"; they're new protocols that have nothing to do with IPsec, except that they happened to borrow some of their design (like payload formats, calculations) from RFC 4306. So I don't think they belong under the same heading as rest of 8.x... Best regards, Pasi From Pasi.Eronen@nokia.com Mon Mar 15 05:10:53 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08EB13A6BD9 for ; Mon, 15 Mar 2010 05:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R20vopl3NfeR for ; Mon, 15 Mar 2010 05:10:49 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C70A43A6985 for ; Mon, 15 Mar 2010 04:42:46 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2FBghe2025223; Mon, 15 Mar 2010 13:42:50 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 13:42:42 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 13:42:42 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 15 Mar 2010 12:42:41 +0100 From: To: , Date: Mon, 15 Mar 2010 12:42:40 +0100 Thread-Topic: [IPsec] Pasi's AD comments on roadmap doc - RFCs to add/delete Thread-Index: Acq/t6FmxC2X4ya9QKiVBCBMzegk4gEfDu4Q Message-ID: <808FD6E27AD4884E94820BC333B2DB775848477F2D@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: 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 X-OriginalArrivalTime: 15 Mar 2010 11:42:42.0339 (UTC) FILETIME=[9F4C1F30:01CAC434] X-Nokia-AV: Clean Subject: Re: [IPsec] Pasi's AD comments on roadmap doc - RFCs to add/delete X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 12:10:53 -0000 Paul Hoffman wrote: > >several groups of RFCs that Pasi wants us to remove: > > > >1) RFCs that define how to configure IPsec for use in other > > protocols, but don't modify/extend how IPsec works (We would prefer > > to keep these in the roadmap): > > > > 8.1.1. RFC 4093, Problem Statement: Mobile IPv4 Traversal of > > Virtual Private Network (VPN) Gateways > > 8.1.2. RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN > > Gateways > > 8.1.5. RFC 5213, Proxy Mobile IPv6 > > 8.1.6. RFC 5268, Mobile IPv6 Fast Handovers > > 8.1.7. RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility > > Management > > 8.2.1. RFC 4552, Authentication/Confidentiality for OSPFv3 >=20 > I agree with Sheila and Suresh, and disagree with Pasi: these should > stay in the roadmap. IPsec implementers should be aware that these > other IETF protocols have specific profiles for IPsec. Well, my question was more about why list *these* particular Mobile IP protocol features, and not several MIP features, and several other protocols (Diameter, RADIUS, TGREP, iSCSI, ...) that also have specific profiles for IPsec? Best regards, Pasi From paul.hoffman@vpnc.org Mon Mar 15 07:35:21 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0523A699F for ; Mon, 15 Mar 2010 07:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84KQZQ5RD+-z for ; Mon, 15 Mar 2010 07:35:19 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 41D173A65A6 for ; Mon, 15 Mar 2010 07:35:19 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2FEZOjZ028779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Mar 2010 07:35:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775848477F15@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB775848477F15@NOK-EUMSG-01.mgdnok.nokia.com> Date: Mon, 15 Mar 2010 07:35:22 -0800 To: , , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Response to Pasi's AD comments on the roadmap draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:35:21 -0000 At 12:36 PM +0100 3/15/10, wrote: >Sheila Frankel wrote: > >> > - I'm not very happy about the use of MUST, SHOULD, etc. in this >> > document. This is supposed to be a purely informational guide to >> > other documents, not something that sets requirements (of any >> > level) for anyone. >> >> The only places these words are used is in re-phrasing requirements >> specified in RFCs. So it doesn't set any requirements, just >> re-states them. > >Currently, it very much reads like it's setting requirements. If we >keep the 2119 keywords for algorithms, at the very least we need to >say that this documnent is just repeating requirements from elsewhere, >and if there's a conflict between this RFC and any other RFC, then the >other RFC is takes precedence. Good call. This should appear in the intro, possibly as a one-paragraph subsection so that the section head stands out. > > > - Appendix B: I'm trying to match table B against RFC 4307/4835 >> > and I can't quite get them to match. For example, RFC 4307 lists >> > AUTH_AES_XCBC_96 as "SHOULD+", while the column "IKEv2" here says >> > "optional". This suggests that perhaps even including this table >> > isn't such a good idea... >> >> RFC 4307 is a very problematic RFC. There are 2 lists of required >> algorithms for IKEv2. Section 3.1.1 (Encrypted Payload Algorithms) >> has 1 list, which specifies the MUST and SHOULD algs for encryption >> and integrity, but does not mention AES-XCBC. >> >> Then there are different lists in section 3.1.3 (encryption) and >> 3.1.5 (integrity). I (Sheila) had originally assumed that section >> 3.1.1 pertained to IKEv2 payloads and the other sections pertained >> to algorithms that IKEv2 negotiated for IPsec. The WG chairs and >> others disagreed, feeling that this RFC was hastily written and >> contradictory. We took section 3.1.1 to be definitive. I guess we >> should explain this in the roadmap. But it's problems like this that >> led us to include the requirements levels in the roadmap. > >I don't disagree that RFC 4307 is somewhat confusing. But if this >roadmap document tries to fix the situation (rather than just >describing it), it needs to update RFC 4307 (which I would prefer not >to do). I agree that we don't want this document to update 4307. However, it seems appropriate for this document to highlight the confusion that 4307 causes. >I'm still wondering what's the criteria for including these particular >RFCs, but not others that use IPSEC (like Diameter, RADIUS, iSCSI, >TGREP, etc).... It's a judgement call. I don't think the real-world use of IPsec by Diameter and RADIUS is orders of magnitude smaller than that of MIP, but I could be wrong. >Including *some* of the Mobile IP specs (those that may change IPsec >processing) certainly makes sense, but when it comes to various minor >MIP extensions, what's the criteria for including these in particular, >and not several other MIP extensions? Again, it's a judgement call. It's fine to include more or fewer of these. > > > - Section 5.x: IMHO lines like "ESP-v2 - undefined (no IANA #)" >> > are a bit confusing, because ESP does not have any IANA >> > registries; the registries are specific to a key management >> > protocol (IKEv1, IKEv2, Photuris, KINK, HIP, ...). >> >> Suggested new wording: "The IANA registries for IKEv1 and IKEv2 >> include IANA values for various cryptographic algorithms. IKE uses >> these values to negotiate IPsec SAs that will provide protection >> using those algorithms. If a specific algorithm lacks a value for >> IKEv1 and/or IKEv2, that algorithm's use is classified as "undefined >> (no IANA #) within IPsec-v2 and/or IPsec-v3." > >Well, it's not necessarily undefined for ESP-v2/ESP-v3, since >that algorithm could still be used with manual keying (and other >key management protocols than IKEv1/IKEv2). > >I would suggest something like "ESP-v2 - optional (but no IANA #, so >cannot be negotiated by IKEv1)". That seems good. > > > - Section 5.7.4: "It also includes 3 EC DH groups (groups 19-21) >> > that were previously defined in [RFC4753]". The normative >> > specification for groups 19-21 in IKE is still 4753/5753bis, so I >> > would propose just omitting this sentence. >> >> OK - but won't people be confused if they look at RFC 5114 and see >> that there are additional groups defined there? > >The situation of RFC 5114 is quite confusing, I agree (because it's >IMHO not totally clear whether the errata for RFC 4753 would apply to >RFC 5114 too). > >Perhaps "It also includes 3 EC DH groups (groups 19-21) for >information; however, the normative specification for these groups >is [4753bis]."? It is inappropriate for this document to say what the normative specification for another document is, particularly one that is as confusing as RFC 5114. > > > - Section 8.6 and 8.4.1 are not about IPsec, but adapting IKEv2 >> > to non-IPsec uses. Perhaps these (and RFC 4705, which is missing >> > from the list) should be grouped under "Non-IPsec Protocols >> > Related to IKE" or something? (and Section 8.4.1 doesn't really >> > belong under title "EMU"; it did not come from the EMU WG). >> >> Section 8 is titled: "Other Protocols that use IPsec/IKE". We would >> prefer to change/expand this title, rather than adding another new >> major section. > >I do not consider 8.6 and 8.4.1 to be "protocols that use IPsec/IKE"; >they're new protocols that have nothing to do with IPsec, except that >they happened to borrow some of their design (like payload formats, >calculations) from RFC 4306. > >So I don't think they belong under the same heading as rest of 8.x... It is easy to add another section. --Paul Hoffman, Director --VPN Consortium From yaronf.ietf@gmail.com Tue Mar 16 03:09:45 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310B13A68A2 for ; Tue, 16 Mar 2010 03:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ-xBQClpuSb for ; Tue, 16 Mar 2010 03:09:44 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id D35703A68FA for ; Tue, 16 Mar 2010 03:09:43 -0700 (PDT) Received: by fxm5 with SMTP id 5so4357715fxm.29 for ; Tue, 16 Mar 2010 03:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=hVtgh8OsUaRAOa+9ykzym0N1YVfb9YBqpFlYUu+ntzU=; b=T6lzWH6fSpbz1NYxaE1tdKthyY3Du3Dx6j4x841XGNQVjExqp4RqF3w+pREerZh7Lv s+npJUWgCtmqjPMz6Yur080K7K65vZA6j3VfIWmxdbEm2JeNDPlGzJRzMJQSMaL9u7BH +5li44CFBlDvLLlFNOWDX+YnCIefdlYM6UuHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=CNhjz7GUaUixWp4tEgUbocQHUL6YnHXY/nZNEk0+SiXJol/Dykqqdwbsah/YegpvBZ 5q8/ZzCbm4WCrN7UBw19vnaeV6rg9cC13tlWup4DQXxqeElpwNj426T0270Z5A1pe6KV FTZRWbj8lj29wx+OgFP2yWFy7NTz5P9pb6bjs= Received: by 10.223.1.130 with SMTP id 2mr2576018faf.84.1268734188972; Tue, 16 Mar 2010 03:09:48 -0700 (PDT) Received: from [10.20.30.8] ([62.219.129.160]) by mx.google.com with ESMTPS id 13sm3786907fxm.14.2010.03.16.03.09.48 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Mar 2010 03:09:48 -0700 (PDT) Message-ID: <4B9F58FE.1060900@gmail.com> Date: Tue, 16 Mar 2010 12:10:06 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] New email address X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 10:10:48 -0000 Hi everyone, I am leaving Check Point within the next few weeks. For the time being, I will be using this address: yaronf.ietf@gmail.com. Unfortunately I will not be coming to Anaheim next week, instead I will make the best of the WebEx facilities. Wishing you all a good meeting in sunny California! Thanks, Yaron From Pasi.Eronen@nokia.com Tue Mar 16 05:39:10 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708FA3A67D6 for ; Tue, 16 Mar 2010 05:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV--c22uGLWt for ; Tue, 16 Mar 2010 05:39:09 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E66133A6A56 for ; Tue, 16 Mar 2010 05:39:04 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2GCd7Bi029297; Tue, 16 Mar 2010 14:39:09 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 14:38:24 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 14:38:19 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 14:38:10 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 16 Mar 2010 13:38:09 +0100 From: To: , , Date: Tue, 16 Mar 2010 13:38:08 +0100 Thread-Topic: [IPsec] Response to Pasi's AD comments on the roadmap draft Thread-Index: AcrETM1U5R26rYKoThqG1zlRBDCxJwAuGj+g Message-ID: <808FD6E27AD4884E94820BC333B2DB775848478AFD@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB775848477F15@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: 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 X-OriginalArrivalTime: 16 Mar 2010 12:38:10.0794 (UTC) FILETIME=[899FCCA0:01CAC505] X-Nokia-AV: Clean Subject: Re: [IPsec] Response to Pasi's AD comments on the roadmap draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 12:39:10 -0000 Paul Hoffman wrote: > > > > - Section 5.7.4: "It also includes 3 EC DH groups (groups 19-21) > >> > that were previously defined in [RFC4753]". The normative > >> > specification for groups 19-21 in IKE is still 4753/5753bis, so I > >> > would propose just omitting this sentence. > >> > >> OK - but won't people be confused if they look at RFC 5114 and see > >> that there are additional groups defined there? > > > >The situation of RFC 5114 is quite confusing, I agree (because it's > >IMHO not totally clear whether the errata for RFC 4753 would apply to > >RFC 5114 too). > > > >Perhaps "It also includes 3 EC DH groups (groups 19-21) for > >information; however, the normative specification for these groups > >is [4753bis]."? >=20 > It is inappropriate for this document to say what the normative > specification for another document is, particularly one that is as > confusing as RFC 5114. Assuming 4753bis gets approved by IESG before the roadmap (which seems very likely), I think we can say this. Or perhaps we could say "current" instead "normative"? "RFC 5114 also included 3 EC DH groups (groups 19-21) that were originally defined in [RFC4753]; however, the current specification for these groups is [4753bis]". Best regards, Pasi From paul.hoffman@vpnc.org Tue Mar 16 07:52:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63BB3A6A2E for ; Tue, 16 Mar 2010 07:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk7EVVBZ+OD1 for ; Tue, 16 Mar 2010 07:52:29 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 358D83A6996 for ; Tue, 16 Mar 2010 07:52:25 -0700 (PDT) Received: from [10.20.30.163] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2GEdZH1021560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 07:39:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775848478AFD@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB775848477F15@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB775848478AFD@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 16 Mar 2010 07:39:35 -0700 To: , , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Response to Pasi's AD comments on the roadmap draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 14:52:30 -0000 At 1:38 PM +0100 3/16/10, wrote: >Paul Hoffman wrote: > >> > > > - Section 5.7.4: "It also includes 3 EC DH groups (groups 19-21) >> >> > that were previously defined in [RFC4753]". The normative >> >> > specification for groups 19-21 in IKE is still 4753/5753bis, so I >> >> > would propose just omitting this sentence. >> >> >> >> OK - but won't people be confused if they look at RFC 5114 and see >> >> that there are additional groups defined there? >> > >> >The situation of RFC 5114 is quite confusing, I agree (because it's >> >IMHO not totally clear whether the errata for RFC 4753 would apply to >> >RFC 5114 too). >> > >> >Perhaps "It also includes 3 EC DH groups (groups 19-21) for >> >information; however, the normative specification for these groups >> >is [4753bis]."? >> >> It is inappropriate for this document to say what the normative >> specification for another document is, particularly one that is as >> confusing as RFC 5114. > >Assuming 4753bis gets approved by IESG before the roadmap (which seems >very likely), I think we can say this. Or perhaps we could >say "current" instead "normative"? > > "RFC 5114 also included 3 EC DH groups (groups 19-21) that were > originally defined in [RFC4753]; however, the current specification > for these groups is [4753bis]". That works for me. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Mar 16 10:22:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4173A6816 for ; Tue, 16 Mar 2010 10:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.664 X-Spam-Level: X-Spam-Status: No, score=-4.664 tagged_above=-999 required=5 tests=[AWL=-1.032, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEMy4AEWfKWO for ; Tue, 16 Mar 2010 10:22:25 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B5D133A6A42 for ; Tue, 16 Mar 2010 10:22:24 -0700 (PDT) Received: from [10.20.30.163] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2GGqrTw030915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Mar 2010 09:52:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100302213439.GJ11824@kebe.East.Sun.COM> References: <20100302213439.GJ11824@kebe.East.Sun.COM> Date: Tue, 16 Mar 2010 09:52:51 -0700 To: Dan McDonald , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Still incorrect understanding of PF_KEY in ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 17:22:29 -0000 [[ This message has gotten no replies. I am far from a PF_KEY expert, and need to hear from the WG before proceeding. --Paul Hoffman ]] At 4:34 PM -0500 3/2/10, Dan McDonald wrote: >Even as of draft-08, section 2.9: > > When an RFC4301-compliant IPsec subsystem receives an IP packet that > matches a "protect" selector in its Security Policy Database (SPD), > the subsystem protects that packet with IPsec. When no SA exists > yet, it is the task of IKE to create it. Maintenance of a system's > SPD is outside the scope of IKE (see [PFKEY] for an example > programming interface, although it only applies to IKEv1), though > some implementations might update their SPD in connection with the > running of IKE (for an example scenario, see Section 1.1.3). > >is entirely incorrect about PF_KEY. > >PF_KEY maintains the SADB and expresses the SPD and/or triggering packet when >IPsec requires a new outbound SA. Some PF_KEY extensions (notably in any >KAME/WIDE-derived implementations) also maintain the SPD. And it certainly >is not applicable to just IKEv1 - it was intended to allow an ARBITRARY Key >Management daemon to add/delete/etc. SAs. The PF_KEY SADB_ACQUIRE message is >an expression of the SPD entry for the packet. > >So as not to just be a whiner, I will provide a replacement first two >paragraphs: > > When an RFC4301-compliant IPsec subsystem receives an IP packet that > matches a "protect" selector in its Security Policy Database (SPD), the > subsystem protects that packet with IPsec. When no SA exists yet, it is > the task of IKE to create it. Maintenance of a system's SPD is outside > the scope of IKE, though some implementations might update their SPD in > connection with the running of IKE (for an example scenario, see Section > 1.1.3). > > Traffic Selector (TS) payloads allow endpoints to communicate some of the > information from their SPD to their peers. These must be communicated to > IKE from the SPD (for example the PF_KEY API [PFKEY] uses the SADB_ACQUIRE > message). TS payloads specify the selection criteria for packets that > will be forwarded over the newly set up SA. This can serve as a > consistency check in some scenarios to assure that the SPDs are > consistent. In others, it guides the dynamic update of the SPD. > >Thanks, >Dan >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From Pasi.Eronen@nokia.com Wed Mar 17 01:21:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3ED23A63C9 for ; Wed, 17 Mar 2010 01:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6+ciJh5+0eI for ; Wed, 17 Mar 2010 01:21:24 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 322333A691B for ; Wed, 17 Mar 2010 01:20:56 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2H8KauP029966; Wed, 17 Mar 2010 10:21:02 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 10:20:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 10:20:40 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 17 Mar 2010 09:20:39 +0100 From: To: , , Date: Wed, 17 Mar 2010 09:20:37 +0100 Thread-Topic: [IPsec] Still incorrect understanding of PF_KEY in ikev2bis-08 Thread-Index: AcrFLXvFUJgMvPKYTQWoROZdFbAW4gAfSewA Message-ID: <808FD6E27AD4884E94820BC333B2DB7758484CF315@NOK-EUMSG-01.mgdnok.nokia.com> References: <20100302213439.GJ11824@kebe.East.Sun.COM> In-Reply-To: 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 X-OriginalArrivalTime: 17 Mar 2010 08:20:40.0175 (UTC) FILETIME=[BAC02FF0:01CAC5AA] X-Nokia-AV: Clean Subject: Re: [IPsec] Still incorrect understanding of PF_KEY in ikev2bis-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 08:21:28 -0000 I think the text proposed by Dan is OK (and it's more accurate about PF_KEY than the current text in -08). Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of ext Paul Hoffman > Sent: 16 March, 2010 18:53 > To: Dan McDonald; ipsec@ietf.org > Subject: Re: [IPsec] Still incorrect understanding of PF_KEY in > ikev2bis-08 >=20 > [[ This message has gotten no replies. I am far from a PF_KEY expert, > and need to hear from the WG before proceeding. --Paul Hoffman ]] >=20 > At 4:34 PM -0500 3/2/10, Dan McDonald wrote: > >Even as of draft-08, section 2.9: > > > > When an RFC4301-compliant IPsec subsystem receives an IP packet > that > > matches a "protect" selector in its Security Policy Database (SPD), > > the subsystem protects that packet with IPsec. When no SA exists > > yet, it is the task of IKE to create it. Maintenance of a system's > > SPD is outside the scope of IKE (see [PFKEY] for an example > > programming interface, although it only applies to IKEv1), though > > some implementations might update their SPD in connection with the > > running of IKE (for an example scenario, see Section 1.1.3). > > > >is entirely incorrect about PF_KEY. > > > >PF_KEY maintains the SADB and expresses the SPD and/or triggering > packet when > >IPsec requires a new outbound SA. Some PF_KEY extensions (notably in > any > >KAME/WIDE-derived implementations) also maintain the SPD. And it > certainly > >is not applicable to just IKEv1 - it was intended to allow an > ARBITRARY Key > >Management daemon to add/delete/etc. SAs. The PF_KEY SADB_ACQUIRE > message is > >an expression of the SPD entry for the packet. > > > >So as not to just be a whiner, I will provide a replacement first two > >paragraphs: > > > > When an RFC4301-compliant IPsec subsystem receives an IP packet > that > > matches a "protect" selector in its Security Policy Database (SPD), > the > > subsystem protects that packet with IPsec. When no SA exists yet, > it is > > the task of IKE to create it. Maintenance of a system's SPD is > outside > > the scope of IKE, though some implementations might update their > SPD in > > connection with the running of IKE (for an example scenario, see > Section > > 1.1.3). > > > > Traffic Selector (TS) payloads allow endpoints to communicate some > of the > > information from their SPD to their peers. These must be > communicated to > > IKE from the SPD (for example the PF_KEY API [PFKEY] uses the > SADB_ACQUIRE > > message). TS payloads specify the selection criteria for packets > that > > will be forwarded over the newly set up SA. This can serve as a > > consistency check in some scenarios to assure that the SPDs are > > consistent. In others, it guides the dynamic update of the SPD. > > > >Thanks, > >Dan > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Wed Mar 17 07:04:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9D13A6903 for ; Wed, 17 Mar 2010 07:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ylk-94H6J-b for ; Wed, 17 Mar 2010 07:04:28 -0700 (PDT) Received: from mail-fx0-f179.google.com (mail-fx0-f179.google.com [209.85.220.179]) by core3.amsl.com (Postfix) with ESMTP id 576983A6C2B for ; Wed, 17 Mar 2010 07:03:57 -0700 (PDT) Received: by fxm27 with SMTP id 27so240895fxm.9 for ; Wed, 17 Mar 2010 07:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=B96AaWiQ3V95y9El4F0IuLYNBt+m1UtZVfn6ClurLeo=; b=Zd2owcDKfGHnvQkjBTch2OZACL5DASjzHtdMrs1MDwGoG6nZT0hM+cSfepuq5aMDHk rPl09Z4m0F06Zm0PDAD+VI2qoBnGRh4RzjmGz2MexEMgzjbQXjGV2h91ZkWWy261D38Y +4kXLHb4IwcIDDytHp6qCCEmninaAC6wAKnvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=mzHMrzRpkTwNyvQKOKq16kq16Pc2b0Bu1mdZCTtn2e55eVhhqH64RzO2O86BQla0/Z oV87g6mjQ9ZkOgIr4yRi9VKENtdzORnzH0/d0toQFsCm4Jro9yRWKUv3FzbaZVyJu1r7 JX1GWEpZWRJgs2PUNK9J4qGlDLgvTMu8Z4MPk= Received: by 10.87.47.32 with SMTP id z32mr2008356fgj.36.1268834643620; Wed, 17 Mar 2010 07:04:03 -0700 (PDT) Received: from [10.20.30.6] ([62.219.129.160]) by mx.google.com with ESMTPS id d8sm1730755fga.5.2010.03.17.07.04.02 (version=SSLv3 cipher=RC4-MD5); Wed, 17 Mar 2010 07:04:02 -0700 (PDT) Message-ID: <4BA0E166.3070901@gmail.com> Date: Wed, 17 Mar 2010 16:04:22 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] HUSH protocol: an EKE-based password authentication mode for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 14:04:30 -0000 Hi, [WG chair hat off] I just published a draft proposing a new IKEv2 authentication mode using EKE on our wiki, at http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs I will submit the draft as an I-D early next week, when the submission window reopens. In the meantime, any comments are welcome. Note that the Anaheim discussion will cover selection criteria of password authentication protocols. We will attempt to focus on these criteria, rather than on discussing any individual protocol, including this one. Thanks, Yaron From paul.hoffman@vpnc.org Thu Mar 18 16:38:08 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCEA3A6A4B for ; Thu, 18 Mar 2010 16:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.212 X-Spam-Level: X-Spam-Status: No, score=-5.212 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMVyHj9HX3Y5 for ; Thu, 18 Mar 2010 16:38:08 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DEFAC3A6954 for ; Thu, 18 Mar 2010 16:38:06 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2INcGTk096292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Mar 2010 16:38:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 18 Mar 2010 16:38:15 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Secure crash recovery comparison X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 23:38:08 -0000 Greetings again. A few years ago, Yoav Nir started an informal Wiki page comparing secure crash recovery proposals. He has updated the page to cover the two items in our charter. We will be discussing these at the meeting on Monday; please read the comparison before then. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Thu Mar 18 19:17:47 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318113A6855 for ; Thu, 18 Mar 2010 19:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.907 X-Spam-Level: X-Spam-Status: No, score=-4.907 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOEGVwP+gPzG for ; Thu, 18 Mar 2010 19:17:43 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DB6CC3A68E8 for ; Thu, 18 Mar 2010 19:17:41 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2J2Hqkh004543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Mar 2010 19:17:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 18 Mar 2010 19:17:50 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2bis (Internet Key Exchange Protocol: IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 02:17:47 -0000 The IETF Last Call on IKEv2bis is now over (but comments are still welcome). I have made the following changes to the draft. I'll turn in the draft on Monday after the face-to-face meeting, and our new AD will then put it on a future IESG telechat. You'll have plenty of time to review the diffs before that telechat so you can tell me if I muffed anything. Thanks again for all the input! --Paul Hoffman D.16. Changes from draft-ietf-ipsecme-ikev2bis-08 to draft-ietf-ipsecme-ikev2bis-09 These changes came during IETF Last Call. Fixed some minor editorial nits. In 1.3, changed "this notify" to "this notification". In 2.6, changed "will cause two packets:" to "will cause two packets to be sent:". Moved the paragraph that starts "When the IKE_SA_INIT exchange does not result" from 2.7 to 2.6. Also changed"the responder's SPI will be zero" to "the responder's SPI will be zero also in the response message". In 2.8.2, last paragraph: Change the beginning of the sentence and changed "older peers may receive these notifications" to "older peers that implement RFC 4306 but not this document may receive these notifications". Fixed the first two paragraphs of 2.9 to talk about PFKEY in the correct context. In 2.23, clarified the paragraph that starts "An initiator can use..." in many places, saying that it is UDP encapsulated ESP. In 3.3.6, changed "If one of the proposals offered is for the Diffie- Hellman group of NONE, the responder MUST ignore the initiator's KE payload and omit the KE payload from the response" to "If one of the proposals offered is for the Diffie-Hellman group of NONE, and the responder selects that Diffie-Hellman group, then it MUST ignore the initiator's KE payload and omit the KE payload from the response". [Issue #176] In 3.5, changed "IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP addresses" to "IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for IP addresses". From paul.hoffman@vpnc.org Fri Mar 19 09:26:53 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FEFA3A69A6 for ; Fri, 19 Mar 2010 09:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.186 X-Spam-Level: X-Spam-Status: No, score=-5.186 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYyHL7TNmeXg for ; Fri, 19 Mar 2010 09:26:51 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DD8AB3A67F0 for ; Fri, 19 Mar 2010 09:26:50 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2JGR1bd054988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Mar 2010 09:27:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 19 Mar 2010 09:27:01 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Fwd: Gen-art review of draft-ietf-ipsecme-ikev2bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 16:26:53 -0000 Sooooo, you can ignore my message from last night. These comments need to be dealt with. I have already replied to Elwyn about the "major" issue, but need to plow through the minor issues and nits. Given travel to the meeting, I doubt I'll have a new draft on Monday as planned, but some of these definitely need WG discussion. --Paul Hoffman >Date: Fri, 19 Mar 2010 14:37:19 +0000 >From: Elwyn Davies >To: General Area Review Team >CC: Mary Barnes , > draft-ietf-ipsecme-ikev2bis.all@tools.ietf.org, > IETF Discussion >X-SA-Exim-Connect-IP: 2001:8b0:0:30::51bb:1e34 >X-SA-Exim-Rcpt-To: draft-ietf-ipsecme-ikev2bis.all@tools.ietf.org >X-SA-Exim-Mail-From: elwynd@dial.pipex.com >X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on > merlot.tools.ietf.org >X-Spam-Level: >X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=no > version=3.3.0 >Subject: Gen-art review of draft-ietf-ipsecme-ikev2bis-08.txt >X-SA-Exim-Version: 4.2.1 (built Sat, 01 Aug 2009 12:09:26 +0000) >X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) > >I have been selected as the General Area Review Team (Gen-ART) >reviewer for this draft (for background on Gen-ART, please see >http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >Please resolve these comments along with any other Last Call comments >you may receive. > >Document: draft-ietf-ipsecme-ikev2bis-08.txt >Reviewer: Elwyn Davies >Review Date: 18 March 2010 >IETF LC End Date: 18 March 2010 >IESG Telechat date: (if known) - > >Summary: >Not ready. The document contains a lot of minor niggles and nits plus a major item that I am not sure the IETF should support: this is the removal of all mention of mandatory to implement security suites from the document. I appreciate the difficulty of keeping up to the minute, but it seems to me that this is outweighed by the difficulty of guaranteeing interoperability. If the security landscape is so unstable, we have a bigger problem perhaps. Whether this change is acceptable to the IAB, the IESG and the wider IETF is not something I can resolve. > >One niggle that I felt represented a rather lackadaisical approach, was the retaining of the publication date of RFC 4306 as a frozen point in time for the purpose of documenting the state of the world as regards lists of configurable lists. I would have preferred the losts to be up to date at the publication of *this* RFC. > >There are also a number of relatively minor points where items and processes are explicitly not fully specified. Thus could lead to annoying corners where implementations are totally interoperable (e.g., what is the complete set of 'terminators' forbidden in IP_FQDNs? What is an acceptable 'sort of' email address/NAI on EAP?) > >Finally there are a number of points where it is recommended that network traffic needs to be limited but no concrete guidelines are given. I think that some sort of suggestions for the parameters to be applied (e.g., time constants, number of repeats, backoff algorithm) would be desirable. > >Major issues: > >s3.3.4: The draft states that the list of mandatory to implement suites has been removed due to evolution going too fast. Is this acceptable? > >Minor issues: >s1: At para 6 in s1 the draft states: >> The first request/response of an IKE session (IKE_SA_INIT) negotiates >> security parameters for the IKE SA, sends nonces, and sends Diffie- >> Hellman values. >As a (not really) naive reader, I asked myself 'Why does this text suddenly mention that we need to send nonces and Diffie-Hellman values?' Looking back at the text so far I realized that the text has not introduced the techniques that it is going to use to establish the authenticated IKE channel etc. It is assumed that readers know that as soon as D-H is mentioned we are talking public key cryptography. A paragraph explaining the underlying ideas would be useful. > >s1.2, last para: >> Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. >> Thus, the SA payloads in the IKE_AUTH exchange cannot contain >> Transform Type 4 (Diffie-Hellman Group) with any value other than >> NONE. Implementations SHOULD omit the whole transform substructure >> instead of sending value NONE. >Does 'cannot contain' conflict with the 'SHOULD'? I am unclear what an implementer would do if s/he chose to do otherwise than omit the transform structure in the light of the previous statement. > >s2.1, last sentence: >> The retransmission policy for one-way messages is somewhat different >> from that for regular messages. Because no acknowledgement is ever >> sent, there is no reason to gratuitously retransmit one-way messages. >> Given that all these messages are errors, it makes sense to send them >> only once per "offending" packet, and only retransmit if further >> offending packets are received. Still, it also makes sense to limit >> retransmissions of such error messages. >Does this need to be more precise? Some explicit policy for restricting retransmissions? Possibly in s2.21.4. > >s2.2: Maybe should mention that retransmissions MUST use the same Message ID. > >s2.3: Should there be some discussion of the interaction of rekeying of the IKE_SA and windows? Presumably a rekey message should not be actioned until all previous messages have been responded to. Likewise receiving a Message ID with a sequence number bigger than that in the rekey message should be very suspect! Should the INVALID_MESSAGE_ID notification be sent in this case (and before or after the rekey?) There might be some knock on into s2.8 where rekeying is discussed. And maybe into s2.25? > >s2.4, para 2: >> The INITIAL_CONTACT notification, if sent, MUST >> be in the first IKE_AUTH request or response, not as a separate >> exchange afterwards; receiving parties MAY ignore it in other >> messages. >What should receiving parties do if they *do* receive it and *don't* ignore it? >Since it 'MUST be sent in the first IKE_AUTH' receiving at any other time is a protocol error and should cause some response (like dropping the IKE_SA perhaps). > >s2.4, para 4: >> Note >> that this places requirements on the failure modes of an IKE >> endpoint. An implementation MUST NOT continue sending on any SA if >> some failure prevents it from receiving on all of the associated SAs. >> If Child SAs can fail independently from one another without the >> associated IKE SA being able to send a delete message, then they MUST >> be negotiated by separate IKE SAs. >I am fairly certain that is impossible for any implementation to guarantee the MUST NOT here. How does it absolutely know that it isn't able to receive anything? Absence of activity might mean failure or idleness. I *think* this is not just talking about IKE SAs but includes the Child SAs. This appears to imply that the Child SAs all have to be usable bidirectionally and have keepalives on them? And that IKE should know about the keepalives. > >What is the second condition saying? Does this impose some constraints on the use of Child SA deletion.. like that the IKE SA must support Child SA deletion? or is it just saying that if the IKE SA has failed you can't leave some Child SAs active (as implied by the next para)? The more I think about this the more confused I become! > >s2.6, next to last para: >> The initiator should limit the number of cookie exchanges it >> tries before giving up. >Does anything need to be said abut exponential back-off? > >ss1.7/2.8: >The changes documented in s1.7 state: >> In 2.8, changed "Note that, when rekeying, the new Child SA MAY have >> different traffic selectors and algorithms than the old one" to "Note >> that, when rekeying, the new Child SA SHOULD NOT have different >> traffic selectors and algorithms than the old one". >This refers to para 3 of s2.8. Is the SHOULD NOT just there to cope with existing implementations? This is a binary choice - either they are the same or they aren't. If MAY is no good, I can't see that allowing the opposite choice at all makes any sense. I would argue that this ought to be MUST NOT. > >s2.8.1, para 2: The use of 'lexicographical' in the comparison algorithm adds confusion IMO. It implies that there is some language related total ordering on the values stored in each octet that might or might not be the natural integer ordering. Presumably the intent is that corresponding octets should be treated as 8 bit unsigned integers (in network bit order?) and compared as such. > >s2.15, definition of signed octets (both cases): What 'Length' is intended? And how should it be represented as a string for concatenation? Are the definitions of Nonce[IR]Payload intended to show how Nonce[IR]Data are derived ? They are not otherwise used. Similarly xxxIDPayload? How many octets of what value make up 'RESERVED' (or is it just the literal text? > >s2.21.2, last sentence: How would the peer expect to demonstrate understanding of extended error notifications? Protocol version number? NOTIFY payload? > >s2.21.4: More requests to limit message rates without specific means. > >s2.23, para 7 and 8 (first bullet point): I understood from earlier that the first requirement (port 4500 and responding to source address/port) applied to *all* implementations and not just those specifically supporting NAT traversal. > >s2.23: Should there be a discussion of NAT64? > >s3.1, Major Version: This definition is not entirely consistent with the major version support discussion earlier in the document. It should probably talk about implementations that support this version of the specification or any subsequent version that uses s higher version number. Reference back to s2.5 would be useful. This applies to the Minor Version also. > >s3.3.5, Key Length attribute: >> o The Key Length attribute MUST NOT be used with transforms that use >> a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and >> all the Type 2 (Pseudo-random function) and Type 3 (Integrity >> Algorithm) transforms specified in this document. It is >> recommended that future Type 2 or 3 transforms do not use this >> attribute. >I think the recommended is a RECOMMENDED here. > >s3.5, Identification Field table: The class of 'terminators' is not fully defined. > >s3.5, IP_FQDN: The specification refers to IDNA - does IDNAbis have any impact here? > >s3.5, last para: >> Responder implementations should not attempt to >> verify that the contents actually conform to the exact syntax given >> in [MAILFORMAT], but instead should accept any reasonable-looking >> NAI. >How do I verify conformance to this statement please? > >s3.6, next to last para: 'also MUST be capable of being configured to send and accept the two Hash and URL formats (with HTTP URLs).' > ^^^^^^^^^^^^^^^^^^^^^^^^ >Only one format appears to be defined in this section. Is there another somewhere else? > >s3.12: >> Writers of Internet-Drafts who wish to extend this protocol MUST >> define a Vendor ID payload to announce the ability to implement the >> extension in the Internet-Draft. It is expected that Internet-Drafts >> that gain acceptance and are standardized will be given "magic >> numbers" out of the Future Use range by IANA, and the requirement to >> use a Vendor ID will go away. >> >I don't understand this paragraph. I suspect I need to eat some magic mushrooms in order to be able to see the magic numbers. Can I recommend swapping over the payload identification numbers with the Delete payload so that Vendor ID is #42? But seriously, this doesn't seem to be the way we should go about standardizing an extension. > >s8.2 [AEAD]: I think the reference in s3.14 makes this normative. >s8.2 [MAILFORMAT]: I think the statements in s3.5 make this normative. > > > >============================================ > >Nits/editorial comments: >General: The version of the draft in the repository is unpaginated. > >General: The notation used for concatenation ('|'), raising to the power ('^'), etc could be usefully defined early on in one place. > >s1, para 4: >> The pair is called an "exchange". We call the first >> messages establishing an IKE SA IKE_SA_INIT and IKE_AUTH exchanges >> and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL > > exchanges. >The start of the second sentence is confusing on a quick read: A better form might be: > We call the first exchanges of messages that establish an IKE SA IKE_SA_INIT and IKE_AUTH and subsequent IKE... > >s1.2 (conventions): The use of [] to denote optional items in exchanges can be confusing with references. But we will probably have to live with it. > >s1.2 >> The keys used for the >> encryption and integrity protection are derived from SKEYSEED and are >I assume *how* the derivation is done is described later (I think sa2.13/2.14 is the right answer). A forward reference would help - both to show that you shouldn't worry about how just now and to point to where it is defined. > >s1.3, para 3: the first sentence is redundant - it was said in para 1. > > >s1.3: The section would be clearer if the last para was moved to be immediately after para 4 (the last para describes how and why the MAY in para 4 occurs). It would also help to change the order of the sentences in the last para, making the last sentence first. > >s1.3.1: The term Message ID has not been discussed on defined before its appearance here. > >s1.5, para 5: the last sentence >> The Initiator >> flag is set, the Response bit is set to 0, and the version flags are >> set in the normal fashion. >can be omitted from the general introduction here - the various items referred to in the sentence have not been introduced at this point in the document. > >s1.5, last para: The previous comment applies to the last sentence here also. > >s2, para 1: There should be references for the port number definitions 500 is in RFC 2408 and 4500 is in RFC 3947. Arguably port 500 should be reassigned to IKE by the IKE standards since ISAKMP is no longer a well-known protocol. > >s2.9, last para: I believe the 'SHOULD narrow' ought to be 'should narrow'. This is is not something the protocol controls. > >s2.13, para 2: HMAC needs a reference. > >s2.13, para 3: I think the statement 'The preferred key size is used as the length..' ought to be strengthened to 'The preferred key size MUST be used as the length..'. > >s2.14, para 1: A reference back to Section 2.13 for the key length discussion would be useful. > >s2.15, para 1: IDr' is defined twice - once on its own and once in concert with IDi'. > >s2.17, para 7: the term ROHC_INTEG is not defined - it almost certainly needs a reference. > >s2.17, last bullet: s/protocol specification/the protocol specification/, > s/For ESP and/For ESP and/ > >s2.20, para 2: Is the term 'trolling' sufficiently well-known not to need definition? > >s2.22: The IPCOMP algorithm table ought to be updated to the date of publication of this draft as an RFC - note to RFC Editor. > >s2.23, para 2: The term 'real Internet' is not well defined. The pejorative language in para 1 and here is unhelpful. > >s2.23, para 6: How is IPsec expected to 'discover' a NAT? (it appears that I am told a few paras later, but it isn't obvious that that is the case here!) > >s2.23, bullet point 7: 'these payloads'? Which payloads are they? > >s2.23.1, para 5: This is the first 'real' use of PAD (as opposed to in the list of changes) - it would be useful to expand it and put in a forward reference. > >s2.23.1: There are several missing definite articles in this section. > >s2.23.1, para 11: s/known NATs outer addresses/known NAT's outer addresses/ > >s3.1, Exchange Type: This should be updated to refer to the current document. AFAICS the table of exchange types is still valid as of today. There are several subsequent instances of the same issue. > >s3.1, Response Flag: s2.21.2 has a (sort of) exception to the 'no response to a response rule'. > >s3.1, Message ID and Length: Should be specified as unsigned integers. > >s3.2: The table of payload type identifiers could usefully have a forward reference to the section number where it is defined. > >s3.2, Payload length: Should be specified as unsigned integers. there are many other cases - it could be conveniently resolved by a global statement added to the byte ordering statement. > >s3.2, last para: 'Many payloads contain fields marked as "RESERVED".' So what? (well they should be treated just like you said two paras before, presumably!). > >s3.3, para 1: :-) 'Assembly of Security Association Payloads requires great peace of mind.' Hence any implementation must be capable of passing the Turing Test?????? > >s3.3, 'Proposal #': The usage of # as shorthand for number is US specific jargon and should be defined. This issue also occurs in '# of transforms' in s3.3.1. > >s3.3 onwards, last para: Repeating the payload type number here makes for a double maintenance problem and isn't useful within the payload. > >s3.3.1, SPI Size: 'the SPI is obtained from the outer header': What does 'outer' mean here? > >s3.5, para after ID Field types table: 'Implementations SHOULD be capable of generating and accepting all of these types.' Does 'all' here mean the four types in the previous sentence or 'all' the types in the full table? > >s3.5, para after ID Field types table: 'IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP addresses.' s/ID_IPV6_ADDR instead of ID_IPV6_ADDR/ID_IPV6_ADDR instead of ID_IPV4_ADDR/ > >s3.6: Probably needs a reference for ASN.1 specification. > >s3.9, last para: s/The size the/The size of the/ > >s3.16, para 1: 'The full set of acceptable values for the payload is defined elsewhere,' Where is not specified, but maybe RFC 3748. It should be explicitly stated that Type and Type_data are taken from RFC 3748 (and maybe other documents). > >s4, para 2: 'There are a series of optional features that can easily be ignored by a particular implementation if it does not support that feature.' I found this hard to parse. I *think* it is saying that the following list of features are ones that are prime candidates for omission from minimal implementations. How about: 'The following features are a selection of those that can be omitted from a minimal implementation while leaving it capable of interoperating satisfactorily with others:' > >s7, last para: Most of the references here could be usefully attached to some of the tables in s3 where the relevant specifications are called out. This would be both useful and resolve the xml2rfc nit. > >Appendix B, para 2: >> The strength supplied by group one may not be sufficient for the >> mandatory-to-implement encryption algorithm and is here for historic >> reasons. >There are no longer any mandatory to implement encryption algorithms (at present), so this statement needs to be revised. From narten@us.ibm.com Fri Mar 19 12:02:27 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA72C3A6929 for ; Fri, 19 Mar 2010 12:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJsP0ozXohDO for ; Fri, 19 Mar 2010 12:02:26 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id CCE153A68C6 for ; Fri, 19 Mar 2010 12:02:26 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o2JIsaFT007799 for ; Fri, 19 Mar 2010 12:54:36 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o2JJ2SKg038954 for ; Fri, 19 Mar 2010 13:02:29 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o2JJ4vP6015352 for ; Fri, 19 Mar 2010 13:04:57 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-76-142-160.mts.ibm.com [9.76.142.160]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o2JJ4udm015308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Mar 2010 13:04:57 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id o2JJ2Qig025943; Fri, 19 Mar 2010 15:02:26 -0400 Message-Id: <201003191902.o2JJ2Qig025943@cichlid.raleigh.ibm.com> To: Paul Hoffman In-reply-to: References: Comments: In-reply-to Paul Hoffman message dated "Fri, 19 Mar 2010 09:27:01 -0700." Date: Fri, 19 Mar 2010 15:02:26 -0400 From: Thomas Narten Cc: IPsecme WG Subject: Re: [IPsec] Fwd: Gen-art review of draft-ietf-ipsecme-ikev2bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 19:02:27 -0000 > s3.3.4: The draft states that the list of mandatory to implement > suites has been removed due to evolution going too fast. Is this > acceptable? Put the list in a standalone document that can (in theory) be easily updated without tying it to other changes in IKEv2? Thomas From paul.hoffman@vpnc.org Fri Mar 19 12:09:51 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F643A67EC for ; Fri, 19 Mar 2010 12:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.182 X-Spam-Level: X-Spam-Status: No, score=-5.182 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7Pjn2zfXvmT for ; Fri, 19 Mar 2010 12:09:50 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0CE5A3A67AE for ; Fri, 19 Mar 2010 12:09:47 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2JJ9xsA063069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Mar 2010 12:10:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <201003191902.o2JJ2Qig025943@cichlid.raleigh.ibm.com> References: <201003191902.o2JJ2Qig025943@cichlid.raleigh.ibm.com> Date: Fri, 19 Mar 2010 12:09:58 -0700 To: Thomas Narten From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Fwd: Gen-art review of draft-ietf-ipsecme-ikev2bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 19:09:51 -0000 At 3:02 PM -0400 3/19/10, Thomas Narten wrote: > > s3.3.4: The draft states that the list of mandatory to implement >> suites has been removed due to evolution going too fast. Is this >> acceptable? > >Put the list in a standalone document that can (in theory) be easily >updated without tying it to other changes in IKEv2? That's exactly what we did with RFC 4307 and RFC 4308. We haven't updated them, but we could. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Fri Mar 19 19:19:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3683A6821 for ; Fri, 19 Mar 2010 19:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.164 X-Spam-Level: X-Spam-Status: No, score=-5.164 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZY-Y1dzvITS for ; Fri, 19 Mar 2010 19:19:56 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 723413A67B1 for ; Fri, 19 Mar 2010 19:19:55 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2K2K7Yb081956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Mar 2010 19:20:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 19 Mar 2010 19:20:05 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Meeting materials and audio information X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 02:19:59 -0000 Greetings again. For those of you attending the Anaheim meeting and those of you who will listen on the audio stream, you can download the meeting materials before the meeting on Monday (although be aware that they might change between now and then). They can be found at . To hear the audio stream, please see the agenda at . The little speaker icons next to the name of the meeting should, in theory, take you to the audio stream. There is also a link for the Jabber room. We are meeting Monday morning, 0900, in California D (not California A, where we were scheduled earlier). The room will also supposedly have a WebEx connection for people who want to dial in to speak. We have no information on that yet. --Paul Hoffman, Director --VPN Consortium From yaronf.ietf@gmail.com Sun Mar 21 13:39:39 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2263A680C for ; Sun, 21 Mar 2010 13:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbyzgG5zM-l2 for ; Sun, 21 Mar 2010 13:39:38 -0700 (PDT) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by core3.amsl.com (Postfix) with ESMTP id 8F0673A67E1 for ; Sun, 21 Mar 2010 13:39:35 -0700 (PDT) Received: by fxm1 with SMTP id 1so5072621fxm.13 for ; Sun, 21 Mar 2010 13:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=jsP9m9fk94Yffzn9I/nKAR6eGBSYlivOankg2CkZ4aw=; b=E64kcDYTazC95YMtP6/JRZLO9M0ZYMcjyJsETXuZP2slKppqr1ee53r4jdWil+U676 MVrnt8xxJBNzShDXOjnicAX/rYpD1NbSXRAMTZ4XXZ9fHVc1tBFfriq/8sEPL7uBD8F7 xM17XckY7KyNdsC5pLpU0fhaG2tB51UKhZPqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=YGZOQNR89KIRxzYXreWuI8szK/ekfUoEOjWeE/I9QbYXYQITiHDe1bWDSDtep3yeCl lqZijDeTgdk3bU12lukpwkN6zAvOPvc3ninMjWL7aiKt8YwosuIPMn0oNTjFfmcvuHAR +52ddHlMhva0oT3ROM+hCZfKNUIm3wR5v12kQ= Received: by 10.87.63.4 with SMTP id q4mr7039233fgk.59.1269203986256; Sun, 21 Mar 2010 13:39:46 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id e3sm4033245fga.29.2010.03.21.13.39.45 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 13:39:46 -0700 (PDT) Message-ID: <4BA68425.7070407@gmail.com> Date: Sun, 21 Mar 2010 22:40:05 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: multipart/alternative; boundary="------------000506020406070601060808" Subject: [IPsec] Remote participation in tomorrow's IPsecME session X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 20:39:39 -0000 This is a multi-part message in MIME format. --------------000506020406070601060808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The IPsecME WG session will take place tomorrow, Monday March 22, at 9:00-11:30 PST. For those of us who are not attending in person (and that includes myself this time), there are two options: The old fashioned Jabber plus one-way audio: see directions here and here (we're in California D). Or the hi tech WebEx alternative: http://www.ietf.org/meeting/77/webex.html (the first line is us). Hope to see you all there tomorrow, even if virtually! Yaron --------------000506020406070601060808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

The IPsecME WG session will take place tomorrow, Monday March 22, at 9:00-11:30 PST.

For those of us who are not attending in person (and that includes myself this time), there are two options:

The old fashioned Jabber plus one-way audio: see directions here and here (we're in California D).

Or the hi tech WebEx alternative: http://www.ietf.org/meeting/77/webex.html (the first line is us).

Hope to see you all there tomorrow, even if virtually!

    Yaron
--------------000506020406070601060808-- From kivinen@iki.fi Sun Mar 21 15:04:31 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A228D3A6824 for ; Sun, 21 Mar 2010 15:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-1.842, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQpH1JGHSngn for ; Sun, 21 Mar 2010 15:04:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 753403A677D for ; Sun, 21 Mar 2010 15:04:30 -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 o2LM4ej5022982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Mar 2010 00:04:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o2LM4dfL027341; Mon, 22 Mar 2010 00:04:39 +0200 (EET) 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: <19366.38903.768745.232444@fireball.kivinen.iki.fi> Date: Mon, 22 Mar 2010 00:04:39 +0200 From: Tero Kivinen To: ynir@checkpoint.com, ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 17 min Subject: [IPsec] Comments about draft-ietf-ipsecme-ipsec-ha-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 22:04:31 -0000 I was quickly browsing this document and here is some quick comments to it: In section 3.2 it is only talking about counters, but for IKE SA the other MUST also be able to retransmit previous message in case it was lost. So it is not enough to transmit only the Message-ID counters (inbound window and outbound message), but also the actual packets associated with each message ID (for outbound case). If devices have window larger than one, then the outbound request window could be large, so several packets per IKE SA needs to be kept. Request packets can be forgotten when reply is received, but replies cannot be forgotten as there is no way to know whether other end received the reply or not. Good thing is that the outbound messages are static after they are sent, thus they only need to be transmitted over the synch channel once. Also in case MOBIKE is used, that will add even more state to the SAs, as the active peer addresses needs to be stored. Most likely there is no need to store the mobike process data itself, as the mobike process that was just ongoing when failure happened, can be rerun after failover. In section 3.4 there is text saying: > o It requires multiple parallel SAs, which the peer has no use for. > Section 2.8 or [RFC4306] specifically allows this, but some > implementation might have a policy against long term maintenance > of redundant SAs. This is not only allowed, it is MUST feature of RFC4301 (section 4.1 says: To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver, with the same selectors. Distribution of traffic among these So even when RFC4306 says it is allowed, it is mandatory feature in IPsec architecture, thus I do not think it really matters if some implementations decide to make policy rules against it as they surely will have way to turn those policy rules off to be able to be RFC4301 complient. Also I think the other two "shortcomings" are not really relevenat here. The firewall or deep inspection engine actiong on the load balancing devices, must be able to cope with the problem anyways. Also IPsec does not have return packets, thus where those imaginary return packets come in does not matter. -- kivinen@iki.fi From kivinen@iki.fi Sun Mar 21 15:20:41 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09BF3A6956 for ; Sun, 21 Mar 2010 15:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=-1.710, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NCF3yXPScUv for ; Sun, 21 Mar 2010 15:20:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C4D343A677D for ; Sun, 21 Mar 2010 15:20:23 -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 o2LMKZ2K023927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Mar 2010 00:20:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o2LMKZqp027407; Mon, 22 Mar 2010 00:20:35 +0200 (EET) 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: <19366.39859.336431.204705@fireball.kivinen.iki.fi> Date: Mon, 22 Mar 2010 00:20:35 +0200 From: Tero Kivinen To: ipsec@ietf.org, yaronf@checkpoint.com X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 14 min Subject: [IPsec] Some comments to the draft-sheffer-ipsecme-pake-criteria-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 22:20:41 -0000 The document should list more of the engineering considerations too in addition to the IPR and security. The Security requirement is mandatory (how that is show is completely different matter). The IPR issue would be nice to have. So I expect we end up looking other properties too. The other considerations section is quite short, and for example I do not really care whether the protocol was specified in standards document or scientific paper, as in any case we are going to make sure our document describes the protocol in a way that alows interoperability. Also in some cases the standards document are WAY too hard to read to be able to provide interoperability... :-) Also the second point of having protocol already integrated into IKE does not really matter, as the only thing it does is to save us some time. If the protocol is good and suitable to be integrated to IKE, I do not really think we should leave it out just because someone has not yet done the work to actually write the document telling how they are integrated. This is the document we are going to be writing here anyways. More suitable criteria would be to say it must be something that can be easily integrated to the IKE. I think this section should also include more concrete engineering criteria lists, like: - Number of round trips - Cost of cryptographic processing - Does it share same cryptograhic blocks already used in IKE (I.e. it would be better to have protocol using MODP+SHA1, than some polynominal shares plush some hash function not used in IKE). - Does it share for example the Diffie-Hellman groups already used in the IKE. - Does it fit to the IKE PSK model (i.e for example it should not rely on trusted third party) Most likely we are going to be using those engineering criteria to select the final protocol, as I do not expect there be that much difference (that we can agree on) on other security and IPR. -- kivinen@iki.fi From kivinen@iki.fi Sun Mar 21 15:41:23 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8BD3A67B4 for ; Sun, 21 Mar 2010 15:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=-1.596, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CMaCJlV05Nw for ; Sun, 21 Mar 2010 15:41:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9894C3A677D for ; Sun, 21 Mar 2010 15:41:21 -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 o2LMfS8g010839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Mar 2010 00:41:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o2LMfQkM028699; Mon, 22 Mar 2010 00:41:26 +0200 (EET) 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: <19366.41110.787241.99409@fireball.kivinen.iki.fi> Date: Mon, 22 Mar 2010 00:41:26 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: sean.s.shen@gmail.com, ssmurthy.nittala@freescale.com, yumao9@gmail.com Subject: [IPsec] One more comment to the draft-ietf-ipsecme-aes-ctr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 22:41:23 -0000 In the security considerations section there is a text saying: > Additionally, since AES has a 128-bit block size, regardless of the > mode employed, the ciphertext generated by AES encryption becomes > distinguishable from random values after 2^64 blocks are encrypted > with a single key. Since IKEv2 is not likely to carry traffic in > such a high quantity compared with ESP, this won't be a big concern > here. However, when a large amount of traffic appears in the future > or under abnormal circumstances, implementations SHOULD generate a > fresh key before 2^64 blocks are encrypted with the same key. The last SHOULD is not really needed as IKEv2 message ID is 32-bits, and the IKE SA MUST be closed (or rekeyed) before it wraps, thus at most one IKE SA can have 2^32 messages, each consisting of at max 2^16 bytes, thus maximum number of bytes that may be transmitted over IKEv2 SA is 2^48 bytes. As this 2^48 bytes is much smaller than 2^64 blocks, this paragraph is not an issue in IKEv2. I would change the paragraph to be: Additionally, since AES has a 128-bit block size, regardless of the mode employed, the ciphertext generated by AES encryption becomes distinguishable from random values after 2^64 blocks are encrypted with a single key. Since IKEv2 SA cannot carry that much of data, this issue is not a concern here. -- kivinen@iki.fi From yaronf.ietf@gmail.com Sun Mar 21 16:06:23 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849AA3A6AD7 for ; Sun, 21 Mar 2010 16:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZPVEmzIv89j for ; Sun, 21 Mar 2010 16:06:22 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 5B1723A6956 for ; Sun, 21 Mar 2010 16:06:22 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so253850fga.13 for ; Sun, 21 Mar 2010 16:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YxKU7TieLMiEKAF6Szdpfk0d+622ecVWetg2zpEdH90=; b=soZEo9hkjYhUW3/8D9wW/SmnxsKno8N8yroC2B5aGaZS2MZl9pTvSig5V5kiaA1iJ+ 4BCaouWoutisu5qqDTfxJ5rtFaLK/1O499GHENI7OCxL5uQWjVtQcJzlZewLWqBHwVo8 VJsnp15ePaJNyzGpeaG+ittJrL1KXe7Ssb2sM= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=WSBUB834pb7Ci8w5MEoPOWh6MAcJHRusn9ql+mzG04XnUMXfUxch5WXxoKuwauPDyH mjYfExIA7iOHLSBwCOLI5p0hmdfdbPb9GLAv/v7SpPXCVBbTSFbXsCfPYUE/Lp/ufi6j Jc8B9L8dg30lAdSN4It3qVR5RDc4babavmTEo= Received: by 10.87.1.13 with SMTP id d13mr1245535fgi.29.1269212795759; Sun, 21 Mar 2010 16:06:35 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id e3sm4134485fga.24.2010.03.21.16.06.34 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 16:06:35 -0700 (PDT) Message-ID: <4BA6A68C.5070301@gmail.com> Date: Mon, 22 Mar 2010 01:06:52 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Tero Kivinen References: <19366.39859.336431.204705@fireball.kivinen.iki.fi> In-Reply-To: <19366.39859.336431.204705@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, yaronf@checkpoint.com Subject: Re: [IPsec] Some comments to the draft-sheffer-ipsecme-pake-criteria-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 23:06:23 -0000 Hi Tero, thanks for your comments. Please note that some of them have already been addressed in -01, which at the moment is only available on http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs. While not disputing the importance of the engineering criteria, I think there's quite a bit of differentiation between the various options on security and IPR. Thanks, Yaron On 22.3.2010 0:20, Tero Kivinen wrote: > The document should list more of the engineering considerations too in > addition to the IPR and security. The Security requirement is > mandatory (how that is show is completely different matter). The IPR > issue would be nice to have. So I expect we end up looking other > properties too. > > The other considerations section is quite short, and for example I do > not really care whether the protocol was specified in standards > document or scientific paper, as in any case we are going to make sure > our document describes the protocol in a way that alows > interoperability. Also in some cases the standards document are WAY > too hard to read to be able to provide interoperability... :-) > > Also the second point of having protocol already integrated into IKE > does not really matter, as the only thing it does is to save us some > time. If the protocol is good and suitable to be integrated to IKE, I > do not really think we should leave it out just because someone has > not yet done the work to actually write the document telling how they > are integrated. This is the document we are going to be writing here > anyways. More suitable criteria would be to say it must be something > that can be easily integrated to the IKE. > > I think this section should also include more concrete engineering > criteria lists, like: > > - Number of round trips > - Cost of cryptographic processing > - Does it share same cryptograhic blocks already used in IKE (I.e. > it would be better to have protocol using MODP+SHA1, than some > polynominal shares plush some hash function not used in IKE). > - Does it share for example the Diffie-Hellman groups already used > in the IKE. > - Does it fit to the IKE PSK model (i.e for example it should not > rely on trusted third party) > > Most likely we are going to be using those engineering criteria to > select the final protocol, as I do not expect there be that much > difference (that we can agree on) on other security and IPR. From fd@cisco.com Mon Mar 22 01:51:08 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB5A3A688A for ; Mon, 22 Mar 2010 01:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtsgCoL7Wb-E for ; Mon, 22 Mar 2010 01:51:07 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id B323E3A6881 for ; Mon, 22 Mar 2010 01:51:06 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o2M8pLvc025533; Mon, 22 Mar 2010 09:51:21 +0100 (CET) Received: from dhcp-64-103-12-106.cisco.com (dhcp-64-103-12-106.cisco.com [64.103.12.106]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o2M8pLXS025524; Mon, 22 Mar 2010 09:51:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Frederic Detienne In-Reply-To: Date: Mon, 22 Mar 2010 09:51:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Hoffman X-Mailer: Apple Mail (2.1077) Cc: IPsecme WG , "Pratima Sethi \(psethi\)" Subject: Re: [IPsec] IPR statement for draft-detienne-ikev2-recovery X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 08:51:08 -0000 Hi Paul, I am afraid you are mistaken. Yoav, Yaron, Pratima and I had a = discussion about the draft's IPR back in Dublin in July 2008. We told = back then that we would have rights released. The process takes its own = time but as far as Pratima and I are concerned, we did due diligence. Will you share your assumptions directly with us next time ? thanks, fred On 09 Mar 2010, at 18:37, Paul Hoffman wrote: > Greetings again. Cisco has recently posted an IPR statement that is = relevant to our charter. Please see = . You can see the patent application referenced in the IPR = statement at = . >=20 > Before reacting to this announcement, please review the IETF's IPR = policy at , and please read the = specific IPR statement carefully. You may wish to inform any legal = counsel you have about this. >=20 > On a personal note, I believe that it would have been much more = appropriate for Cisco to have let the WG know about this IPR before we = put the draft by name in our charter. I also note that at least one of = the co-authors on the named draft was not informed of the IPR; in my = opinion, this is particularly inappropriate. >=20 > We will begin the discussion of which secure crash discovery protocol = the WG wants to adopt in the next few days, and this IPR statement might = or might not affect the outcome, based on what the WG desires. >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Mon Mar 22 02:03:12 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDE83A6864 for ; Mon, 22 Mar 2010 02:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoybP2xsoTdm for ; Mon, 22 Mar 2010 02:03:12 -0700 (PDT) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by core3.amsl.com (Postfix) with ESMTP id E4B7F3A67F8 for ; Mon, 22 Mar 2010 02:03:11 -0700 (PDT) Received: by fxm1 with SMTP id 1so5402888fxm.13 for ; Mon, 22 Mar 2010 02:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=sv1EQZ6orEqsUclgJJI2zi4pe4uz7bIvk5DaN0JKg7o=; b=mxYc0RBWkztWo2zsYr/v9Z8Zw5+S5ZJ9pFXO8Fj3TtAcT1d/WMDK/cWESERFdW3ago ljgpRrFeujf3Oqf8IGJXZVspclb0bv02eFIIQmMxVXCHjc0Ydh4EbFhsUqtDe8dvPdnH sIfq1XMeHE4RhdVJ0P7o9EdtjZe2b3Vhi93Hc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=MDwlFaE42cKJBiIIpIRmCAGPmKaYu3BkhTENk+XlgWetMi4vRs4GAd8rm34en+T5jU xTYvFYE+/FShYfd4HJBJ29TbsJHmlBPX9Nw3z/t/OMnxphqj8LY5Lb6jKHloU0b+Taet 0vB8gDErMllEVZSe46Kwqmh/2WHVkkP391n+s= Received: by 10.87.74.27 with SMTP id b27mr5139611fgl.11.1269248605440; Mon, 22 Mar 2010 02:03:25 -0700 (PDT) Received: from [10.20.30.12] ([62.219.129.160]) by mx.google.com with ESMTPS id 4sm935714fge.28.2010.03.22.02.03.24 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 02:03:25 -0700 (PDT) Message-ID: <4BA73271.4090908@gmail.com> Date: Mon, 22 Mar 2010 11:03:45 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] PAKE Criteria draft posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 09:03:13 -0000 Hi, version -01 of the draft has been on the IPsecME wiki for the last few days. It is now posted under https://datatracker.ietf.org/doc/draft-sheffer-ipsecme-pake-criteria/ (with a new date, but the same content). Thanks, Yaron From paul.hoffman@vpnc.org Mon Mar 22 07:13:38 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D7328C15D for ; Mon, 22 Mar 2010 07:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkBeJo+r5y42 for ; Mon, 22 Mar 2010 07:13:37 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5ED493A6951 for ; Mon, 22 Mar 2010 07:10:11 -0700 (PDT) Received: from [10.6.19.70] (adsl-99-32-106-187.dsl.irvnca.sbcglobal.net [99.32.106.187]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2ME9f1R048251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Mar 2010 07:09:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 22 Mar 2010 07:09:15 -0700 To: Frederic Detienne From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG , "Pratima Sethi \(psethi\)" Subject: Re: [IPsec] IPR statement for draft-detienne-ikev2-recovery X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 14:13:38 -0000 At 9:51 AM +0100 3/22/10, Frederic Detienne wrote: >I am afraid you are mistaken. Yoav, Yaron, Pratima and I had a discussion about the draft's IPR back in Dublin in July 2008. We told back then that we would have rights released. The process takes its own time but as far as Pratima and I are concerned, we did due diligence. Thank you. >Will you share your assumptions directly with us next time ? As WG co-chair, I need to trust the words and intentions of active WG contributors as much as I can. When the Cisco IPR statement for SIR came out, I was surprised, so I asked your co-author, Yoav Nir, about whether he had known about it. His response was that he had not known about it until after Cisco's recent IPR statement. I took him at his word. To be clear: this is not a matter of which one of you is telling the truth. It is quite easy that one of you misunderstood the other because the discussion of SIR and QCD had gotten mixed up with the discussion of session resumption and maybe-related topics. There is, I believe, a chance that you told *me* about the pending patent and I forgot. I doubt that, but I also admit to having prejudices about IPR and so on that would cause me to have less-than-perfect memory. I cut you and Yoav the same slack I cut myself. To be clear, part 2: the patent situation with SIR has not affected the WG's decision yet. There are plenty of companies whose generic IETF patent licenses are similar to those offered by Cisco for SIR. That is why my message to the WG informing them of Cisco's IPR statement said "Before reacting to this announcement, please review the IETF's IPR policy". Knee-jerk reactions to IPR statements can cause more damage in the IETF than IPR statements themselves. I still stand by my statement that I would have preferred Cisco to issue the statement when we were discussing listing SIR in the charter in this current round: more information is always good. I apologize for saying "at least one of the co-authors on the named draft was not informed of the IPR"; I could have said "I have heard that at least one of the co-authors on the named draft was not informed of the IPR", which is a more accurate statement. --Paul Hoffman, Director --VPN Consortium From yaronf.ietf@gmail.com Mon Mar 22 08:10:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8453A68EB for ; Mon, 22 Mar 2010 08:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJb099WQ1OZD for ; Mon, 22 Mar 2010 08:10:34 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 89A803A68CC for ; Mon, 22 Mar 2010 08:10:33 -0700 (PDT) Received: by fxm5 with SMTP id 5so1524383fxm.29 for ; Mon, 22 Mar 2010 08:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=rYvJTPBnNm/FkTnsuIX02VAB+MaU9zWVaTgisX6Qx1c=; b=Cc92mnEloxbhQb5iNdcnxpjXjlRCyzuvZ9jHKA2GnFD4Mwzy8RPVhJSCgKOKK6L8Zn TrJwv4yjVTLSrhMnk8p4fC+Vr+aP3rKAUqMkpXdmQGz1UvKpjpGTkBoiLe+zbtYAv4XX oBnEZ4ksWJoeH0g22fblMb39J440TmN4vuD98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=KiyOg1W64FiQlDN74g8nwRYKb3xE/kT0hKelm98D6UKkLHyFkbZWGdM+Nz8DCj0+UU rT00yshzOAi1pijOUSGsRcEZBIl5qhaP+g2TRlEjmKahE+nOicnmRq/HPDtn9C/3pYJn 0yiF4ImxmbIDAknQ32ymZSQqbkbMNupXU1868= Received: by 10.86.22.2 with SMTP id 2mr2439380fgv.17.1269270644173; Mon, 22 Mar 2010 08:10:44 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id e3sm4825654fga.14.2010.03.22.08.10.42 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 08:10:43 -0700 (PDT) Message-ID: <4BA78886.60409@gmail.com> Date: Mon, 22 Mar 2010 17:11:02 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: multipart/alternative; boundary="------------050007060006020102080805" Subject: [IPsec] Fwd: I-D Action:draft-sheffer-ipsecme-hush-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 15:10:35 -0000 This is a multi-part message in MIME format. --------------050007060006020102080805 Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Hi, we will *not* discuss this document at today's IPsecME session. But we would appreciate your comments anyway. Thanks, Yaron -------- Original Message -------- Subject: I-D Action:draft-sheffer-ipsecme-hush-00.txt Date: Mon, 22 Mar 2010 01:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : HUSH: Using HUmanly memorable SHared secrets with IKEv2 Author(s) : Y. Sheffer, S. Fluhrer Filename : draft-sheffer-ipsecme-hush-00.txt Pages : 12 Date : 2010-03-22 This document defines a new mode for IKEv2, where both peers can authenticate using a short, humanly memorable shared secret. This mode is based on the EKE protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-hush-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------050007060006020102080805 Content-Type: text/html; charset=windows-1255 Content-Transfer-Encoding: 8bit Hi,

we will *not* discuss this document at today's IPsecME session. But we would appreciate your comments anyway.

Thanks,
    Yaron

-------- Original Message --------
Subject: I-D Action:draft-sheffer-ipsecme-hush-00.txt
Date: Mon, 22 Mar 2010 01:15:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : HUSH: Using HUmanly memorable SHared secrets with IKEv2
	Author(s)       : Y. Sheffer, S. Fluhrer
	Filename        : draft-sheffer-ipsecme-hush-00.txt
	Pages           : 12
	Date            : 2010-03-22

This document defines a new mode for IKEv2, where both peers can
authenticate using a short, humanly memorable shared secret.  This
mode is based on the EKE protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-hush-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------050007060006020102080805-- From wwwrun@rfc-editor.org Sun Mar 21 11:37:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA323A6828 for ; Sun, 21 Mar 2010 11:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyTJswk-il0a for ; Sun, 21 Mar 2010 11:37:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 19BDB3A67E9 for ; Sun, 21 Mar 2010 11:37:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B9207E0764; Sun, 21 Mar 2010 11:37:45 -0700 (PDT) To: pasi.eronen@nokia.com, julienl@qualcomm.com, cmadson@cisco.com, tim.polk@nist.gov, pasi.eronen@nokia.com, paul.hoffman@vpnc.org, yaronf@checkpoint.com From: RFC Errata System Message-Id: <20100321183745.B9207E0764@rfc-editor.org> Date: Sun, 21 Mar 2010 11:37:45 -0700 (PDT) X-Mailman-Approved-At: Mon, 22 Mar 2010 08:11:36 -0700 Cc: ipsec@ietf.org, ah@TR-Sys.de, rfc-editor@rfc-editor.org Subject: [IPsec] [Technical Errata Reported] RFC5739 (2089) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 18:37:31 -0000 The following errata report has been submitted for RFC5739, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5739&eid=2089 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 4.5,2nd para Original Text ------------- All other attributes except INTERNAL_IP6_ADDRESS (and | INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of [RFC4718] for discussion). Corrected Text -------------- All other attributes except INTERNAL_IP6_ADDRESS (and | INTERNAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of [RFC4718] for discussion). Notes ----- Rationale: Technically significant spelling error. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5739 (draft-ietf-ipsecme-ikev2-ipv6-config-03) -------------------------------------- Title : IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : February 2010 Author(s) : P. Eronen, J. Laganier, C. Madson Category : EXPERIMENTAL Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Sun Mar 21 11:40:27 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70DC3A67E9 for ; Sun, 21 Mar 2010 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+1MSO4XFcM3 for ; Sun, 21 Mar 2010 11:40:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 2C9AB3A6784 for ; Sun, 21 Mar 2010 11:40:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CCC12E0764; Sun, 21 Mar 2010 11:40:43 -0700 (PDT) To: pasi.eronen@nokia.com, julienl@qualcomm.com, cmadson@cisco.com, tim.polk@nist.gov, pasi.eronen@nokia.com, paul.hoffman@vpnc.org, yaronf@checkpoint.com From: RFC Errata System Message-Id: <20100321184043.CCC12E0764@rfc-editor.org> Date: Sun, 21 Mar 2010 11:40:43 -0700 (PDT) X-Mailman-Approved-At: Mon, 22 Mar 2010 08:11:36 -0700 Cc: ipsec@ietf.org, ah@TR-Sys.de, rfc-editor@rfc-editor.org Subject: [IPsec] [Editorial Errata Reported] RFC5739 (2090) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 18:40:27 -0000 The following errata report has been submitted for RFC5739, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5739&eid=2090 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 4.3,1st para Original Text ------------- [...]. However, if the same peers are also using IPsec/ IKEv2 for other uses (with addresses not assigned inside IKEv2), they would also have SPD entries and PAD Child SA Authorization Data that | is not related to the virtual link. Corrected Text -------------- [...]. However, if the same peers are also using IPsec/ IKEv2 for other uses (with addresses not assigned inside IKEv2), they would also have SPD entries and PAD Child SA Authorization Data that | are not related to the virtual link. Notes ----- Rationale: Grammar: "SPD entries and ... Data ... are ..." Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5739 (draft-ietf-ipsecme-ikev2-ipv6-config-03) -------------------------------------- Title : IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : February 2010 Author(s) : P. Eronen, J. Laganier, C. Madson Category : EXPERIMENTAL Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From fd@cisco.com Mon Mar 22 08:17:00 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83AA3A6800 for ; Mon, 22 Mar 2010 08:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1zFvJcz0ssc for ; Mon, 22 Mar 2010 08:17:00 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id C5A283A692E for ; Mon, 22 Mar 2010 08:16:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o2MFGwnT012300; Mon, 22 Mar 2010 16:16:58 +0100 (CET) Received: from dhcp-bru-peg2-vl26-144-254-9-252.cisco.com (dhcp-bru-peg2-vl26-144-254-9-252.cisco.com [144.254.9.252]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o2MFGwN6012289; Mon, 22 Mar 2010 16:16:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Frederic Detienne In-Reply-To: Date: Mon, 22 Mar 2010 16:16:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38A5FB2E-CD22-45D1-B941-9519F961A033@cisco.com> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1077) Cc: IPsecme WG , "Pratima Sethi \(psethi\)" Subject: Re: [IPsec] IPR statement for draft-detienne-ikev2-recovery X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 15:17:00 -0000 Hi Paul, I am still puzzled that you see fit to check in private with Yoav and in = public with us. For the records, at least one of the co-chairs (Yaron) was advised about = the IPR at the same time as Yoav. regards, fred On 22 Mar 2010, at 15:09, Paul Hoffman wrote: > At 9:51 AM +0100 3/22/10, Frederic Detienne wrote: >> I am afraid you are mistaken. Yoav, Yaron, Pratima and I had a = discussion about the draft's IPR back in Dublin in July 2008. We told = back then that we would have rights released. The process takes its own = time but as far as Pratima and I are concerned, we did due diligence. >=20 > Thank you. >=20 >> Will you share your assumptions directly with us next time ? >=20 > As WG co-chair, I need to trust the words and intentions of active WG = contributors as much as I can. When the Cisco IPR statement for SIR came = out, I was surprised, so I asked your co-author, Yoav Nir, about whether = he had known about it. His response was that he had not known about it = until after Cisco's recent IPR statement. I took him at his word. >=20 > To be clear: this is not a matter of which one of you is telling the = truth. It is quite easy that one of you misunderstood the other because = the discussion of SIR and QCD had gotten mixed up with the discussion of = session resumption and maybe-related topics. There is, I believe, a = chance that you told *me* about the pending patent and I forgot. I doubt = that, but I also admit to having prejudices about IPR and so on that = would cause me to have less-than-perfect memory. I cut you and Yoav the = same slack I cut myself. >=20 > To be clear, part 2: the patent situation with SIR has not affected = the WG's decision yet. There are plenty of companies whose generic IETF = patent licenses are similar to those offered by Cisco for SIR. That is = why my message to the WG informing them of Cisco's IPR statement said = "Before reacting to this announcement, please review the IETF's IPR = policy". Knee-jerk reactions to IPR statements can cause more damage in = the IETF than IPR statements themselves. >=20 > I still stand by my statement that I would have preferred Cisco to = issue the statement when we were discussing listing SIR in the charter = in this current round: more information is always good. I apologize for = saying "at least one of the co-authors on the named draft was not = informed of the IPR"; I could have said "I have heard that at least one = of the co-authors on the named draft was not informed of the IPR", which = is a more accurate statement. >=20 > --Paul Hoffman, Director > --VPN Consortium From yaronf.ietf@gmail.com Mon Mar 22 08:35:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64803A691E for ; Mon, 22 Mar 2010 08:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.105 X-Spam-Level: X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O9vdiWdrKF0 for ; Mon, 22 Mar 2010 08:35:32 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 3B4A33A6800 for ; Mon, 22 Mar 2010 08:35:28 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so567674fgg.13 for ; Mon, 22 Mar 2010 08:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=UDdioGdtF85BUxzqYLpBT5aP2KzR6e1qZfvIcn1uBtY=; b=KNCv39Kx1rV0is44Jv9ZDGX3VDGDmeHSPKnla8VtGOwIvElmpekUSqCyVVWH0iZ8M5 jxfi98ewcyAjlPAI1mMmxRveW5q084fHTmWYD6M2U9GgDOoaOlqCQczkjmjrU+naR1RB gKj2j4BnaNTsxAavzqMAhGJnFE6oKYclsnqY4= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=agYvigPlGM6S0cL6RV7YnCTbf0i4ayn8lzBdt/oNkRqYfM0k51YuGMkc7/GlXdaIip r+Mx2t3o6r/f8PimpGrScL+uXn6kUbdgdS6jOtHU6viw8CNAOT+iJXMKb6LIm6IdQPZ/ dSMeODfiAxHM2osDVTPDJkQafhPQs9cXxNroE= Received: by 10.87.47.35 with SMTP id z35mr1796171fgj.76.1269272142313; Mon, 22 Mar 2010 08:35:42 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id 12sm4241723fgg.4.2010.03.22.08.35.41 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 08:35:41 -0700 (PDT) Message-ID: <4BA78E61.3080001@gmail.com> Date: Mon, 22 Mar 2010 17:36:01 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Frederic Detienne References: <38A5FB2E-CD22-45D1-B941-9519F961A033@cisco.com> In-Reply-To: <38A5FB2E-CD22-45D1-B941-9519F961A033@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman , "Pratima Sethi \(psethi\)" Subject: Re: [IPsec] IPR statement for draft-detienne-ikev2-recovery X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 15:35:33 -0000 Hi Frederic, this is correct, however we did not share this information because it was an individual submission at the time, and we expected Cisco to do the right thing, i.e. to inform the WG in a timely manner (and later, we simply forgot). For some reason, Cisco chose to publish the IPR statement more than a year after the application was published by the patent office. It was Cisco's responsibility, and your personal responsibility, to follow IETF due process here. Thanks, Yaron On 22.3.2010 17:16, Frederic Detienne wrote: > Hi Paul, > > I am still puzzled that you see fit to check in private with Yoav and in public with us. > > For the records, at least one of the co-chairs (Yaron) was advised about the IPR at the same time as Yoav. > > regards, > > fred > > On 22 Mar 2010, at 15:09, Paul Hoffman wrote: > >> At 9:51 AM +0100 3/22/10, Frederic Detienne wrote: >>> I am afraid you are mistaken. Yoav, Yaron, Pratima and I had a discussion about the draft's IPR back in Dublin in July 2008. We told back then that we would have rights released. The process takes its own time but as far as Pratima and I are concerned, we did due diligence. >> >> Thank you. >> >>> Will you share your assumptions directly with us next time ? >> >> As WG co-chair, I need to trust the words and intentions of active WG contributors as much as I can. When the Cisco IPR statement for SIR came out, I was surprised, so I asked your co-author, Yoav Nir, about whether he had known about it. His response was that he had not known about it until after Cisco's recent IPR statement. I took him at his word. >> >> To be clear: this is not a matter of which one of you is telling the truth. It is quite easy that one of you misunderstood the other because the discussion of SIR and QCD had gotten mixed up with the discussion of session resumption and maybe-related topics. There is, I believe, a chance that you told *me* about the pending patent and I forgot. I doubt that, but I also admit to having prejudices about IPR and so on that would cause me to have less-than-perfect memory. I cut you and Yoav the same slack I cut myself. >> >> To be clear, part 2: the patent situation with SIR has not affected the WG's decision yet. There are plenty of companies whose generic IETF patent licenses are similar to those offered by Cisco for SIR. That is why my message to the WG informing them of Cisco's IPR statement said "Before reacting to this announcement, please review the IETF's IPR policy". Knee-jerk reactions to IPR statements can cause more damage in the IETF than IPR statements themselves. >> >> I still stand by my statement that I would have preferred Cisco to issue the statement when we were discussing listing SIR in the charter in this current round: more information is always good. I apologize for saying "at least one of the co-authors on the named draft was not informed of the IPR"; I could have said "I have heard that at least one of the co-authors on the named draft was not informed of the IPR", which is a more accurate statement. >> >> --Paul Hoffman, Director >> --VPN Consortium > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From root@core3.amsl.com Mon Mar 22 09:15:02 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 29DA33A69B0; Mon, 22 Mar 2010 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100322161502.29DA33A69B0@core3.amsl.com> Date: Mon, 22 Mar 2010 09:15:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Heuristics for Detecting ESP-NULL packets Author(s) : T. Kivinen, D. McDonald Filename : draft-ietf-ipsecme-esp-null-heuristics-07.txt Pages : 37 Date : 2010-03-22 This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep inspection engines, to quickly decide whether given packet flow is encrypted or not, i.e. whether it can be inspected or not. Use of these heuristics does not require any changes made on existing RFC4303 compliant IPsec hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-esp-null-heuristics-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-22090355.I-D@ietf.org> --NextPart-- From mcgrew@cisco.com Mon Mar 22 09:31:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3244A3A693C for ; Mon, 22 Mar 2010 09:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.034 X-Spam-Level: X-Spam-Status: No, score=-10.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG9qG+sPDgFc for ; Mon, 22 Mar 2010 09:31:28 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 13F8F28C123 for ; Mon, 22 Mar 2010 09:31:26 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF84p0tAZnwN/2dsb2JhbACbJHOjfZgZhH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,288,1267401600"; d="scan'208";a="95047266" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Mar 2010 16:31:44 +0000 Received: from dhcp-wireless-open-abg-26-197.meeting.ietf.org (che-vpn-cluster-1-128.cisco.com [10.86.240.128]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2MGVhdF012063; Mon, 22 Mar 2010 16:31:44 GMT Message-Id: From: David McGrew To: ynir@checkpoint.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 22 Mar 2010 09:29:05 -0700 X-Mailer: Apple Mail (2.936) Cc: IPsecme WG Subject: [IPsec] synchronizing crypto state X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:31:29 -0000 Hi Yoav, another requirement for IPsec HA is to coordinate the use of distinct counters between multiple crypto engines. The problem (and a convenient solution) is described in http://tools.ietf.org/html/draft-ietf-msec-ipsec-group-counter-modes-05 David From shore@arsc.edu Mon Mar 22 09:44:23 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD333A69C2 for ; Mon, 22 Mar 2010 09:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[AWL=-2.441, BAYES_80=2, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v8j6krx3snv for ; Mon, 22 Mar 2010 09:44:08 -0700 (PDT) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id B9C103A691D for ; Mon, 22 Mar 2010 09:44:06 -0700 (PDT) Received: from webmail.arsc.edu (web4.arsc.edu [199.165.84.246]) by arsc.edu (20090828.ARSC) with ESMTP id o2MGiF3V003888 for ; Mon, 22 Mar 2010 08:44:15 -0800 (AKDT) Received: from 2001:df8:0:24:225:d3ff:fed5:7b05 by webmail.arsc.edu with HTTP; Mon, 22 Mar 2010 08:44:15 -0800 (ADT) Message-ID: <2f9f601123df0c8467eab4a5e9fed14b.squirrel@webmail.arsc.edu> Date: Mon, 22 Mar 2010 08:44:15 -0800 (ADT) From: shore@arsc.edu To: ipsec@ietf.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-CanIt-Geo: ip=199.165.84.246; country=US; region=AK; city=Fairbanks; postalcode=99775; latitude=64.8834; longitude=-147.4984; metrocode=745; areacode=907; http://maps.google.com/maps?q=64.8834,-147.4984&z=6 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 199.165.84.167 Subject: [IPsec] Terminology issue (minor) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:44:23 -0000 This is probably a small thing, but in general the term "cluster" implies at least some degree of shared state among cluster members. I understand that there's some suggestion of that in saying that a cluster protects the same domain but there's really quite a bit more to it than that - it's going to things like the SADB or a subset of the SADB. It needn't be in real-time or near real-time, but it has to be there for it to be considered a cluster (rather than, say, multi-homing). I don't think including that in the definition requires that the wg take on state synchronization among cluster members. Melinda From Black_David@emc.com Mon Mar 22 11:18:06 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3434A3A6842 for ; Mon, 22 Mar 2010 11:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.683 X-Spam-Level: X-Spam-Status: No, score=-5.683 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkAKtNxG2Ead for ; Mon, 22 Mar 2010 11:18:05 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id E76CD3A693C for ; Mon, 22 Mar 2010 11:18:03 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o2MIIKuD028296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Mar 2010 14:18:20 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Mon, 22 Mar 2010 14:18:18 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o2MII3X9013792 for ; Mon, 22 Mar 2010 14:18:17 -0400 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 14:18:14 -0400 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: Mon, 22 Mar 2010 14:18:11 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Password-Based Auth: Two criteria comments Thread-Index: AcrJ7AfxCLArm/AvSRSQ7D/IXyRH2Q== From: To: X-OriginalArrivalTime: 22 Mar 2010 18:18:14.0172 (UTC) FILETIME=[0976B5C0:01CAC9EC] X-EMM-EM: Active Cc: Black_David@emc.com Subject: [IPsec] Password-Based Auth: Two criteria comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 18:18:06 -0000 Summarizing what I said in the meeting: (1) The performance criteria should include performance with large = complex secrets (e.g., pre-shared keys), not just the smaller passwords = that people can reasonably be expected to remember. This is because a password-based authentication mechanism may be = usefully applied to shared secret authentication implementations that = derive a supposedly strong secret solely from a password (see the = discussion of pre-shared key authentication in Section 2.15 of RFC = 4306). Password-based authentication would provides some defense = against this and other key generation weaknesses. The original password = that was used to generate the shared secret may no longer be available, = so good performance on large complex secrets would enable password based = authentication to use the derived (supposedly strong) secret as the = password. (2) Management (e.g., password change, password policy) is not mentioned = in the criteria document. This is good. Keeping management orthogonal (i.e., out of scope of this criteria = discussion) is (IMHO) a good thing, as management techniques and = requirements may vary widely across classes of implementations. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 black_david@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From dharkins@lounge.org Mon Mar 22 11:20:06 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714A73A69CF for ; Mon, 22 Mar 2010 11:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.329 X-Spam-Level: X-Spam-Status: No, score=-4.329 tagged_above=-999 required=5 tests=[AWL=-1.794, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roUImVrTI5zf for ; Mon, 22 Mar 2010 11:20:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 32F213A67D3 for ; Mon, 22 Mar 2010 11:20:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B80CC1022404A; Mon, 22 Mar 2010 11:20:20 -0700 (PDT) Received: from 130.129.26.143 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 22 Mar 2010 11:20:20 -0700 (PDT) Message-ID: <884e7195495b157f15c923c3ba660a99.squirrel@www.trepanning.net> In-Reply-To: References: Date: Mon, 22 Mar 2010 11:20:20 -0700 (PDT) From: "Dan Harkins" To: "David McGrew" 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 , ynir@checkpoint.com Subject: Re: [IPsec] synchronizing crypto state X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 18:20:06 -0000 Hi, Another solution is to use a cipher mode (like SIV) that does not lose all security if a counter is reused. Then you don't have to worry at all it. Dan. On Mon, March 22, 2010 9:29 am, David McGrew wrote: > Hi Yoav, > > another requirement for IPsec HA is to coordinate the use of distinct > counters between multiple crypto engines. The problem (and a > convenient solution) is described in > http://tools.ietf.org/html/draft-ietf-msec-ipsec-group-counter-modes-05 > > David > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf.ietf@gmail.com Mon Mar 22 11:27:50 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1ABF3A68B6 for ; Mon, 22 Mar 2010 11:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9Rrf2tkYh2F for ; Mon, 22 Mar 2010 11:27:49 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 90BDE3A688F for ; Mon, 22 Mar 2010 11:27:49 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so36810fgb.13 for ; Mon, 22 Mar 2010 11:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=gzSZZQXg1GmBwJguuiYFT11IaNSzSmafdPHP1nJn9zE=; b=a5gkgCAw6N0WB27wZwlSrJnpatdWj2e6X55sTu+ojc39DidjI9+HJAgS9uO6b4YltU dCIX15h8c+zOg+S3J6hoMoWlhj2a02/bG3+XSbxQXVwqBGWymfQTMYmAWsT81fQ6vbSD vRrcDHd00w5jVsCy41ijOyhSLXw/uGbNisVyo= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=UpKktFhh8kn31a4lFFXS3U+TU703FJP1EVx6Y0LyJYtN+9y88OqPsJQnFEQ+hCgDLZ YUnWWNUNNihykVO64RQeoR13fuNOuPo2D3U+AP0Az1vegiG+tQZh9U/sx1PvbYE8CgBE GSCzlzkRvXyyEvHrwaK0brZBpdOmMGzhBnxjQ= Received: by 10.87.47.32 with SMTP id z32mr114013fgj.36.1269282483633; Mon, 22 Mar 2010 11:28:03 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id 4sm1757530fgg.17.2010.03.22.11.28.02 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 11:28:03 -0700 (PDT) Message-ID: <4BA7B6C6.9000504@gmail.com> Date: Mon, 22 Mar 2010 20:28:22 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Black_David@emc.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] Password-Based Auth: Two criteria comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 18:27:50 -0000 Hi David, I think both of these are (correct) requirements, rather than criteria. None of the algorithms I've seen care whether it's a 6-char ASCII password, or 512 truly-random bits. None of them say anything about management (with the possible exception of the "augmented" algorithms where the "augmentation" has some bearing on management). Regarding management, -01 says this, which I think is in line with what you're saying: It is noted that some features (such as support for password expiry) and some security criteria (such as resistance to server compromise) are very important for the "teleworker" use case. This document is limited to the use of password-based authentication to achieve trust between gateways, and for this use case, these features and criteria are of questionable value. Thanks, Yaron On 22.3.2010 20:18, Black_David@emc.com wrote: > Summarizing what I said in the meeting: > > (1) The performance criteria should include performance with large complex secrets (e.g., pre-shared keys), not just the smaller passwords that people can reasonably be expected to remember. > > This is because a password-based authentication mechanism may be usefully applied to shared secret authentication implementations that derive a supposedly strong secret solely from a password (see the discussion of pre-shared key authentication in Section 2.15 of RFC 4306). Password-based authentication would provides some defense against this and other key generation weaknesses. The original password that was used to generate the shared secret may no longer be available, so good performance on large complex secrets would enable password based authentication to use the derived (supposedly strong) secret as the password. > > (2) Management (e.g., password change, password policy) is not mentioned in the criteria document. This is good. > > Keeping management orthogonal (i.e., out of scope of this criteria discussion) is (IMHO) a good thing, as management techniques and requirements may vary widely across classes of implementations. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From jun.hu@alcatel-lucent.com Mon Mar 22 12:13:13 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 409C53A69EA for ; Mon, 22 Mar 2010 12:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.99 X-Spam-Level: X-Spam-Status: No, score=0.99 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kodpy7AefwPe for ; Mon, 22 Mar 2010 12:13:12 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 191DE3A6B88 for ; Mon, 22 Mar 2010 12:13:01 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o2MJDI1k020351 for ; Mon, 22 Mar 2010 14:13:18 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o2MJDI0O027794 for ; Mon, 22 Mar 2010 14:13:18 -0500 (CDT) Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 22 Mar 2010 14:13:17 -0500 From: "Hu, Jun (Jun)" To: "ipsec@ietf.org" Date: Mon, 22 Mar 2010 14:13:23 -0500 Thread-Topic: criteria for failure detection Thread-Index: AcrJ8746oNuWfmIdRTyRvwnbz+cLuw== Message-ID: <098C866D3766674B95CCF197E1C2489B0B82631361@USNAVSXCHMBSC1.ndc.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [IPsec] criteria for failure detection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 19:13:13 -0000 Hi, First of all, I am not sure if this fit into existing "supported scenarios"= criteria or it is a new one, the failure detection time is cirtical to som= e services runs over ipsec tunnel, such services like VoIP can only tolerat= e sub-second(or 1~2 seconds max) of transport failure, otherwise the call w= ill be dropped. However , it seems to me that the current proposed solution= s all depends on reception of "INVALID_SPI" from failed node AFTER reboot w= hich usually take much longer time than 1~2 seconds. This will result to t= he interuption of those services. Of course, a good HA implementation may solve this issue, however a fast fa= ilure detection mechanism can also help the host to switch to a backup tunn= el(or other route) asap before the service got interrupted. --------------- Hu Jun =20 From ynir@checkpoint.com Mon Mar 22 12:35:36 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C493A6853 for ; Mon, 22 Mar 2010 12:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq0X+EjzhtDj for ; Mon, 22 Mar 2010 12:35:35 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 51CC53A67F0 for ; Mon, 22 Mar 2010 12:35:34 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2MJZnsd022276; Mon, 22 Mar 2010 21:35:49 +0200 (IST) X-CheckPoint: {4BA7C5ED-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 22 Mar 2010 21:36:10 +0200 From: Yoav Nir To: " " Date: Mon, 22 Mar 2010 21:35:47 +0200 Thread-Topic: [IPsec] Password-Based Auth: Two criteria comments Thread-Index: AcrJ9uxKjj7NyYd5R2aHzHBEM6MADQ== Message-ID: <62327CCC-F66A-401D-A910-60ABE31C84E1@checkpoint.com> References: In-Reply-To: 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: "ipsec@ietf.org" Subject: Re: [IPsec] Password-Based Auth: Two criteria comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 19:35:36 -0000 On Mar 22, 2010, at 11:18 AM, w= rote: > Summarizing what I said in the meeting: >=20 > (1) The performance criteria should include performance with large comple= x secrets (e.g., pre-shared keys), not just the smaller passwords that peop= le can reasonably be expected to remember. >=20 > This is because a password-based authentication mechanism may be usefully= applied to shared secret authentication implementations that derive a supp= osedly strong secret solely from a password (see the discussion of pre-shar= ed key authentication in Section 2.15 of RFC 4306). Password-based authent= ication would provides some defense against this and other key generation w= eaknesses. The original password that was used to generate the shared secr= et may no longer be available, so good performance on large complex secrets= would enable password based authentication to use the derived (supposedly = strong) secret as the password. IKE already has PSK-based authentication. If my "password" is 9975612f178b3= 1164bef5bb672cbeb1db6437d6459ff1d8a17f12ec73fcd5c92, then I don't need any = new-fangled mode, because the authentication described in section 2.15 of R= FC 4306 is good enough. The new mode we're looking for is for giving a little security for people w= ho use the password "yoav71", thinking that nobody would ever guess it.= From ynir@checkpoint.com Mon Mar 22 12:57:38 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF3D28C16B for ; Mon, 22 Mar 2010 12:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OawwXcSI91gk for ; Mon, 22 Mar 2010 12:57:37 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id C29C63A6B23 for ; Mon, 22 Mar 2010 12:57:00 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2MJvFsd024208; Mon, 22 Mar 2010 21:57:15 +0200 (IST) X-CheckPoint: {4BA7CAF2-1-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 22 Mar 2010 21:57:35 +0200 From: Yoav Nir To: Dan Harkins Date: Mon, 22 Mar 2010 21:57:12 +0200 Thread-Topic: [IPsec] synchronizing crypto state Thread-Index: AcrJ+eqO7LzHfYMPT6iGoVOZXFZb7A== Message-ID: <2C2138DA-692D-45BE-A4B5-94B339716558@checkpoint.com> References: <884e7195495b157f15c923c3ba660a99.squirrel@www.trepanning.net> In-Reply-To: <884e7195495b157f15c923c3ba660a99.squirrel@www.trepanning.net> 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 , David McGrew Subject: Re: [IPsec] synchronizing crypto state X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 19:57:38 -0000 That would be good, but we don't want to madate not using certain modes of = operation when you have a cluster. That would be very counter-productive. OTOH, because of the replay counter, we've already agreed that an outbound = child SA cannot be shared among members of a load-sharing cluster. As for the "hot standby" cluster, it *is* important to avoid repeating an I= C after failover, so precautions must be taken, and that draft David mentio= ned is one good way. However, this problem is internal to the cluster. It has nothing to do with= IKE interoperability with other peers (I don't think any peer actually ver= ifies that an IC or IV has not been previously used with the same key). The= refore, this whole discussion is out of scope for this work item. Do you agree? Yoav On Mar 22, 2010, at 11:20 AM, Dan Harkins wrote: >=20 > Hi, >=20 > Another solution is to use a cipher mode (like SIV) that does not lose > all security if a counter is reused. Then you don't have to worry at all > it. >=20 > Dan. >=20 > On Mon, March 22, 2010 9:29 am, David McGrew wrote: >> Hi Yoav, >>=20 >> another requirement for IPsec HA is to coordinate the use of distinct >> counters between multiple crypto engines. The problem (and a >> convenient solution) is described in >> http://tools.ietf.org/html/draft-ietf-msec-ipsec-group-counter-modes-05 >>=20 >> David >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Mon Mar 22 13:04:36 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6853A69A6 for ; Mon, 22 Mar 2010 13:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=-1.641, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb5s5TRO6FU9 for ; Mon, 22 Mar 2010 13:04:35 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A73373A6AFA for ; Mon, 22 Mar 2010 13:04:28 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2MK4hsd025202; Mon, 22 Mar 2010 22:04:43 +0200 (IST) X-CheckPoint: {4BA7CCB2-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 22 Mar 2010 22:05:03 +0200 From: Yoav Nir To: "Hu, Jun (Jun)" Date: Mon, 22 Mar 2010 22:04:41 +0200 Thread-Topic: [IPsec] criteria for failure detection Thread-Index: AcrJ+vXXq2q3QgUMR0iQ6yhNmhlKbw== Message-ID: <7C523A18-610F-4B3D-8BAB-0511C157F9A3@checkpoint.com> References: <098C866D3766674B95CCF197E1C2489B0B82631361@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> In-Reply-To: <098C866D3766674B95CCF197E1C2489B0B82631361@USNAVSXCHMBSC1.ndc.alcatel-lucent.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: "ipsec@ietf.org" Subject: Re: [IPsec] criteria for failure detection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 20:04:36 -0000 Failure detection by either QCD or SIR takes 1-2 roundtrips, whether this i= s subsecond or not depends on round-trip time. In case of a non-synchronized hot-standby gateway, those 2 roundtrips begin= the moment that the standby gateway becomes active, so the call probably d= oesn't get dropped. In case of a single gateway, these two roundtrips start when the gateway is= back online. - with a manual tunnel deletion, this can be immediate. - with a restart of IPsec services, this can be 10-15 seconds (for a partic= ular implementation) - with a reboot of the device, this is 0.5-2 minutes. What the work item is about, is shortening the time that the actual detecti= on takes, from the several minutes specified in RFC 4306 to something more = manageable, like two roundtrips. Without an HA implementation, this is not about keeping the current calls, = but about being able to establish new calls as soon as possible. Yoav On Mar 22, 2010, at 12:13 PM, Hu, Jun (Jun) wrote: > Hi, > First of all, I am not sure if this fit into existing "supported scenario= s" criteria or it is a new one, the failure detection time is cirtical to s= ome services runs over ipsec tunnel, such services like VoIP can only toler= ate sub-second(or 1~2 seconds max) of transport failure, otherwise the call= will be dropped. However , it seems to me that the current proposed soluti= ons all depends on reception of "INVALID_SPI" from failed node AFTER reboot= which usually take much longer time than 1~2 seconds. This will result to= the interuption of those services. >=20 > Of course, a good HA implementation may solve this issue, however a fast = failure detection mechanism can also help the host to switch to a backup tu= nnel(or other route) asap before the service got interrupted. >=20 > --------------- > Hu Jun From Black_David@emc.com Mon Mar 22 14:22:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9483A6977 for ; Mon, 22 Mar 2010 14:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.667 X-Spam-Level: X-Spam-Status: No, score=-5.667 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq2UPfn+nZxB for ; Mon, 22 Mar 2010 14:22:34 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 49C053A67E1 for ; Mon, 22 Mar 2010 14:19:58 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o2MLK7l2017210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Mar 2010 17:20:07 -0400 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Mon, 22 Mar 2010 17:20:06 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o2MLK6sN024424; Mon, 22 Mar 2010 17:20:06 -0400 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 17:20:06 -0400 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: Mon, 22 Mar 2010 17:20:04 -0400 Message-ID: In-Reply-To: <62327CCC-F66A-401D-A910-60ABE31C84E1@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Password-Based Auth: Two criteria comments Thread-Index: AcrJ9uxKjj7NyYd5R2aHzHBEM6MADQADYMGA References: <62327CCC-F66A-401D-A910-60ABE31C84E1@checkpoint.com> From: To: X-OriginalArrivalTime: 22 Mar 2010 21:20:06.0143 (UTC) FILETIME=[718158F0:01CACA05] X-EMM-EM: Active Cc: ipsec@ietf.org Subject: Re: [IPsec] Password-Based Auth: Two criteria comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 21:22:35 -0000 Yoav, > IKE already has PSK-based authentication. If my "password" is > 9975612f178b31164bef5bb672cbeb1db6437d6459ff1d8a17f12ec73fcd5c92, then I don't need any new-fangled > mode, because the authentication described in section 2.15 of RFC 4306 is good enough. If that "password" was generated from a known hash of a low entropy password with no additional entropy input (this is discussed as a possibility in Section 2.15 of 4306), that "password" is weak, and changing the hash to double the length of the output won't strengthen the result. > The new mode we're looking for is for giving a little security for people who use the password > "yoav71", thinking that nobody would ever guess it. And I'm suggesting the it may also be usefully applicable to SHA-1("yoav71") with default padding. I completely agree that "yoav71" is typical of the most important use case. I'm trying to point out that it may not be the only relevant use case. Thanks, --David > -----Original Message----- > From: Yoav Nir [mailto:ynir@checkpoint.com] > Sent: Monday, March 22, 2010 3:36 PM > To: Black, David > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Password-Based Auth: Two criteria comments >=20 >=20 > On Mar 22, 2010, at 11:18 AM, wrote: >=20 > > Summarizing what I said in the meeting: > > > > (1) The performance criteria should include performance with large complex secrets (e.g., pre-shared > keys), not just the smaller passwords that people can reasonably be expected to remember. > > > > This is because a password-based authentication mechanism may be usefully applied to shared secret > authentication implementations that derive a supposedly strong secret solely from a password (see the > discussion of pre-shared key authentication in Section 2.15 of RFC 4306). Password-based > authentication would provides some defense against this and other key generation weaknesses. The > original password that was used to generate the shared secret may no longer be available, so good > performance on large complex secrets would enable password based authentication to use the derived > (supposedly strong) secret as the password. >=20 > IKE already has PSK-based authentication. If my "password" is > 9975612f178b31164bef5bb672cbeb1db6437d6459ff1d8a17f12ec73fcd5c92, then I don't need any new-fangled > mode, because the authentication described in section 2.15 of RFC 4306 is good enough. >=20 > The new mode we're looking for is for giving a little security for people who use the password > "yoav71", thinking that nobody would ever guess it. From turners@ieca.com Mon Mar 22 18:59:19 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1DE3A680C for ; Mon, 22 Mar 2010 18:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrvcpzT2FcrN for ; Mon, 22 Mar 2010 18:59:18 -0700 (PDT) Received: from smtp114.biz.mail.sp1.yahoo.com (smtp114.biz.mail.sp1.yahoo.com [69.147.92.227]) by core3.amsl.com (Postfix) with SMTP id A240B3A6817 for ; Mon, 22 Mar 2010 18:59:18 -0700 (PDT) Received: (qmail 3033 invoked from network); 23 Mar 2010 01:59:34 -0000 Received: from dhcp-wireless-open-abg-24-191.meeting.ietf.org (turners@130.129.24.191 with plain) by smtp114.biz.mail.sp1.yahoo.com with SMTP; 22 Mar 2010 18:59:34 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: Sa64SS8VM1lAscMTvSnj0DQVGPQVy0zOaTaEJSxiBLOTtOYTveW6egEDPUY5OpEg9M39MYdJd61DADhv82LaB0J3SoiNAhdZBz5r1_VIAVLD_DB.7PIzH5PNvngoNbWNEYoT_rozf2i50Lhio4QaddI2.4ZYu.8TK5CymvajsxnIPjt5HldO44AZxsA5wnyt6ibqv_7iuBRRGAh_1AhMmVP548s0GsH3WMqbi0hNOidtMtvqMQ_ZaSFM_C37HyEhJrDebN8ay.E035F6Ag-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BA82086.1070401@ieca.com> Date: Mon, 22 Mar 2010 18:59:34 -0700 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Password-Based Auth: One criteria comment X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 01:59:19 -0000 Criteria: the scheme must support arbitrary octets as the input. I don't want to pick one that doesn't support whatever the current/future IETF character set encoding is. spt From psethi@cisco.com Tue Mar 23 05:23:03 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093C33A6B0C for ; Tue, 23 Mar 2010 05:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.868 X-Spam-Level: X-Spam-Status: No, score=-6.868 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SWAqyyYbwCH for ; Tue, 23 Mar 2010 05:23:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3A15F3A6A05 for ; Tue, 23 Mar 2010 05:19:12 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.51,294,1267401600"; d="scan'208,217";a="170818278" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 23 Mar 2010 12:19:30 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2NCJTN0009632; Tue, 23 Mar 2010 12:19:29 GMT Received: from xfe-bgl-412.cisco.com ([72.163.129.200]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 17:49:28 +0530 Received: from [64.103.239.117] ([64.103.239.117]) by xfe-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 17:49:28 +0530 Message-ID: <4BA8B1CF.7030407@cisco.com> Date: Tue, 23 Mar 2010 17:49:27 +0530 From: Pratima Sethi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Yaron Sheffer References: <38A5FB2E-CD22-45D1-B941-9519F961A033@cisco.com> <4BA78E61.3080001@gmail.com> In-Reply-To: <4BA78E61.3080001@gmail.com> Content-Type: multipart/alternative; boundary="------------080302090904040706050207" X-OriginalArrivalTime: 23 Mar 2010 12:19:28.0184 (UTC) FILETIME=[15635B80:01CACA83] Cc: IPsecme WG , Frederic Detienne , Paul Hoffman Subject: Re: [IPsec] IPR statement for draft-detienne-ikev2-recovery X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 12:23:03 -0000 This is a multi-part message in MIME format. --------------080302090904040706050207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Yaron, thanks for clarifying the situation. The overall disclosure process still somewhat escaped us and we were unclear as to when such statements need to be published. If we made a mistake, I hereby apologize; we know better now. We mainly wanted to clear our names of any malicious intent. I am glad that memory has been restored. regards, - prati On 3/22/2010 9:06 PM, Yaron Sheffer wrote: > Hi Frederic, > > this is correct, however we did not share this information because it > was an individual submission at the time, and we expected Cisco to do > the right thing, i.e. to inform the WG in a timely manner (and later, > we simply forgot). > > For some reason, Cisco chose to publish the IPR statement more than a > year after the application was published by the patent office. It was > Cisco's responsibility, and your personal responsibility, to follow > IETF due process here. > > Thanks, > Yaron > > On 22.3.2010 17:16, Frederic Detienne wrote: >> Hi Paul, >> >> I am still puzzled that you see fit to check in private with Yoav and >> in public with us. >> >> For the records, at least one of the co-chairs (Yaron) was advised >> about the IPR at the same time as Yoav. >> >> regards, >> >> fred >> >> On 22 Mar 2010, at 15:09, Paul Hoffman wrote: >> >>> At 9:51 AM +0100 3/22/10, Frederic Detienne wrote: >>>> I am afraid you are mistaken. Yoav, Yaron, Pratima and I had a >>>> discussion about the draft's IPR back in Dublin in July 2008. We >>>> told back then that we would have rights released. The process >>>> takes its own time but as far as Pratima and I are concerned, we >>>> did due diligence. >>> >>> Thank you. >>> >>>> Will you share your assumptions directly with us next time ? >>> >>> As WG co-chair, I need to trust the words and intentions of active >>> WG contributors as much as I can. When the Cisco IPR statement for >>> SIR came out, I was surprised, so I asked your co-author, Yoav Nir, >>> about whether he had known about it. His response was that he had >>> not known about it until after Cisco's recent IPR statement. I took >>> him at his word. >>> >>> To be clear: this is not a matter of which one of you is telling the >>> truth. It is quite easy that one of you misunderstood the other >>> because the discussion of SIR and QCD had gotten mixed up with the >>> discussion of session resumption and maybe-related topics. There is, >>> I believe, a chance that you told *me* about the pending patent and >>> I forgot. I doubt that, but I also admit to having prejudices about >>> IPR and so on that would cause me to have less-than-perfect memory. >>> I cut you and Yoav the same slack I cut myself. >>> >>> To be clear, part 2: the patent situation with SIR has not affected >>> the WG's decision yet. There are plenty of companies whose generic >>> IETF patent licenses are similar to those offered by Cisco for SIR. >>> That is why my message to the WG informing them of Cisco's IPR >>> statement said "Before reacting to this announcement, please review >>> the IETF's IPR policy". Knee-jerk reactions to IPR statements can >>> cause more damage in the IETF than IPR statements themselves. >>> >>> I still stand by my statement that I would have preferred Cisco to >>> issue the statement when we were discussing listing SIR in the >>> charter in this current round: more information is always good. I >>> apologize for saying "at least one of the co-authors on the named >>> draft was not informed of the IPR"; I could have said "I have heard >>> that at least one of the co-authors on the named draft was not >>> informed of the IPR", which is a more accurate statement. >>> >>> --Paul Hoffman, Director >>> --VPN Consortium >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > --------------080302090904040706050207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Yaron,

thanks for clarifying the situation.

The overall disclosure process still somewhat escaped us and we were unclear as to when such statements need to be published.

If we made a mistake, I hereby apologize; we know better now.

We mainly wanted to clear our names of any malicious intent. I am glad that memory has been restored.

regards,
- prati

 

On 3/22/2010 9:06 PM, Yaron Sheffer wrote:
Hi Frederic,

this is correct, however we did not share this information because it was an individual submission at the time, and we expected Cisco to do the right thing, i.e. to inform the WG in a timely manner (and later, we simply forgot).

For some reason, Cisco chose to publish the IPR statement more than a year after the application was published by the patent office. It was Cisco's responsibility, and your personal responsibility, to follow IETF due process here.

Thanks,
    Yaron

On 22.3.2010 17:16, Frederic Detienne wrote:
Hi Paul,

I am still puzzled that you see fit to check in private with Yoav and in public with us.

For the records, at least one of the co-chairs (Yaron) was advised about the IPR at the same time as Yoav.

regards,

    fred

On 22 Mar 2010, at 15:09, Paul Hoffman wrote:

At 9:51 AM +0100 3/22/10, Frederic Detienne wrote:
I am afraid you are mistaken. Yoav, Yaron, Pratima and I had a discussion about the draft's IPR back in Dublin in July 2008. We told back then that we would have rights released. The process takes its own time but as far as Pratima and I are concerned, we did due diligence.

Thank you.

Will you share your assumptions directly with us next time ?

As WG co-chair, I need to trust the words and intentions of active WG contributors as much as I can. When the Cisco IPR statement for SIR came out, I was surprised, so I asked your co-author, Yoav Nir, about whether he had known about it. His response was that he had not known about it until after Cisco's recent IPR statement. I took him at his word.

To be clear: this is not a matter of which one of you is telling the truth. It is quite easy that one of you misunderstood the other because the discussion of SIR and QCD had gotten mixed up with the discussion of session resumption and maybe-related topics. There is, I believe, a chance that you told *me* about the pending patent and I forgot. I doubt that, but I also admit to having prejudices about IPR and so on that would cause me to have less-than-perfect memory. I cut you and Yoav the same slack I cut myself.

To be clear, part 2: the patent situation with SIR has not affected the WG's decision yet. There are plenty of companies whose generic IETF patent licenses are similar to those offered by Cisco for SIR. That is why my message to the WG informing them of Cisco's IPR statement said "Before reacting to this announcement, please review the IETF's IPR policy". Knee-jerk reactions to IPR statements can cause more damage in the IETF than IPR statements themselves.

I still stand by my statement that I would have preferred Cisco to issue the statement when we were discussing listing SIR in the charter in this current round: more information is always good. I apologize for saying "at least one of the co-authors on the named draft was not informed of the IPR"; I could have said "I have heard that at least one of the co-authors on the named draft was not informed of the IPR", which is a more accurate statement.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--------------080302090904040706050207-- From wwwrun@core3.amsl.com Tue Mar 23 08:41:03 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D669F3A6C41; Tue, 23 Mar 2010 08:41:03 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100323154103.D669F3A6C41@core3.amsl.com> Date: Tue, 23 Mar 2010 08:41:03 -0700 (PDT) Cc: ipsecme mailing list , ipsecme chair , Internet Architecture Board , RFC Editor Subject: [IPsec] Document Action: 'Heuristics for Detecting ESP-NULL packets' to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 15:41:04 -0000 The IESG has approved the following document: - 'Heuristics for Detecting ESP-NULL packets ' as an Informational RFC This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-07.txt Technical Summary This document describes a set of heuristics for distinguishing IPsec ESP-null (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, such as traffic analyzers and deep inspection engines, to quickly decide whether given packet flow is interesting or not. Use of these heuristics does not require any changes made on existing RFC 4303 compliant IPsec hosts. Working Group Summary Early on there was prolonged WG discussion about the relative merits of the Wrapped ESP solution for identifying ESP-null traffic, compared to heuristic methods for traffic inspection. Eventually the WG reached consensus on the usefulness of having both solutions published, with the heuristics solution targeted for the interim period until WESP is widely deployed. This consensus is documented in both protocol documents. Document Quality Currently, there are no known implementations. Personnel The document shepherd is Yaron Sheffer, and the responsible area director is Pasi Eronen. From rdv@sfc.wide.ad.jp Tue Mar 23 10:58:53 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AA73A6C32 for ; Tue, 23 Mar 2010 10:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.766 X-Spam-Level: X-Spam-Status: No, score=-94.766 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_22=0.6, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLPKX2wEzV4s for ; Tue, 23 Mar 2010 10:58:52 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id D4E5B3A6D02 for ; Tue, 23 Mar 2010 10:46:20 -0700 (PDT) Received: from [IPv6:2001:df8::24:223:6cff:fe91:9b42] (unknown [IPv6:2001:df8:0:24:223:6cff:fe91:9b42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C9BE84DC57 for ; Wed, 24 Mar 2010 02:46:28 +0900 (JST) Message-Id: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> From: Rodney Van Meter To: ipsec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Mar 2010 02:46:26 +0900 X-Mailer: Apple Mail (2.936) Subject: [IPsec] HA/LS terminology X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:58:53 -0000 I am *NOT* an expert on fault tolerance, but I have studied it a little (long ago, if not so far away), and I worked on Network Alchemy's fault tolerant implementation of an IPsec gateway (a decade ago, and a little farther away). So, some suggestions on the terminology for the HA&LS draft. Terminology: "High Availability" refers to a gateway or cluster whose expected downtime is low on e.g. an annual basis. High availability may be achieved using fault tolerant techniques such as hardware/software clustering. It may also be achieved by e.g. using extremely robust components and having a very low reboot time. "Fault Tolerant" refers to a gateway or cluster that will maintain service availability even when a specified set of fault conditions occurs, such as the loss of one or more cluster members to a hardware or software fault. Clusters whose purpose is improving availability may operate using a "hot standby" model, in which one or more gateways is active and one or more gateways is held in reserve and activated when the failure of an active member is detected. Clusters whose purpose is improving scalability (of performance, number of active connections, etc.), using a "load sharing" model, have more than one member active. IPsec gateways must be prepared for their peers to lose state, e.g. as a result of a reboot, resulting in each peer attempting to reconnect. The latency of that reconnection, and the computational load of reconnecting a large number of peers, means that a fast-rebooting gateway alone is not sufficient to provide high availability service, driving the need for fault tolerance in an IPsec gateway implementation. If a fault is never visible to peers, the cluster is said to be "completely transparent". If some peers must reconnect, or a change of IP address is visible, the cluster is said to be "partially transparent". It is possible to create an implementation with lazy synchronization or an otherwise incompletely redundant state, resulting in e.g. a few percent of peers (or a few percent probability of any given peer) being aware of the fault. --Rod From shore@arsc.edu Tue Mar 23 13:42:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8713A69F2 for ; Tue, 23 Mar 2010 13:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.731 X-Spam-Level: * X-Spam-Status: No, score=1.731 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpUKAmjomDdo for ; Tue, 23 Mar 2010 13:42:11 -0700 (PDT) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id BC5DC3A6B63 for ; Tue, 23 Mar 2010 13:42:09 -0700 (PDT) Received: from webmail.arsc.edu (web4.arsc.edu [199.165.84.246]) by arsc.edu (20090828.ARSC) with ESMTP id o2NKgJdi016028; Tue, 23 Mar 2010 12:42:21 -0800 (AKDT) Received: from 2001:df8:0:24:225:d3ff:fed5:7b05 by webmail.arsc.edu with HTTP; Tue, 23 Mar 2010 12:42:22 -0800 (ADT) Message-ID: <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> In-Reply-To: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> Date: Tue, 23 Mar 2010 12:42:22 -0800 (ADT) From: "Melinda Shore" To: "Rodney Van Meter" User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-CanIt-Geo: ip=199.165.84.246; country=US; region=AK; city=Fairbanks; postalcode=99775; latitude=64.8834; longitude=-147.4984; metrocode=745; areacode=907; http://maps.google.com/maps?q=64.8834,-147.4984&z=6 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 199.165.84.167 Cc: ipsec@ietf.org Subject: Re: [IPsec] HA/LS terminology X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:42:11 -0000 On Tue, March 23, 2010 9:46 am, Rodney Van Meter wrote: > I am *NOT* an expert on fault tolerance, but I have studied it a > little (long ago, if not so far away), and I worked on Network > Alchemy's fault tolerant implementation of an IPsec gateway (a decade > ago, and a little farther away). So, some suggestions on the > terminology for the HA&LS draft. [ ... ] I think this is a really nice taxonomy and think it might be useful to integrate it nearly as-is into the HA document. Melinda From rdv@sfc.wide.ad.jp Tue Mar 23 13:51:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C774D3A6B62 for ; Tue, 23 Mar 2010 13:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.675 X-Spam-Level: X-Spam-Status: No, score=-94.675 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDSPzUGUPc+E for ; Tue, 23 Mar 2010 13:51:30 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id D3D3A3A6B0C for ; Tue, 23 Mar 2010 13:51:29 -0700 (PDT) Received: from dhcp-wireless-open-abg-29-110.meeting.ietf.org (dhcp-wireless-open-abg-29-110.meeting.ietf.org [130.129.29.110]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9ABED4C5A7; Wed, 24 Mar 2010 05:51:42 +0900 (JST) From: Rodney Van Meter To: "Melinda Shore" In-Reply-To: <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> X-Priority: 3 (Normal) References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> Message-Id: <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Mar 2010 05:51:41 +0900 X-Mailer: Apple Mail (2.936) Cc: ipsec@ietf.org Subject: Re: [IPsec] HA/LS terminology X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:51:30 -0000 > > I think this is a really nice taxonomy and think it might be useful > to integrate it nearly as-is into the HA document. > Go for it. I can't promise more help (I'm in workload-shedding rather than workload-accreting mode right now), but if it's useful, it was worth an hour of my time to write up. There *must* be a standard textbook/reference on FT/HA, but I'm out of date. --Rod From ynir@checkpoint.com Tue Mar 23 14:20:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5000E3A6C89 for ; Tue, 23 Mar 2010 14:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njz9bxHqP5yW for ; Tue, 23 Mar 2010 14:20:33 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 52C4C3A6C87 for ; Tue, 23 Mar 2010 14:20:31 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2NLKVsd004359; Tue, 23 Mar 2010 23:20:31 +0200 (IST) X-CheckPoint: {4BA92FE8-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 23 Mar 2010 23:20:52 +0200 From: Yoav Nir To: Rodney Van Meter Date: Tue, 23 Mar 2010 23:20:28 +0200 Thread-Topic: Issue #177. (was: HA/LS terminology) Thread-Index: AcrKzrayy2IIP9LJTpuRJYqHtPnU4Q== Message-ID: <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> In-Reply-To: <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> 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: "ipsec@ietf.org" , Melinda Shore Subject: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:20:35 -0000 And thank you for taking the time, Rod. The linktionary has a pretty good definition, though I don't know if it cou= nts as "textbook". Same for Wikipedia http://www.linktionary.com/f/fault_tolerance.html http://en.wikipedia.org/wiki/Fault-tolerant_system Anyway, we need to limit the scope of this document. I think we're only int= erested in clusters that provide high-availability, that are, to use your t= erms, completely or partially transparent. Also, while there could be clusters with m members, where n, such that 1<= =3Dn<=3Dm, are active, for the purposes of the discussion it is enough to a= ssume that we're dealing with two types of high-availability, mostly transp= arent clusters: - Those where exactly one does IKE and IPsec, and the rest just synchronize= state, and - Those where more than one member are doing IKE and IPsec, all the time sy= nchronizing state. This taxonomy is needed, because some of the problems that affect one clust= er type do not affect the other. So I propose the following terms, and these are not for generic clusters pr= oviding generic services to the generic Internet, but only for the purposes= of this work item in this working group. - For the cluster with just one member doing IKE and IPsec, I propose "hot-= standby cluster" - For the cluster with several members doing IKE and IPsec, I propose to ke= ep "load-sharing cluster" Is this fine with everyone? Yoav On Mar 23, 2010, at 1:51 PM, Rodney Van Meter wrote: >>=20 >> I think this is a really nice taxonomy and think it might be useful >> to integrate it nearly as-is into the HA document. >>=20 >=20 > Go for it. I can't promise more help (I'm in workload-shedding rather =20 > than workload-accreting mode right now), but if it's useful, it was =20 > worth an hour of my time to write up. >=20 > There *must* be a standard textbook/reference on FT/HA, but I'm out of =20 > date. >=20 > --Rod From rdv@sfc.wide.ad.jp Tue Mar 23 14:30:36 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BF03A6891 for ; Tue, 23 Mar 2010 14:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.141 X-Spam-Level: X-Spam-Status: No, score=-95.141 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwhVJOW2JRWw for ; Tue, 23 Mar 2010 14:30:32 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 37F823A6D0B for ; Tue, 23 Mar 2010 14:30:09 -0700 (PDT) Received: from [IPv6:2001:df8::24:223:6cff:fe91:9b42] (unknown [IPv6:2001:df8:0:24:223:6cff:fe91:9b42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B73BD4DC87; Wed, 24 Mar 2010 06:30:24 +0900 (JST) Message-Id: <51E62BEE-0A11-43E4-8301-E83ED1BCEA8A@sfc.wide.ad.jp> From: Rodney Van Meter To: Yoav Nir In-Reply-To: <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Mar 2010 06:30:22 +0900 References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> X-Mailer: Apple Mail (2.936) Cc: "ipsec@ietf.org" , Melinda Shore Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:30:36 -0000 On Mar 24, 2010, at 6:20 AM, Yoav Nir wrote: > > - For the cluster with just one member doing IKE and IPsec, I > propose "hot-standby cluster" > - For the cluster with several members doing IKE and IPsec, I > propose to keep "load-sharing cluster" > > Is this fine with everyone? > I'm good with that, as long as we understand that both types of cluster may be either completely fault tolerant, partially fault tolerant, or not fault tolerant. Of course, the taxonomy is simpler with only FT/not-FT, and most implementations will probably strive to be one or the other. --Rod From shore@arsc.edu Tue Mar 23 14:31:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D353A6CBB for ; Tue, 23 Mar 2010 14:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxBfcg1udMlr for ; Tue, 23 Mar 2010 14:31:58 -0700 (PDT) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id EC4BD3A6891 for ; Tue, 23 Mar 2010 14:31:56 -0700 (PDT) Received: from webmail.arsc.edu (web4.arsc.edu [199.165.84.246]) by arsc.edu (20090828.ARSC) with ESMTP id o2NLVrdl019086; Tue, 23 Mar 2010 13:31:53 -0800 (AKDT) Received: from 2001:df8:0:24:225:d3ff:fed5:7b05 by webmail.arsc.edu with HTTP; Tue, 23 Mar 2010 13:31:57 -0800 (ADT) Message-ID: <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> In-Reply-To: <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> Date: Tue, 23 Mar 2010 13:31:57 -0800 (ADT) From: "Melinda Shore" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-CanIt-Geo: ip=199.165.84.246; country=US; region=AK; city=Fairbanks; postalcode=99775; latitude=64.8834; longitude=-147.4984; metrocode=745; areacode=907; http://maps.google.com/maps?q=64.8834,-147.4984&z=6 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 199.165.84.167 Cc: Rodney Van Meter , "ipsec@ietf.org" , Melinda Shore Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:31:59 -0000 On Tue, March 23, 2010 1:20 pm, Yoav Nir wrote: > - For the cluster with just one member doing IKE and IPsec, I propose > "hot-standby cluster" > - For the cluster with several members doing IKE and IPsec, I propose to > keep "load-sharing cluster" I think "failover" is in broader use than "hot standby" and would tend to prefer it myself, but I think either is clear. Melinda From rdv@sfc.wide.ad.jp Tue Mar 23 14:35:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714983A6C73 for ; Tue, 23 Mar 2010 14:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.186 X-Spam-Level: X-Spam-Status: No, score=-95.186 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnVsOzGnGkq5 for ; Tue, 23 Mar 2010 14:35:33 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 89EAB3A6BCE for ; Tue, 23 Mar 2010 14:35:29 -0700 (PDT) Received: from [IPv6:2001:df8::24:223:6cff:fe91:9b42] (unknown [IPv6:2001:df8:0:24:223:6cff:fe91:9b42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A2F3E4D957; Wed, 24 Mar 2010 06:35:41 +0900 (JST) From: Rodney Van Meter To: "Melinda Shore" In-Reply-To: <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> X-Priority: 3 (Normal) References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> Message-Id: <7851CFA5-E9BD-489B-8757-1BC69EF6729D@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Mar 2010 06:35:39 +0900 X-Mailer: Apple Mail (2.936) Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:35:34 -0000 On Mar 24, 2010, at 6:31 AM, Melinda Shore wrote: > On Tue, March 23, 2010 1:20 pm, Yoav Nir wrote: >> - For the cluster with just one member doing IKE and IPsec, I propose >> "hot-standby cluster" >> - For the cluster with several members doing IKE and IPsec, I >> propose to >> keep "load-sharing cluster" > > I think "failover" is in broader use than "hot standby" > and would tend to prefer it myself, but I think either is clear. > I'm okay with "failover cluster" as a description of the cluster type. For the node itself, I think referring to it as the "hot standby node" is probably a little clearer than the "failover node". But I'm okay either way, I'll leave it to the actual document editor. From ynir@checkpoint.com Tue Mar 23 14:43:01 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828873A68EA for ; Tue, 23 Mar 2010 14:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO3S73nrohc7 for ; Tue, 23 Mar 2010 14:43:00 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 545D13A68BB for ; Tue, 23 Mar 2010 14:43:00 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2NLh3sd006976; Tue, 23 Mar 2010 23:43:03 +0200 (IST) X-CheckPoint: {4BA93530-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 23 Mar 2010 23:43:24 +0200 From: Yoav Nir To: Melinda Shore Date: Tue, 23 Mar 2010 23:43:01 +0200 Thread-Topic: Issue #177. (was: HA/LS terminology) Thread-Index: AcrK0dzQWQzKTBwXTGikqOJAicUSHQ== Message-ID: <3B0BF1DE-83E0-413E-A09E-146F8B2C7C9B@checkpoint.com> References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> In-Reply-To: <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> 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: Rodney Van Meter , "ipsec@ietf.org" Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:43:01 -0000 On Mar 23, 2010, at 2:31 PM, Melinda Shore wrote: > On Tue, March 23, 2010 1:20 pm, Yoav Nir wrote: >> - For the cluster with just one member doing IKE and IPsec, I propose >> "hot-standby cluster" >> - For the cluster with several members doing IKE and IPsec, I propose to >> keep "load-sharing cluster" >=20 > I think "failover" is in broader use than "hot standby" > and would tend to prefer it myself, but I think either is clear. >=20 > Melinda >=20 I did not want to use "fault tolerant" because some would take that term is= broad and sometimes taken to mean things I would not like to specify, like= RAID arrays, and dual power supplies. I don't think we should use this it= em to mandate that the two cluster members should not be connected to the s= ame power strip. Anyway, "failover cluster" is OK, except that we've already used "failover"= to describe an event that happens to both types of clusters. So I think w= e can stay with "hot standby" and "load sharing" Yoav From dharkins@lounge.org Tue Mar 23 18:05:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01FCC3A6BD1 for ; Tue, 23 Mar 2010 18:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DhtLSfiFxou for ; Tue, 23 Mar 2010 18:05:32 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id E424C3A6BB2 for ; Tue, 23 Mar 2010 18:05:32 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 03AF91022404A; Tue, 23 Mar 2010 18:05:52 -0700 (PDT) Received: from 130.129.26.143 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 23 Mar 2010 18:05:52 -0700 (PDT) Message-ID: In-Reply-To: <3B0BF1DE-83E0-413E-A09E-146F8B2C7C9B@checkpoint.com> References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> <3B0BF1DE-83E0-413E-A09E-146F8B2C7C9B@checkpoint.com> Date: Tue, 23 Mar 2010 18:05:52 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" 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: Rodney Van Meter , "ipsec@ietf.org" , Melinda Shore Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 01:05:34 -0000 Hi, "hot standby" implies a box sitting ("hot") twiddling its thumbs doing little but waiting for another box to fail ("standby"). It's the VRRP model. There is a HA model which supports dynamic load balancing as well as active session failover. Nodes in such a cluster are not "standby". They each have loads that they can shed and add to based upon some heuristic. A neat attribute of such a system is that an IPsec SA can be established on node A, move to node B after a while, and come back to A some time later without any actual node failure. State moves around to keep the cluster balanced. I would very much prefer "session failover" to "hot standby" and a mild preference of "load balancing" over "load sharing". An HA model doing VRRP could be termed "session failover" but the HA model described above really can't be called "hot standby". And load can be shared but just sharing a load can result in a mis-balanced cluster if sessions on one node terminate naturally and it sits doing little while another node whose sessions haven't terminated is huffing-and-puffing. Balancing can imply sharing but not vice versa. regards, Dan. On Tue, March 23, 2010 2:43 pm, Yoav Nir wrote: > On Mar 23, 2010, at 2:31 PM, Melinda Shore wrote: > >> On Tue, March 23, 2010 1:20 pm, Yoav Nir wrote: >>> - For the cluster with just one member doing IKE and IPsec, I propose >>> "hot-standby cluster" >>> - For the cluster with several members doing IKE and IPsec, I propose >>> to >>> keep "load-sharing cluster" >> >> I think "failover" is in broader use than "hot standby" >> and would tend to prefer it myself, but I think either is clear. >> >> Melinda >> > I did not want to use "fault tolerant" because some would take that term > is broad and sometimes taken to mean things I would not like to specify, > like RAID arrays, and dual power supplies. I don't think we should use > this item to mandate that the two cluster members should not be connected > to the same power strip. > > Anyway, "failover cluster" is OK, except that we've already used > "failover" to describe an event that happens to both types of clusters. > So I think we can stay with "hot standby" and "load sharing" > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Tue Mar 23 19:24:32 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B37E3A67E1 for ; Tue, 23 Mar 2010 19:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-HoEKwxZh4J for ; Tue, 23 Mar 2010 19:24:31 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id DB6253A672E for ; Tue, 23 Mar 2010 19:24:30 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2O2OWsd026790; Wed, 24 Mar 2010 04:24:32 +0200 (IST) X-CheckPoint: {4BA97726-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 24 Mar 2010 04:24:53 +0200 From: Yoav Nir To: Dan Harkins Date: Wed, 24 Mar 2010 04:24:30 +0200 Thread-Topic: [IPsec] Issue #177. (was: HA/LS terminology) Thread-Index: AcrK+S+wAUq31EkTQ26Nyy/cyY/g9A== Message-ID: <6AA54FAA-419E-4887-9801-227AABBCD702@checkpoint.com> References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> <3B0BF1DE-83E0-413E-A09E-146F8B2C7C9B@checkpoint.com> In-Reply-To: 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: Rodney Van Meter , "ipsec@ietf.org" , Melinda Shore Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 02:24:32 -0000 On Mar 23, 2010, at 6:05 PM, Dan Harkins wrote: >=20 > Hi, >=20 > "hot standby" implies a box sitting ("hot") twiddling its thumbs doing > little but waiting for another box to fail ("standby"). It's the VRRP > model. And that's exactly what I want to describe. Well, not twiddling its thumbs.= The standby is synchronizing state with the active member, but it's not do= ing any IKE or IPsec >=20 > There is a HA model which supports dynamic load balancing as well as > active session failover. Nodes in such a cluster are not "standby". They > each have loads that they can shed and add to based upon some heuristic. > A neat attribute of such a system is that an IPsec SA can be established > on node A, move to node B after a while, and come back to A some time > later without any actual node failure. State moves around to keep the > cluster balanced. Failure is just used as an example of why a certain SA failed over to anoth= er member. It is by no means the only reason. Still, what you are describin= g is a model that provides both high-availability and load balancing, and t= hat is the reason we're moving away from calling the first model "high avai= lability". >=20 > I would very much prefer "session failover" to "hot standby" and a > mild preference of "load balancing" over "load sharing". An HA model > doing VRRP could be termed "session failover" but the HA model described > above really can't be called "hot standby". And load can be shared but > just sharing a load can result in a mis-balanced cluster if sessions on > one node terminate naturally and it sits doing little while another node > whose sessions haven't terminated is huffing-and-puffing. Balancing can > imply sharing but not vice versa. "Session failover" sounds to me more like a description of an event than a = type of cluster. >=20 > regards, >=20 > Dan. From dharkins@lounge.org Wed Mar 24 00:45:44 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98B23A6A4A for ; Wed, 24 Mar 2010 00:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euoQ0G3NhjQp for ; Wed, 24 Mar 2010 00:45:44 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id EFE5A3A6A49 for ; Wed, 24 Mar 2010 00:45:43 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D1DC61022404A; Wed, 24 Mar 2010 00:46:03 -0700 (PDT) Received: from 130.129.26.143 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 24 Mar 2010 00:46:04 -0700 (PDT) Message-ID: <03e919e078c06550481ad5f272511dd0.squirrel@www.trepanning.net> In-Reply-To: <6AA54FAA-419E-4887-9801-227AABBCD702@checkpoint.com> References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> <3B0BF1DE-83E0-413E-A09E-146F8B2C7C9B@checkpoint.com> <6AA54FAA-419E-4887-9801-227AABBCD702@checkpoint.com> Date: Wed, 24 Mar 2010 00:46:04 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" 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: Rodney Van Meter , "ipsec@ietf.org" , Melinda Shore , Dan Harkins Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 07:45:44 -0000 On Tue, March 23, 2010 7:24 pm, Yoav Nir wrote: > > On Mar 23, 2010, at 6:05 PM, Dan Harkins wrote: > >> >> Hi, >> >> "hot standby" implies a box sitting ("hot") twiddling its thumbs doing >> little but waiting for another box to fail ("standby"). It's the VRRP >> model. > > And that's exactly what I want to describe. Well, not twiddling its > thumbs. The standby is synchronizing state with the active member, but > it's not doing any IKE or IPsec Well don't use such a limiting term to describe a behavior that is not so limited. Not all HA is that small subset you want to describe. >> There is a HA model which supports dynamic load balancing as well as >> active session failover. Nodes in such a cluster are not "standby". They >> each have loads that they can shed and add to based upon some heuristic. >> A neat attribute of such a system is that an IPsec SA can be established >> on node A, move to node B after a while, and come back to A some time >> later without any actual node failure. State moves around to keep the >> cluster balanced. > > Failure is just used as an example of why a certain SA failed over to > another member. It is by no means the only reason. Still, what you are > describing is a model that provides both high-availability and load > balancing, and that is the reason we're moving away from calling the first > model "high availability". Of course it's not the only reason. But you're missing the point. The point is that the reason doesn't matter! You want to describe a particular reason-- the "master" crashed and all state went over to the "hot standby"-- not the generic concept of state moving. So don't call it "high availability" then. But "hot standby" is worse. >> I would very much prefer "session failover" to "hot standby" and a >> mild preference of "load balancing" over "load sharing". An HA model >> doing VRRP could be termed "session failover" but the HA model described >> above really can't be called "hot standby". And load can be shared but >> just sharing a load can result in a mis-balanced cluster if sessions on >> one node terminate naturally and it sits doing little while another node >> whose sessions haven't terminated is huffing-and-puffing. Balancing can >> imply sharing but not vice versa. > > "Session failover" sounds to me more like a description of an event than a > type of cluster. So what? Are you suggesting that a type of cluster that is not a "hot standby" is not worthy of terminology in IPsecME? Your term is severely limiting. I like "session failover". If you don't then come up with a term that generically describes HA and not the particular style of HA that you are accustomed to. Dan. From shore@arsc.edu Wed Mar 24 07:29:15 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7463A6A41 for ; Wed, 24 Mar 2010 07:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFLKn4otBcm7 for ; Wed, 24 Mar 2010 07:29:14 -0700 (PDT) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id E0CF63A6A39 for ; Wed, 24 Mar 2010 07:29:12 -0700 (PDT) Received: from webmail.arsc.edu (web4.arsc.edu [199.165.84.246]) by arsc.edu (20090828.ARSC) with ESMTP id o2OET9bD014971; Wed, 24 Mar 2010 06:29:10 -0800 (AKDT) Received: from 2001:df8:0:24:225:d3ff:fed5:7b05 by webmail.arsc.edu with HTTP; Wed, 24 Mar 2010 06:29:11 -0800 (ADT) Message-ID: <2a15cb8fa4dd280013f4fb77ff6f46ca.squirrel@webmail.arsc.edu> In-Reply-To: <03e919e078c06550481ad5f272511dd0.squirrel@www.trepanning.net> References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> <3B0BF1DE-83E0-413E-A09E-146F8B2C7C9B@checkpoint.com> <6AA54FAA-419E-4887-9801-227AABBCD702@checkpoint.com> <03e919e078c06550481ad5f272511dd0.squirrel@www.trepanning.net> Date: Wed, 24 Mar 2010 06:29:11 -0800 (ADT) From: "Melinda Shore" To: "Dan Harkins" User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-CanIt-Geo: ip=199.165.84.246; country=US; region=AK; city=Fairbanks; postalcode=99775; latitude=64.8834; longitude=-147.4984; metrocode=745; areacode=907; http://maps.google.com/maps?q=64.8834,-147.4984&z=6 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 199.165.84.167 Cc: Rodney Van Meter , "ipsec@ietf.org" , Melinda Shore , Yoav Nir , Dan Harkins Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 14:29:15 -0000 On Tue, March 23, 2010 11:46 pm, Dan Harkins wrote: > Of course it's not the only reason. But you're missing the point. The > point is that the reason doesn't matter! You want to describe a particular > reason-- the "master" crashed and all state went over to the "hot > standby"-- > not the generic concept of state moving. Yes, I think this is my issue with the choice of "hot standby," as well - there's an implication that they're not sharing state and that failing over looks from the outside like a reboot. Melinda From yaronf.ietf@gmail.com Wed Mar 24 23:46:09 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3773A6C30 for ; Wed, 24 Mar 2010 23:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.75 X-Spam-Level: * X-Spam-Status: No, score=1.75 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXXyExOPjbw9 for ; Wed, 24 Mar 2010 23:46:08 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 56F353A6452 for ; Wed, 24 Mar 2010 23:46:08 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1271690fgb.13 for ; Wed, 24 Mar 2010 23:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=OxbIA7Oc6lkJUTdeAqreISZWlauNKj6db4fNdREGiag=; b=lj9xwqWvk0Xx2UqOPrSBwzZ67MojAJqtgqClV7YorLbdOFGR9Ys1tRmfZ8cASezD1G W/gA4mPWvilypXAyUAkkqjwt087fhEiYRtAiFplHRSILVjyiN6WehdKyXWhyVm9BXtHR IhTlfyBixM/DlhvQW7AH63oC5AuZXjTjIO95Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=rlucklmlnxfj6nyh/7no7HhsysMDL3vhceERqu6CRep7PNVxEpbXQhP+4subgMC+8Y 3dOb0nZj/n+2veuGLJgdQpif6XhW6dpYtrT1j6nCFtkhzR4uZjA4JqLNCM7TzuATrdkx gRNiujcaS+Cg10OUxNDEb91xgiLTOIN/v3f48= Received: by 10.87.73.13 with SMTP id a13mr1237837fgl.44.1269499584862; Wed, 24 Mar 2010 23:46:24 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id l12sm2458155fgb.22.2010.03.24.23.46.24 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Mar 2010 23:46:24 -0700 (PDT) Message-ID: <4BAB06D4.3030907@gmail.com> Date: Thu, 25 Mar 2010 08:46:44 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] New PAKE Criteria draft posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 06:46:09 -0000 Hi, after the good discussion in Anaheim, and with the help of comments received on and off the list, I have updated the PAKE Criteria draft and posted it as http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. I have added a number of criteria, clarified others, and added numbering (SEC1-SEC6, IPR1-IPR3 etc.). Thanks, Yaron From rsjenwar@gmail.com Wed Mar 24 23:48:16 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105913A6452 for ; Wed, 24 Mar 2010 23:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhJmb-V3awTJ for ; Wed, 24 Mar 2010 23:48:15 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id BCD673A6CA8 for ; Wed, 24 Mar 2010 23:48:14 -0700 (PDT) Received: by gwj23 with SMTP id 23so1535560gwj.31 for ; Wed, 24 Mar 2010 23:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZteBYVoH3J/2bW2uOQlhLNzB+QN9iNoqlGfu/J0wCyA=; b=TP/ueWzbptls4kJZH87bHqCwClaxCix6ClRBKIxGzjl9/iQNODbX7drBFusEKNTSac yDjh7BssqRa3RQZRXbYrfb0dWeUh0P5iOpv0jwxBrbJOOZXhyyz5eJWH8hmd1te9AeLe t8wNxBFSgbsKUefIjdNw19RvcERXS/UFVzHQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=J55AxOLj+OG5URuaHxJXkYy3rPebv4Hb64tMNZCaMAUiGQSQIvKh0cC37sKVTH7pQT 9fIQPFm1Q+exCK5sBeJ0yEOCzr13JXHkyzbHHSgw2/npqt3dTZMWxd1uSxFbn1Clh1eK NJdREy27MWYPlTPt8xI+qv/lesbcjNOlhTSJs= MIME-Version: 1.0 Received: by 10.90.14.16 with SMTP id 16mr779645agn.47.1269499711466; Wed, 24 Mar 2010 23:48:31 -0700 (PDT) In-Reply-To: <03e919e078c06550481ad5f272511dd0.squirrel@www.trepanning.net> References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> <3B0BF1DE-83E0-413E-A09E-146F8B2C7C9B@checkpoint.com> <6AA54FAA-419E-4887-9801-227AABBCD702@checkpoint.com> <03e919e078c06550481ad5f272511dd0.squirrel@www.trepanning.net> Date: Thu, 25 Mar 2010 12:18:31 +0530 Message-ID: <7ccecf671003242348r119d3bd4uce7f70a226aeff3b@mail.gmail.com> From: Raj Singh To: Dan Harkins Content-Type: multipart/alternative; boundary=0016361646bf582ddc04829a6ffb Cc: Rodney Van Meter , "ipsec@ietf.org" , Melinda Shore , Yoav Nir Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 06:48:16 -0000 --0016361646bf582ddc04829a6ffb Content-Type: text/plain; charset=UTF-8 +1 I agree with Dan. On Wed, Mar 24, 2010 at 1:16 PM, Dan Harkins wrote: > > On Tue, March 23, 2010 7:24 pm, Yoav Nir wrote: > > > > On Mar 23, 2010, at 6:05 PM, Dan Harkins wrote: > > > >> > >> Hi, > >> > >> "hot standby" implies a box sitting ("hot") twiddling its thumbs doing > >> little but waiting for another box to fail ("standby"). It's the VRRP > >> model. > > > > And that's exactly what I want to describe. Well, not twiddling its > > thumbs. The standby is synchronizing state with the active member, but > > it's not doing any IKE or IPsec > > Well don't use such a limiting term to describe a behavior that is > not so limited. Not all HA is that small subset you want to describe. > > >> There is a HA model which supports dynamic load balancing as well as > >> active session failover. Nodes in such a cluster are not "standby". They > >> each have loads that they can shed and add to based upon some heuristic. > >> A neat attribute of such a system is that an IPsec SA can be established > >> on node A, move to node B after a while, and come back to A some time > >> later without any actual node failure. State moves around to keep the > >> cluster balanced. > > > > Failure is just used as an example of why a certain SA failed over to > > another member. It is by no means the only reason. Still, what you are > > describing is a model that provides both high-availability and load > > balancing, and that is the reason we're moving away from calling the > first > > model "high availability". > > Of course it's not the only reason. But you're missing the point. The > point is that the reason doesn't matter! You want to describe a particular > reason-- the "master" crashed and all state went over to the "hot > standby"-- > not the generic concept of state moving. > > So don't call it "high availability" then. But "hot standby" is worse. > > >> I would very much prefer "session failover" to "hot standby" and a > >> mild preference of "load balancing" over "load sharing". An HA model > >> doing VRRP could be termed "session failover" but the HA model described > >> above really can't be called "hot standby". And load can be shared but > >> just sharing a load can result in a mis-balanced cluster if sessions on > >> one node terminate naturally and it sits doing little while another node > >> whose sessions haven't terminated is huffing-and-puffing. Balancing can > >> imply sharing but not vice versa. > > > > "Session failover" sounds to me more like a description of an event than > a > > type of cluster. > > So what? Are you suggesting that a type of cluster that is not a > "hot standby" is not worthy of terminology in IPsecME? > > Your term is severely limiting. I like "session failover". If you don't > then come up with a term that generically describes HA and not the > particular style of HA that you are accustomed to. > > Dan. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016361646bf582ddc04829a6ffb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1
I agree with Dan.

On Wed, Mar 24, = 2010 at 1:16 PM, Dan Harkins <dharkins@lounge.org> wrote:

On Tue, March 23, 2010 7:24 pm, Yoav Nir wrote:
>
> On Mar 23, 2010, at 6:05 PM, Dan Harkins wrote:
>
>>
>> =C2=A0Hi,
>>
>> =C2=A0"hot standby" implies a box sitting ("hot&quo= t;) twiddling its thumbs doing
>> little but waiting for another box to fail ("standby"). = It's the VRRP
>> model.
>
> And that's exactly what I want to describe. Well, not twiddling it= s
> thumbs. The standby is synchronizing state with the active member, but=
> it's not doing any IKE or IPsec

=C2=A0Well don't use such a limiting term to describe a behavior= that is
not so limited. Not all HA is that small subset you want to describe.

>> =C2=A0There is a HA model which supports dynamic load balancing as= well as
>> active session failover. Nodes in such a cluster are not "sta= ndby". They
>> each have loads that they can shed and add to based upon some heur= istic.
>> A neat attribute of such a system is that an IPsec SA can be estab= lished
>> on node A, move to node B after a while, and come back to A some t= ime
>> later without any actual node failure. State moves around to keep = the
>> cluster balanced.
>
> Failure is just used as an example of why a certain SA failed over to<= br> > another member. It is by no means the only reason. Still, what you are=
> describing is a model that provides both high-availability and load > balancing, and that is the reason we're moving away from calling t= he first
> model "high availability".

=C2=A0Of course it's not the only reason. But you're missing= the point. The
point is that the reason doesn't matter! You want to describe a particu= lar
reason-- the "master" crashed and all state went over to the &quo= t;hot standby"--
not the generic concept of state moving.

=C2=A0So don't call it "high availability" then. But "h= ot standby" is worse.

>> =C2=A0I would very much prefer "session failover" to &qu= ot;hot standby" and a
>> mild preference of "load balancing" over "load shar= ing". An HA model
>> doing VRRP could be termed "session failover" but the HA= model described
>> above really can't be called "hot standby". And load= can be shared but
>> just sharing a load can result in a mis-balanced cluster if sessio= ns on
>> one node terminate naturally and it sits doing little while anothe= r node
>> whose sessions haven't terminated is huffing-and-puffing. Bala= ncing can
>> imply sharing but not vice versa.
>
> "Session failover" sounds to me more like a description of a= n event than a
> type of cluster.

=C2=A0So what? Are you suggesting that a type of cluster that is not= a
"hot standby" is not worthy of terminology in IPsecME?

=C2=A0Your term is severely limiting. I like "session failover".= If you don't
then come up with a term that generically describes HA and not the
particular style of HA that you are accustomed to.

=C2=A0Dan.



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

--0016361646bf582ddc04829a6ffb-- From shinsh93@gmail.com Thu Mar 25 11:08:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945BF3A6E52 for ; Thu, 25 Mar 2010 11:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5f9WkW8FhaG for ; Thu, 25 Mar 2010 11:08:26 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id CD3E43A6E44 for ; Thu, 25 Mar 2010 11:07:31 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so1516636qwi.31 for ; Thu, 25 Mar 2010 11:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=vmAkJckQEGiyotXCBWKadXyGjPgegEcOw6jvp0t2APU=; b=Ud0VXOGKF9tfbhdvnG9c/RfjC2lh4wn5myGomSFDwTFunmyWcmTRuIAoOa+AeNVSwl h3I/kPl9ioB0rAmh3CYyeRrog5JH2yVWGtjfnGVXyglkLFNtyz4ZqqP9z7KTNMV+/Roy 2X55W25epmGsivpL2MPAcxdCJON2+YgbXcnWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Tv3M7fLhpw6RM3zuWgxrSvpGnD1i/3lrxzog02smhi8QrdL3AyLOL97PYs2WqQIa3v drZWEhvRd5JTNDqUFp77Acz7m/4kHVUSl9Js9PdGGSyfh3NGZiAMIhXDo8ZLqcdvVuiy 23p+bD7ucfZFdWcRDvpTCNVuXLvM+KY8CkX+k= MIME-Version: 1.0 Sender: shinsh93@gmail.com Received: by 10.229.98.129 with SMTP id q1mr1081298qcn.100.1269540464503; Thu, 25 Mar 2010 11:07:44 -0700 (PDT) In-Reply-To: <4BAB06D4.3030907@gmail.com> References: <4BAB06D4.3030907@gmail.com> Date: Fri, 26 Mar 2010 03:07:43 +0900 X-Google-Sender-Auth: 76fd675aa6cdff7b Message-ID: From: SeongHan Shin To: Yaron Sheffer Content-Type: multipart/alternative; boundary=0016364274e76ba1ad0482a3ec3a Cc: IPsecme WG , Kazukuni Kobara , Shin Subject: Re: [IPsec] New PAKE Criteria draft posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:08:30 -0000 --0016364274e76ba1ad0482a3ec3a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Yaron Sheffer, I have one question about the draft. draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 =93This document is limited to the use of password-based authentication to achieve trust between gateways=94 Is this a consensus of this WG? Best regards, Shin On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer wrote= : > Hi, > > after the good discussion in Anaheim, and with the help of comments > received on and off the list, I have updated the PAKE Criteria draft and > posted it as > http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. > > I have added a number of criteria, clarified others, and added numbering > (SEC1-SEC6, IPR1-IPR3 etc.). > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --=20 ------------------------------------------------------------------ SeongHan Shin Research Center for Information Security (RCIS), National Institute of Advanced Industrial Science and Technology (AIST), Room no. 1003, Akihabara Daibiru 10F, 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan Tel : +81-3-5298-2722 Fax : +81-3-5298-4522 E-mail : seonghan.shin@aist.go.jp ------------------------------------------------------------------ --0016364274e76ba1ad0482a3ec3a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Yaron Sheffer,

I have one question about the draft.

draf= t-sheffer-ipsecme-pake-criteria-02.txt says in Page 4
=93This document is limited to the use of password-based authentication to = achieve trust between gateways=94

Is this a consensus of this WG?

Best regards,
Shin

On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer <yaronf.ietf@gmail.= com> wrote:
Hi,

after the good discussion in Anaheim, and with the help of comments receive= d on and off the list, I have updated the PAKE Criteria draft and posted it= as http://www.ietf.org/id/draft-sheffer-ipsecme-pake-= criteria-02.txt.

I have added a number of criteria, clarified others, and added numbering (S= EC1-SEC6, IPR1-IPR3 etc.).

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



--
-----------------------= -------------------------------------------
SeongHan Shin
Research Ce= nter for Information Security (RCIS),
National Institute of Advanced Ind= ustrial Science and Technology (AIST),
Room no. 1003, Akihabara Daibiru 10F,
1-18-13, Sotokannda, Chiyoda-ku, T= okyo 101-0021 Japan
Tel : +81-3-5298-2722
Fax : +81-3-5298-4522
E-= mail : seonghan.shin@aist.go.jp=
------------------------------------------------------------------
--0016364274e76ba1ad0482a3ec3a-- From yaronf.ietf@gmail.com Thu Mar 25 11:31:46 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0653A6B65 for ; Thu, 25 Mar 2010 11:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ewy5grE5cYb for ; Thu, 25 Mar 2010 11:31:44 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 0AC6E3A6DAA for ; Thu, 25 Mar 2010 11:29:35 -0700 (PDT) Received: by fxm5 with SMTP id 5so1293756fxm.29 for ; Thu, 25 Mar 2010 11:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xv0+EKWUVF9MiArkcosApfveUM5HcTOC1s8XjaMOWfE=; b=mwhuC45Wxyihsa60WRtxfjKKj5YODDYBa4rqPcaQRw9i10t91tA8IDdhgTZpfkszfJ arvWpn+MxXXzUpGKY9cywGHUU3NwqnFlKrH5EjG+u/aYLbn3lpXrDeS8AGuDE6fXqCwD UYUe7nBo3EzBmk4hETZnr6j6OqyePfyf5eAi0= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ZjIta+qoMz/598E6C1KzS/1rE+nj4Y1CbsNPJpVm1wp47uDduP7o2gQsL+B2bv+I2n a6RTXQ3Ef3D9MVf0wc/1DPQuvZFgiZ22NQ9y7zmSDZ4ZhtnP+dZwWmSqqKHgJXBFaGfY DLteJQWvBAY59QtU0GE44bIRMOkf5Xc33hpJE= Received: by 10.87.2.15 with SMTP id e15mr87266fgi.23.1269541795085; Thu, 25 Mar 2010 11:29:55 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id 4sm74193fge.23.2010.03.25.11.29.48 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Mar 2010 11:29:54 -0700 (PDT) Message-ID: <4BABABAE.5050501@gmail.com> Date: Thu, 25 Mar 2010 20:30:06 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: SeongHan Shin References: <4BAB06D4.3030907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IPsecme WG , Kazukuni Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:31:46 -0000 Hi Shin, Yes. For the typical remote access VPN, EAP is typically more useful. Note that there is still need for strong password-based mutual authentication EAP methods - but their home is the EMU working group. In addition, the IPsecME has another charter item designed to fit such EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. Please see again the group's charter, http://tools.ietf.org/wg/ipsecme/charters. Thanks, Yaron On 25.3.2010 20:07, SeongHan Shin wrote: > Dear Yaron Sheffer, > > I have one question about the draft. > > draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 > “This document is limited to the use of password-based authentication to > achieve trust between gateways” > > Is this a consensus of this WG? > > Best regards, > Shin > > On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer > wrote: > > Hi, > > after the good discussion in Anaheim, and with the help of comments > received on and off the list, I have updated the PAKE Criteria draft > and posted it as > http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. > > I have added a number of criteria, clarified others, and added > numbering (SEC1-SEC6, IPR1-IPR3 etc.). > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > > -- > ------------------------------------------------------------------ > SeongHan Shin > Research Center for Information Security (RCIS), > National Institute of Advanced Industrial Science and Technology (AIST), > Room no. 1003, Akihabara Daibiru 10F, > 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan > Tel : +81-3-5298-2722 > Fax : +81-3-5298-4522 > E-mail : seonghan.shin@aist.go.jp > ------------------------------------------------------------------ From yaronf.ietf@gmail.com Thu Mar 25 11:32:21 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0030B3A6ED3 for ; Thu, 25 Mar 2010 11:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ+4haUkaZEb for ; Thu, 25 Mar 2010 11:32:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id A93963A6EA5 for ; Thu, 25 Mar 2010 11:29:57 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1513605fgb.13 for ; Thu, 25 Mar 2010 11:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xv0+EKWUVF9MiArkcosApfveUM5HcTOC1s8XjaMOWfE=; b=cfYM0hLB+t8Vq33GKwrFD5cVICsjUaRsemliTGalvR69YuLkMZnCFWbqCOoGR/r4oX tm28hkAGd6+u+0R6jvFTT0hH7KQSj+5Qqm7xReexElSlRimdpvABKQB1PEjVxpZI2ila 2OmtT3BuKRKrSUwGmpxMuDr8vwKnzZzCE8YPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=XdQ76daURmc8vJE3sGCHYu/9TUWhjSMDx9O9Vuchafby0cuhbLDiH2yCJq0Ks5TmM7 3lCpmFx/NH9bDkYHkG73OXDby8bjX6Ty0pBrXaM7nIDJDgsTpsk9rtV04ZskKQDSxsuB hPUUf814JT/LX+QygK+dJFtZQ9O6q03b80peo= Received: by 10.87.1.12 with SMTP id d12mr2427576fgi.78.1269541813962; Thu, 25 Mar 2010 11:30:13 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id 3sm2757297fge.5.2010.03.25.11.30.12 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Mar 2010 11:30:13 -0700 (PDT) Message-ID: <4BABABC8.8010204@gmail.com> Date: Thu, 25 Mar 2010 20:30:32 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: SeongHan Shin References: <4BAB06D4.3030907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IPsecme WG , Kazukuni Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:32:21 -0000 Hi Shin, Yes. For the typical remote access VPN, EAP is typically more useful. Note that there is still need for strong password-based mutual authentication EAP methods - but their home is the EMU working group. In addition, the IPsecME has another charter item designed to fit such EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. Please see again the group's charter, http://tools.ietf.org/wg/ipsecme/charters. Thanks, Yaron On 25.3.2010 20:07, SeongHan Shin wrote: > Dear Yaron Sheffer, > > I have one question about the draft. > > draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 > “This document is limited to the use of password-based authentication to > achieve trust between gateways” > > Is this a consensus of this WG? > > Best regards, > Shin > > On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer > wrote: > > Hi, > > after the good discussion in Anaheim, and with the help of comments > received on and off the list, I have updated the PAKE Criteria draft > and posted it as > http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. > > I have added a number of criteria, clarified others, and added > numbering (SEC1-SEC6, IPR1-IPR3 etc.). > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > > -- > ------------------------------------------------------------------ > SeongHan Shin > Research Center for Information Security (RCIS), > National Institute of Advanced Industrial Science and Technology (AIST), > Room no. 1003, Akihabara Daibiru 10F, > 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan > Tel : +81-3-5298-2722 > Fax : +81-3-5298-4522 > E-mail : seonghan.shin@aist.go.jp > ------------------------------------------------------------------ From shinsh93@gmail.com Thu Mar 25 12:28:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DF63A68B3 for ; Thu, 25 Mar 2010 12:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVtuDb5ypXls for ; Thu, 25 Mar 2010 12:28:29 -0700 (PDT) Received: from mail-qy0-f197.google.com (mail-qy0-f197.google.com [209.85.221.197]) by core3.amsl.com (Postfix) with ESMTP id BA4863A69D4 for ; Thu, 25 Mar 2010 12:27:13 -0700 (PDT) Received: by qyk35 with SMTP id 35so460864qyk.18 for ; Thu, 25 Mar 2010 12:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=aeBGAc/Lt3o33n53LaNhJDrhkAHta6nPmomd5DULEfE=; b=U43VknUxSl4lRpzV9t+jtpQL2Dt8WHUqs9pm0cKxIenZjbV1G8dD3XYwKIl29KVTBi inQEoKWYMrR6NCIlvlDZss/e/s5q1Sxggo1v4apSArCEiTb5HSla8O79dpEcGk3Q9SBh J0mngxkp9uBnYPNc0EK2e4OxufhKYaBNTbQHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=lUpCNDvOKmRL1yrbo7QoZ0TQPBlXMU0Jcms5D66hdFavdls74/M4dAl0aD4rTbE0Dk gP+CSa0f+bZ0pZRmBXT8d553PESWKWPVsqEFAVjbifJ+qltbrOZKdaiFmniyulTB6JEn n69HvV1yEcACbb1zP2llB+j4im2HOdjBOAYI0= MIME-Version: 1.0 Sender: shinsh93@gmail.com Received: by 10.229.230.84 with SMTP id jl20mr4143984qcb.88.1269545253218; Thu, 25 Mar 2010 12:27:33 -0700 (PDT) In-Reply-To: <4BABABAE.5050501@gmail.com> References: <4BAB06D4.3030907@gmail.com> <4BABABAE.5050501@gmail.com> Date: Fri, 26 Mar 2010 04:27:33 +0900 X-Google-Sender-Auth: 2ca4fdfd668c47a3 Message-ID: From: SeongHan Shin To: Yaron Sheffer Content-Type: multipart/alternative; boundary=00163630ff21d829b40482a50945 Cc: IPsecme WG , Kazukuni Kobara , Shin Subject: Re: [IPsec] New PAKE Criteria draft posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 19:28:30 -0000 --00163630ff21d829b40482a50945 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thank you for your kind explanation. Best regards, Shin On Fri, Mar 26, 2010 at 3:30 AM, Yaron Sheffer wrote= : > Hi Shin, > > Yes. For the typical remote access VPN, EAP is typically more useful. Not= e > that there is still need for strong password-based mutual authentication = EAP > methods - but their home is the EMU working group. > > In addition, the IPsecME has another charter item designed to fit such EA= P > methods (such as the future EAP-AugPAKE :-) into IKEv2. > > Please see again the group's charter, > http://tools.ietf.org/wg/ipsecme/charters. > > Thanks, > Yaron > > > On 25.3.2010 20:07, SeongHan Shin wrote: > >> Dear Yaron Sheffer, >> >> I have one question about the draft. >> >> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >> =93This document is limited to the use of password-based authentication = to >> achieve trust between gateways=94 >> >> Is this a consensus of this WG? >> >> Best regards, >> Shin >> >> On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer > > wrote: >> >> Hi, >> >> after the good discussion in Anaheim, and with the help of comments >> received on and off the list, I have updated the PAKE Criteria draft >> and posted it as >> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >> >> I have added a number of criteria, clarified others, and added >> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >> >> Thanks, >> Yaron >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> >> -- >> ------------------------------------------------------------------ >> SeongHan Shin >> Research Center for Information Security (RCIS), >> National Institute of Advanced Industrial Science and Technology (AIST), >> Room no. 1003, Akihabara Daibiru 10F, >> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >> Tel : +81-3-5298-2722 >> Fax : +81-3-5298-4522 >> E-mail : seonghan.shin@aist.go.jp >> ------------------------------------------------------------------ >> > --=20 ------------------------------------------------------------------ SeongHan Shin Research Center for Information Security (RCIS), National Institute of Advanced Industrial Science and Technology (AIST), Room no. 1003, Akihabara Daibiru 10F, 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan Tel : +81-3-5298-2722 Fax : +81-3-5298-4522 E-mail : seonghan.shin@aist.go.jp ------------------------------------------------------------------ --00163630ff21d829b40482a50945 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thank you for your kind explanation.

Best regards,
Shin

On Fri, Mar 26, 2010 at 3:30 AM, Yaron Sheffer= <yaronf.ietf= @gmail.com> wrote:
Hi Shin,

Yes. For the typical remote access VPN, EAP is typically more useful. Note = that there is still need for strong password-based mutual authentication EA= P methods - but their home is the EMU working group.

In addition, the IPsecME has another charter item designed to fit such EAP = methods (such as the future EAP-AugPAKE :-) into IKEv2.

Please see again the group's charter, http://tools.ietf.org/wg/ipsecme/cha= rters.

Thanks,
=A0 =A0 =A0 =A0Yaron


On 25.3.2010 20:07, SeongHan Shin wrote:
Dear Yaron Sheffer,

I have one question about the draft.

draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4
=93This document is limited to the use of password-based authentication to<= br> achieve trust between gateways=94

Is this a consensus of this WG?

Best regards,
Shin

On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer <yaronf.ietf@gmail.com
<mailto:yaron= f.ietf@gmail.com>> wrote:

=A0 =A0Hi,

=A0 =A0after the good discussion in Anaheim, and with the help of comments=
=A0 =A0received on and off the list, I have updated the PAKE Criteria draf= t
=A0 =A0and posted it as
=A0 =A0http://www.ietf.org/id/draft-sheffer-ipsecme-p= ake-criteria-02.txt.

=A0 =A0I have added a number of criteria, clarified others, and added
=A0 =A0numbering (SEC1-SEC6, IPR1-IPR3 etc.).

=A0 =A0Thanks,
=A0 =A0 =A0 =A0Yaron
=A0 =A0_______________________________________________
=A0 =A0IPsec mailing list
=A0 =A0IPsec@ietf.org<= /a> <mailto:IPsec@ie= tf.org>

=A0 =A0https://www.ietf.org/mailman/listinfo/ipsec




--
------------------------------------------------------------------
SeongHan Shin
Research Center for Information Security (RCIS),
National Institute of Advanced Industrial Science and Technology (AIST), Room no. 1003, Akihabara Daibiru 10F,
1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan
Tel : +81-3-5298-2722
Fax : +81-3-5298-4522
E-mail : seon= ghan.shin@aist.go.jp <mailto:seonghan.shin@aist.go.jp>
------------------------------------------------------------------



--
-----------------------= -------------------------------------------
SeongHan Shin
Research Ce= nter for Information Security (RCIS),
National Institute of Advanced Ind= ustrial Science and Technology (AIST),
Room no. 1003, Akihabara Daibiru 10F,
1-18-13, Sotokannda, Chiyoda-ku, T= okyo 101-0021 Japan
Tel : +81-3-5298-2722
Fax : +81-3-5298-4522
E-= mail : seonghan.shin@aist.go.jp=
------------------------------------------------------------------
--00163630ff21d829b40482a50945-- From ynir@checkpoint.com Thu Mar 25 13:09:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D133A6892 for ; Thu, 25 Mar 2010 13:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXNrGkMqxyJK for ; Thu, 25 Mar 2010 13:09:51 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id C642F3A6B18 for ; Thu, 25 Mar 2010 13:09:48 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2PK9lsd003990; Thu, 25 Mar 2010 22:09:47 +0200 (IST) X-CheckPoint: {4BABC23A-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 25 Mar 2010 22:10:09 +0200 From: Yoav Nir To: Dan Harkins Date: Thu, 25 Mar 2010 22:09:45 +0200 Thread-Topic: [IPsec] Issue #177. (was: HA/LS terminology) Thread-Index: AcrMVyrZa+0+oxzoSZqgsYEAhEMYNg== Message-ID: References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> <3B0BF1DE-83E0-413E-A09E-146F8B2C7C9B@checkpoint.com> <6AA54FAA-419E-4887-9801-227AABBCD702@checkpoint.com> <03e919e078c06550481ad5f272511dd0.squirrel@www.trepanning.net> In-Reply-To: <03e919e078c06550481ad5f272511dd0.squirrel@www.trepanning.net> 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: Rodney Van Meter , "ipsec@ietf.org" , Melinda Shore Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 20:09:52 -0000 Hi Dan I am not trying to create a complete taxonomy of cluster types. I should al= so note that we don't really have a term for a single "thing" that does IKE= and IPsec. Our documents use terms like "gateway" and "peer", but "gateway= " does not encompass VPN clients and hosts, and "peer" is not just any impl= ementation, it's the *other* implementation. "Implementation" is a little t= oo long. Anyway, draft-ietf-ipsecme-ipsec-ha is not out to make a complete taxonomy = of clusters. We only define what we need to discuss the problems. All the c= lusters that are of interest to us provide the ability for another member t= o take over the work of a failed member. Since this is common to all the cl= usters that we are considering, we don't need to define this specially. The= only difference that matters is whether or not more than one member is han= dling traffic with the same peer at the same time. So the only terminology that we need, the only taxonomy that we need, is fo= r these two mutually-exclusive types of cluster: - Only one member handles all traffic for a particular peer at the same tim= e - Several members handle traffic for a particular peer at the same time. That's all the terminology that we need. So with that in mind, what terms would you suggest for these two types of c= luster?= From kivinen@iki.fi Thu Mar 25 15:59:38 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91E63A67EF for ; Thu, 25 Mar 2010 15:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIFv-1NxpcYS for ; Thu, 25 Mar 2010 15:59:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5423A67E4 for ; Thu, 25 Mar 2010 15:59:37 -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 o2PMxW3F003708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Mar 2010 00:59:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o2PMxV4S006874; Fri, 26 Mar 2010 00:59:31 +0200 (EET) 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: <19371.60115.78743.946754@fireball.kivinen.iki.fi> Date: Fri, 26 Mar 2010 00:59:31 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> <3B0BF1DE-83E0-413E-A09E-146F8B2C7C9B@checkpoint.com> <6AA54FAA-419E-4887-9801-227AABBCD702@checkpoint.com> <03e919e078c06550481ad5f272511dd0.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: Rodney Van Meter , "ipsec@ietf.org" , Melinda Shore , Dan Harkins Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 22:59:38 -0000 Yoav Nir writes: > I am not trying to create a complete taxonomy of cluster types. I think it is worth adding more defined terms, just to show which we are not talking about too. > I should also note that we don't really have a term for a single > "thing" that does IKE and IPsec. Our documents use terms like > "gateway" and "peer", but "gateway" does not encompass VPN clients > and hosts, and "peer" is not just any implementation, it's the > *other* implementation. "Implementation" is a little too long. I would use host, or implementation, and I do not think implementation is too long... > Anyway, draft-ietf-ipsecme-ipsec-ha is not out to make a complete > taxonomy of clusters. We only define what we need to discuss the > problems. All the clusters that are of interest to us provide the > ability for another member to take over the work of a failed member. I do not think that was clear from the terminology section. For example the "load sharing cluster" and "cluster" does not really say that. If we add terms that describe different cluster types better, then we can more clearly describe what we are really talking about. One of the problems we have when talking about the ipsec-ha is that people use different terms and they interpret them meaning different things. Thats why I think it would be needed for this document to define good and extensive terminology for this area and use those terms consitently inside the document. > Since this is common to all the clusters that we are considering, we > don't need to define this specially. How can someone know that this is generic for all clusters, if you do not define it? > The only difference that matters is whether or not more than one > member is handling traffic with the same peer at the same time. > > So the only terminology that we need, the only taxonomy that we > need, is for these two mutually-exclusive types of cluster: I disagree. We do need much more extensive terminology to explain also things we are not talking about, just to clarify that we do not mean them. -- kivinen@iki.fi From kobara_conf@m.aist.go.jp Thu Mar 25 16:40:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6473A69BF for ; Thu, 25 Mar 2010 16:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI-FKYTL3Qez for ; Thu, 25 Mar 2010 16:40:27 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id 7EE7B3A683B for ; Thu, 25 Mar 2010 16:40:27 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o2PNenXU003071 for ; Fri, 26 Mar 2010 08:40:49 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=m.aist.go.jp; s=aist; t=1269560449; bh=cKmq1V4e4sbLpfVoIX/bEpz27dm3fy+nZRaA5vH0SvY=; h=From:Date:Message-ID; b=nTdsNzvgAtQS2McDB0dNS/wsi8dKnZTytdP64JYbhrG3uzHmUOF+FyxO/tUJBZlIf u/QXbAOWG+GknWkWj1N+yTCAiTgpepC67rGXXEVZTQ8alCEjEGqbCK4kUDOpNksRd8 gx3zz0At7bd6vUmASTjYfuT6juN76+seiqGv9A8I= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o2PNemHp004445 for ; Fri, 26 Mar 2010 08:40:48 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id o2PNelkC006258 for ; Fri, 26 Mar 2010 08:40:48 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) From: "Kaz Kobara" To: Date: Fri, 26 Mar 2010 08:40:51 +0900 Message-ID: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrMSajKfQlL1qC9RXauA2xWjjDOaQADzTAQAAbMQtA= Content-Language: ja Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 23:40:28 -0000 Hi Yaron > draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 > "This document is limited to the use of password-based authentication to > achieve trust between gateways" I would like to make sure that "gateway" in this document does not encompass VPN clients and hosts, right? Kaz > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yaron Sheffer > Sent: Friday, March 26, 2010 3:31 AM > To: SeongHan Shin > Cc: IPsecme WG; Kazukuni Kobara > Subject: Re: [IPsec] New PAKE Criteria draft posted > > Hi Shin, > > Yes. For the typical remote access VPN, EAP is typically more useful. > Note that there is still need for strong password-based mutual > authentication EAP methods - but their home is the EMU working group. > > In addition, the IPsecME has another charter item designed to fit such > EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. > > Please see again the group's charter, > http://tools.ietf.org/wg/ipsecme/charters. > > Thanks, > Yaron > > On 25.3.2010 20:07, SeongHan Shin wrote: > > Dear Yaron Sheffer, > > > > I have one question about the draft. > > > > draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 > > "This document is limited to the use of password-based authentication > to > > achieve trust between gateways" > > > > Is this a consensus of this WG? > > > > Best regards, > > Shin > > > > On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer > > wrote: > > > > Hi, > > > > after the good discussion in Anaheim, and with the help of comments > > received on and off the list, I have updated the PAKE Criteria draft > > and posted it as > > > http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. > > > > I have added a number of criteria, clarified others, and added > > numbering (SEC1-SEC6, IPR1-IPR3 etc.). > > > > Thanks, > > Yaron > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > -- > > ------------------------------------------------------------------ > > SeongHan Shin > > Research Center for Information Security (RCIS), > > National Institute of Advanced Industrial Science and Technology (AIST), > > Room no. 1003, Akihabara Daibiru 10F, > > 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan > > Tel : +81-3-5298-2722 > > Fax : +81-3-5298-4522 > > E-mail : seonghan.shin@aist.go.jp > > ------------------------------------------------------------------ > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From dharkins@lounge.org Thu Mar 25 16:59:03 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BFAD3A6805 for ; Thu, 25 Mar 2010 16:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.259 X-Spam-Level: X-Spam-Status: No, score=-4.259 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2vS7HiLACaP for ; Thu, 25 Mar 2010 16:59:02 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 95BC13A6804 for ; Thu, 25 Mar 2010 16:59:02 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7EEE21022404A; Thu, 25 Mar 2010 16:59:24 -0700 (PDT) Received: from 130.129.26.143 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 25 Mar 2010 16:59:24 -0700 (PDT) Message-ID: <4093d38f9abeccadfd77722bca2bedd5.squirrel@www.trepanning.net> In-Reply-To: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> Date: Thu, 25 Mar 2010 16:59:24 -0700 (PDT) From: "Dan Harkins" To: "Kaz Kobara" 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 Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 23:59:03 -0000 On the contrary, I would like to see no notion of "clients", "hosts", and "gateways" at all. There is no reason why this technique could not be used in any of the use cases in IKEv2. And such a statement certainly does not belong in a document that supposedly deals with criteria upon which a selection will be made. Dan. On Thu, March 25, 2010 4:40 pm, Kaz Kobara wrote: > Hi Yaron > >> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >> "This document is limited to the use of password-based authentication to >> achieve trust between gateways" > > I would like to make sure that > "gateway" in this document does not encompass VPN clients and hosts, > right? > > Kaz > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of >> Yaron Sheffer >> Sent: Friday, March 26, 2010 3:31 AM >> To: SeongHan Shin >> Cc: IPsecme WG; Kazukuni Kobara >> Subject: Re: [IPsec] New PAKE Criteria draft posted >> >> Hi Shin, >> >> Yes. For the typical remote access VPN, EAP is typically more useful. >> Note that there is still need for strong password-based mutual >> authentication EAP methods - but their home is the EMU working group. >> >> In addition, the IPsecME has another charter item designed to fit such >> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >> >> Please see again the group's charter, >> http://tools.ietf.org/wg/ipsecme/charters. >> >> Thanks, >> Yaron >> >> On 25.3.2010 20:07, SeongHan Shin wrote: >> > Dear Yaron Sheffer, >> > >> > I have one question about the draft. >> > >> > draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >> > "This document is limited to the use of password-based authentication >> to >> > achieve trust between gateways" >> > >> > Is this a consensus of this WG? >> > >> > Best regards, >> > Shin >> > >> > On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer > > > wrote: >> > >> > Hi, >> > >> > after the good discussion in Anaheim, and with the help of >> comments >> > received on and off the list, I have updated the PAKE Criteria >> draft >> > and posted it as >> > >> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >> > >> > I have added a number of criteria, clarified others, and added >> > numbering (SEC1-SEC6, IPR1-IPR3 etc.). >> > >> > Thanks, >> > Yaron >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> > >> > >> > >> > -- >> > ------------------------------------------------------------------ >> > SeongHan Shin >> > Research Center for Information Security (RCIS), >> > National Institute of Advanced Industrial Science and Technology >> (AIST), >> > Room no. 1003, Akihabara Daibiru 10F, >> > 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >> > Tel : +81-3-5298-2722 >> > Fax : +81-3-5298-4522 >> > E-mail : seonghan.shin@aist.go.jp >> > ------------------------------------------------------------------ >> _______________________________________________ >> 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 yaronf.ietf@gmail.com Thu Mar 25 22:26:40 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D483A6999 for ; Thu, 25 Mar 2010 22:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGXnMROVwCew for ; Thu, 25 Mar 2010 22:26:39 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id BA25D3A69E9 for ; Thu, 25 Mar 2010 22:25:23 -0700 (PDT) Received: by fxm5 with SMTP id 5so1676211fxm.29 for ; Thu, 25 Mar 2010 22:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=L19OYKP5VEw9PS4qz70bDSZDT7VMBHq37AyZ/q0MkfI=; b=N4P7OseesXBNc1BhlBhFX41bQprqCCFQU31qbDIltiamD633h2g4WAx72HPJSvhBGj EWfBDVv2CFXf2tKy1cCpDDsgKvOsUlN2ApJ8WL6HnpT/ktwn58lK9We5CBUow/gWSeOr ygGu6OFY7cOCVxAElODAK7/L3lUm4f4UTb2mk= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=FCf6U7P9C8HFpFoRJt4I82dCyXMyLxDzH0c7S07lgTSAIJC04vZxofDuboHyPI6M2J 1hwuR5wjGw3t3K0xgGWBU4UsD35qHDhKDL+njIRbTCfwGps95sQecLF2+Jz9IWyEwz7P SgC27EF7yZjwWmDxVUb69ve2Cpyf5rrk8sQaA= Received: by 10.87.67.25 with SMTP id u25mr3318045fgk.32.1269581137367; Thu, 25 Mar 2010 22:25:37 -0700 (PDT) Received: from [192.117.42.149] (192.117.42.149.static.012.net.il [192.117.42.149]) by mx.google.com with ESMTPS id 3sm3262965fge.5.2010.03.25.22.25.34 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Mar 2010 22:25:37 -0700 (PDT) Message-ID: <4BAC40DC.6070509@gmail.com> Date: Fri, 26 Mar 2010 08:06:36 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Dan Harkins References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4093d38f9abeccadfd77722bca2bedd5.squirrel@www.trepanning.net> In-Reply-To: <4093d38f9abeccadfd77722bca2bedd5.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Kaz Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 05:26:40 -0000 As I mentioned in my previous mail, the document attempts to follow the use cases as agreed in the charter. For the remote access case, there are clear benefits to having a separate AAA server, and EAP has been adopted by multiple protocols including IKEv2. I don't see a reason to open this decision now. And the criteria that this document "supposedly" deals with have to be evaluated in the context of use cases and scenarios. They are not abstract entities. Thanks, Yaron On 26.3.2010 1:59, Dan Harkins wrote: > > On the contrary, I would like to see no notion of "clients", "hosts", > and "gateways" at all. There is no reason why this technique could > not be used in any of the use cases in IKEv2. > > And such a statement certainly does not belong in a document that > supposedly deals with criteria upon which a selection will be made. > > Dan. > > On Thu, March 25, 2010 4:40 pm, Kaz Kobara wrote: >> Hi Yaron >> >>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>> "This document is limited to the use of password-based authentication to >>> achieve trust between gateways" >> >> I would like to make sure that >> "gateway" in this document does not encompass VPN clients and hosts, >> right? >> >> Kaz >> >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>> Of >>> Yaron Sheffer >>> Sent: Friday, March 26, 2010 3:31 AM >>> To: SeongHan Shin >>> Cc: IPsecme WG; Kazukuni Kobara >>> Subject: Re: [IPsec] New PAKE Criteria draft posted >>> >>> Hi Shin, >>> >>> Yes. For the typical remote access VPN, EAP is typically more useful. >>> Note that there is still need for strong password-based mutual >>> authentication EAP methods - but their home is the EMU working group. >>> >>> In addition, the IPsecME has another charter item designed to fit such >>> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >>> >>> Please see again the group's charter, >>> http://tools.ietf.org/wg/ipsecme/charters. >>> >>> Thanks, >>> Yaron >>> >>> On 25.3.2010 20:07, SeongHan Shin wrote: >>>> Dear Yaron Sheffer, >>>> >>>> I have one question about the draft. >>>> >>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>> "This document is limited to the use of password-based authentication >>> to >>>> achieve trust between gateways" >>>> >>>> Is this a consensus of this WG? >>>> >>>> Best regards, >>>> Shin >>>> >>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer>>> > wrote: >>>> >>>> Hi, >>>> >>>> after the good discussion in Anaheim, and with the help of >>> comments >>>> received on and off the list, I have updated the PAKE Criteria >>> draft >>>> and posted it as >>>> >>> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >>>> >>>> I have added a number of criteria, clarified others, and added >>>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >>>> >>>> Thanks, >>>> Yaron >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------ >>>> SeongHan Shin >>>> Research Center for Information Security (RCIS), >>>> National Institute of Advanced Industrial Science and Technology >>> (AIST), >>>> Room no. 1003, Akihabara Daibiru 10F, >>>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >>>> Tel : +81-3-5298-2722 >>>> Fax : +81-3-5298-4522 >>>> E-mail : seonghan.shin@aist.go.jp >>>> ------------------------------------------------------------------ >>> _______________________________________________ >>> 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 yaronf.ietf@gmail.com Thu Mar 25 22:27:01 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AABE3A68CD for ; Thu, 25 Mar 2010 22:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bksx2PW3vdhr for ; Thu, 25 Mar 2010 22:27:00 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 71C083A69E8 for ; Thu, 25 Mar 2010 22:25:35 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1668082fgb.13 for ; Thu, 25 Mar 2010 22:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=7q21PY53Kis14dTl0PXO+JxRQSynfiWNl3+TwlU1/Mk=; b=xsKJBwqPj8v2nxDpQze6XvKZKZTy5mu3YA0BeJIZCbPyduSRK7V9H8qTt3LH22z512 1DpL3MUMOjZ5QfVz5S9sq/9o8hAMS3Q+qU3RaURTdVcezfBvKjP8O9hcmndgae6ZanL1 b4PZ5oUJe+zHTFdFDSm4GJxttNIbcRVetRrac= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=mYs6PbtSAvO7z1rEqvznlGS+g5ySBZkz/wkhRshR62TjSyEBsX2uu31GuQuvCXIHHK MVNz5hhfGqoucAuPJIqQyYsou6MePDKr6R5OoViQhGsX5Dlu5AiCBwJX2MidlIcFVi7o N0PnJexQmYGJy0CxYCdENOr1SNNF4kGuBbVZ0= Received: by 10.87.47.5 with SMTP id z5mr2869652fgj.19.1269581154232; Thu, 25 Mar 2010 22:25:54 -0700 (PDT) Received: from [192.117.42.149] (192.117.42.149.static.012.net.il [192.117.42.149]) by mx.google.com with ESMTPS id 4sm908272fgg.12.2010.03.25.22.25.52 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Mar 2010 22:25:54 -0700 (PDT) Message-ID: <4BAC4283.9010002@gmail.com> Date: Fri, 26 Mar 2010 08:13:39 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Kaz Kobara References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> In-Reply-To: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 05:27:01 -0000 Hi Kaz, I *thought* my intention was clear: "between gateways" as opposed to "between clients and gateways". So your assertion is correct. Thanks, Yaron On 26.3.2010 1:40, Kaz Kobara wrote: > Hi Yaron > >> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >> "This document is limited to the use of password-based authentication to >> achieve trust between gateways" > > I would like to make sure that > "gateway" in this document does not encompass VPN clients and hosts, right? > > Kaz > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >> Yaron Sheffer >> Sent: Friday, March 26, 2010 3:31 AM >> To: SeongHan Shin >> Cc: IPsecme WG; Kazukuni Kobara >> Subject: Re: [IPsec] New PAKE Criteria draft posted >> >> Hi Shin, >> >> Yes. For the typical remote access VPN, EAP is typically more useful. >> Note that there is still need for strong password-based mutual >> authentication EAP methods - but their home is the EMU working group. >> >> In addition, the IPsecME has another charter item designed to fit such >> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >> >> Please see again the group's charter, >> http://tools.ietf.org/wg/ipsecme/charters. >> >> Thanks, >> Yaron >> >> On 25.3.2010 20:07, SeongHan Shin wrote: >>> Dear Yaron Sheffer, >>> >>> I have one question about the draft. >>> >>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>> "This document is limited to the use of password-based authentication >> to >>> achieve trust between gateways" >>> >>> Is this a consensus of this WG? >>> >>> Best regards, >>> Shin >>> >>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer>> > wrote: >>> >>> Hi, >>> >>> after the good discussion in Anaheim, and with the help of comments >>> received on and off the list, I have updated the PAKE Criteria draft >>> and posted it as >>> >> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >>> >>> I have added a number of criteria, clarified others, and added >>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >>> >>> Thanks, >>> Yaron >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> >>> >>> -- >>> ------------------------------------------------------------------ >>> SeongHan Shin >>> Research Center for Information Security (RCIS), >>> National Institute of Advanced Industrial Science and Technology (AIST), >>> Room no. 1003, Akihabara Daibiru 10F, >>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >>> Tel : +81-3-5298-2722 >>> Fax : +81-3-5298-4522 >>> E-mail : seonghan.shin@aist.go.jp >>> ------------------------------------------------------------------ >> _______________________________________________ >> 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 yaronf.ietf@gmail.com Thu Mar 25 22:34:46 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A363A67A7 for ; Thu, 25 Mar 2010 22:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pszmznQgW1Q0 for ; Thu, 25 Mar 2010 22:34:45 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 81C043A6862 for ; Thu, 25 Mar 2010 22:34:45 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2189061fga.13 for ; Thu, 25 Mar 2010 22:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xv0+EKWUVF9MiArkcosApfveUM5HcTOC1s8XjaMOWfE=; b=NQicnLndrfiOGb+yMg/qYapA8v/CzuP1r50hvu1FDJzW54sDMfpc3yOKUYmZMEToGe CgY8q8XDrI80l9qUnak1yzTtmY3ggmkrJFelefa8ve2cqZTwdzAzfE6h33EJp2rEtlJW bLTjqBOPEP6AnPYuMsuUcOqAuHNgGDkBGTlhI= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=KRdnoWN7qTmGNl5FOmgTtDEOCANHFO7yVdOGVbTYejZ3+dM10eaoy/RhOAdKeidIX+ kG1yY+5a4lOLpyuNqLVSQs9+FUwOW87hqPqoJvcKxIc5+66ZWVUksbMWF3z1w7Cz0rTZ Py8d/7GrK50eY9jSldup2KoX+LIJk9o/dy2qE= Received: by 10.87.73.30 with SMTP id a30mr30714fgl.64.1269581704187; Thu, 25 Mar 2010 22:35:04 -0700 (PDT) Received: from [192.117.42.149] (192.117.42.149.static.012.net.il [192.117.42.149]) by mx.google.com with ESMTPS id d6sm3420220fga.23.2010.03.25.22.35.01 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Mar 2010 22:35:03 -0700 (PDT) Message-ID: <4BAC4797.8040603@gmail.com> Date: Fri, 26 Mar 2010 08:35:19 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: SeongHan Shin References: <4BAB06D4.3030907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IPsecme WG , Kazukuni Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 05:34:46 -0000 Hi Shin, Yes. For the typical remote access VPN, EAP is typically more useful. Note that there is still need for strong password-based mutual authentication EAP methods - but their home is the EMU working group. In addition, the IPsecME has another charter item designed to fit such EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. Please see again the group's charter, http://tools.ietf.org/wg/ipsecme/charters. Thanks, Yaron On 25.3.2010 20:07, SeongHan Shin wrote: > Dear Yaron Sheffer, > > I have one question about the draft. > > draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 > “This document is limited to the use of password-based authentication to > achieve trust between gateways” > > Is this a consensus of this WG? > > Best regards, > Shin > > On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer > wrote: > > Hi, > > after the good discussion in Anaheim, and with the help of comments > received on and off the list, I have updated the PAKE Criteria draft > and posted it as > http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. > > I have added a number of criteria, clarified others, and added > numbering (SEC1-SEC6, IPR1-IPR3 etc.). > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > > -- > ------------------------------------------------------------------ > SeongHan Shin > Research Center for Information Security (RCIS), > National Institute of Advanced Industrial Science and Technology (AIST), > Room no. 1003, Akihabara Daibiru 10F, > 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan > Tel : +81-3-5298-2722 > Fax : +81-3-5298-4522 > E-mail : seonghan.shin@aist.go.jp > ------------------------------------------------------------------ From dharkins@lounge.org Fri Mar 26 08:59:13 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547F43A6A3E for ; Fri, 26 Mar 2010 08:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.478 X-Spam-Level: X-Spam-Status: No, score=-4.478 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH5M8+ZZwBkq for ; Fri, 26 Mar 2010 08:59:12 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 576283A69D1 for ; Fri, 26 Mar 2010 08:59:12 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AFDF41022404A; Fri, 26 Mar 2010 08:59:35 -0700 (PDT) Received: from 130.129.26.143 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 26 Mar 2010 08:59:35 -0700 (PDT) Message-ID: In-Reply-To: <4BAC40DC.6070509@gmail.com> References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4093d38f9abeccadfd77722bca2bedd5.squirrel@www.trepanning.net> <4BAC40DC.6070509@gmail.com> Date: Fri, 26 Mar 2010 08:59:35 -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: ipsec@ietf.org, Dan Harkins , Kaz Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 15:59:13 -0000 Great, clear benefits to having a separate AAA server. So that's the reason to neuter technology? What you're talking about is a deployment issue and that really isn't any of our business. Dan. On Thu, March 25, 2010 10:06 pm, Yaron Sheffer wrote: > As I mentioned in my previous mail, the document attempts to follow the > use cases as agreed in the charter. > > For the remote access case, there are clear benefits to having a > separate AAA server, and EAP has been adopted by multiple protocols > including IKEv2. I don't see a reason to open this decision now. > > And the criteria that this document "supposedly" deals with have to be > evaluated in the context of use cases and scenarios. They are not > abstract entities. > > Thanks, > Yaron > > On 26.3.2010 1:59, Dan Harkins wrote: >> >> On the contrary, I would like to see no notion of "clients", "hosts", >> and "gateways" at all. There is no reason why this technique could >> not be used in any of the use cases in IKEv2. >> >> And such a statement certainly does not belong in a document that >> supposedly deals with criteria upon which a selection will be made. >> >> Dan. >> >> On Thu, March 25, 2010 4:40 pm, Kaz Kobara wrote: >>> Hi Yaron >>> >>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>> "This document is limited to the use of password-based authentication >>>> to >>>> achieve trust between gateways" >>> >>> I would like to make sure that >>> "gateway" in this document does not encompass VPN clients and hosts, >>> right? >>> >>> Kaz >>> >>>> -----Original Message----- >>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>>> Of >>>> Yaron Sheffer >>>> Sent: Friday, March 26, 2010 3:31 AM >>>> To: SeongHan Shin >>>> Cc: IPsecme WG; Kazukuni Kobara >>>> Subject: Re: [IPsec] New PAKE Criteria draft posted >>>> >>>> Hi Shin, >>>> >>>> Yes. For the typical remote access VPN, EAP is typically more useful. >>>> Note that there is still need for strong password-based mutual >>>> authentication EAP methods - but their home is the EMU working group. >>>> >>>> In addition, the IPsecME has another charter item designed to fit such >>>> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >>>> >>>> Please see again the group's charter, >>>> http://tools.ietf.org/wg/ipsecme/charters. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 25.3.2010 20:07, SeongHan Shin wrote: >>>>> Dear Yaron Sheffer, >>>>> >>>>> I have one question about the draft. >>>>> >>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>> "This document is limited to the use of password-based authentication >>>> to >>>>> achieve trust between gateways" >>>>> >>>>> Is this a consensus of this WG? >>>>> >>>>> Best regards, >>>>> Shin >>>>> >>>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer>>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> after the good discussion in Anaheim, and with the help of >>>> comments >>>>> received on and off the list, I have updated the PAKE Criteria >>>> draft >>>>> and posted it as >>>>> >>>> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >>>>> >>>>> I have added a number of criteria, clarified others, and added >>>>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >>>>> >>>>> Thanks, >>>>> Yaron >>>>> _______________________________________________ >>>>> IPsec mailing list >>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> SeongHan Shin >>>>> Research Center for Information Security (RCIS), >>>>> National Institute of Advanced Industrial Science and Technology >>>> (AIST), >>>>> Room no. 1003, Akihabara Daibiru 10F, >>>>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >>>>> Tel : +81-3-5298-2722 >>>>> Fax : +81-3-5298-4522 >>>>> E-mail : seonghan.shin@aist.go.jp >>>>> ------------------------------------------------------------------ >>>> _______________________________________________ >>>> 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 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kobara_conf@m.aist.go.jp Fri Mar 26 09:52:53 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07ED43A6BB3 for ; Fri, 26 Mar 2010 09:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVwTMb3M7ed9 for ; Fri, 26 Mar 2010 09:52:51 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id 3F9593A6A73 for ; Fri, 26 Mar 2010 09:52:51 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o2QGrD5e025601 for ; Sat, 27 Mar 2010 01:53:13 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=m.aist.go.jp; s=aist; t=1269622394; bh=RtNht1erCjUB0gTE2hU+/RxhowHpA7X1sM8laCD3Zw0=; h=From:Date:Message-ID; b=oP/TfjLbd68raAj3ec2RDaNXX/uso6hNOdzVfFLquxeOhYQq3rgoO6xIn4kNIwMw9 ySt3/XLrESVruSHvwM1uyXQX3hQfQ4tdKf2T6BJ9TC4T6e6BDQk3gXhtRpZdORcUsP JBeSxom9zMG9eJO/1aMmUThIeeVd7tDQzsix7wRo= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o2QGrDtP027619 for ; Sat, 27 Mar 2010 01:53:13 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id o2QGrCCK003578 for ; Sat, 27 Mar 2010 01:53:13 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) From: "Kaz Kobara" To: References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> In-Reply-To: <4BAC4283.9010002@gmail.com> Date: Sat, 27 Mar 2010 01:53:17 +0900 Message-ID: <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrMpNEz/MKtWb4cSHmjkTfcRWtGeQAWZ9ww Content-Language: ja Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:52:53 -0000 Hi Yaron Thank you for your clarification. > "between gateways" as opposed to > "between clients and gateways". So your assertion is correct. (Between gateways, administrators can set long secrets, so the necessity of PAKE seems smaller than between clients and gateways where passwords are recorded in the gateways and users have to type the passwords.) Anyway, if the scope is limited only on "between gateways" but not "between clients and gateways," the title "Password-Based Authentication in IKEv2: Selection Criteria and Comparison" seems misleading (since this itself misinforms that this criteria may be applied to IKEv2 in any cases), and the above should be clearly mentioned in the document. Kaz > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Friday, March 26, 2010 2:14 PM > To: Kaz Kobara > Cc: ipsec@ietf.org > Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) > > Hi Kaz, > > I *thought* my intention was clear: "between gateways" as opposed to > "between clients and gateways". So your assertion is correct. > > Thanks, > Yaron > > On 26.3.2010 1:40, Kaz Kobara wrote: > > Hi Yaron > > > >> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 > >> "This document is limited to the use of password-based authentication > to > >> achieve trust between gateways" > > > > I would like to make sure that > > "gateway" in this document does not encompass VPN clients and hosts, right? > > > > Kaz > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of > >> Yaron Sheffer > >> Sent: Friday, March 26, 2010 3:31 AM > >> To: SeongHan Shin > >> Cc: IPsecme WG; Kazukuni Kobara > >> Subject: Re: [IPsec] New PAKE Criteria draft posted > >> > >> Hi Shin, > >> > >> Yes. For the typical remote access VPN, EAP is typically more useful. > >> Note that there is still need for strong password-based mutual > >> authentication EAP methods - but their home is the EMU working group. > >> > >> In addition, the IPsecME has another charter item designed to fit such > >> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. > >> > >> Please see again the group's charter, > >> http://tools.ietf.org/wg/ipsecme/charters. > >> > >> Thanks, > >> Yaron > >> > >> On 25.3.2010 20:07, SeongHan Shin wrote: > >>> Dear Yaron Sheffer, > >>> > >>> I have one question about the draft. > >>> > >>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 > >>> "This document is limited to the use of password-based authentication > >> to > >>> achieve trust between gateways" > >>> > >>> Is this a consensus of this WG? > >>> > >>> Best regards, > >>> Shin > >>> > >>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer >>> > wrote: > >>> > >>> Hi, > >>> > >>> after the good discussion in Anaheim, and with the help of comments > >>> received on and off the list, I have updated the PAKE Criteria > draft > >>> and posted it as > >>> > >> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. > >>> > >>> I have added a number of criteria, clarified others, and added > >>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). > >>> > >>> Thanks, > >>> Yaron > >>> _______________________________________________ > >>> IPsec mailing list > >>> IPsec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipsec > >>> > >>> > >>> > >>> > >>> -- > >>> ------------------------------------------------------------------ > >>> SeongHan Shin > >>> Research Center for Information Security (RCIS), > >>> National Institute of Advanced Industrial Science and Technology > (AIST), > >>> Room no. 1003, Akihabara Daibiru 10F, > >>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan > >>> Tel : +81-3-5298-2722 > >>> Fax : +81-3-5298-4522 > >>> E-mail : seonghan.shin@aist.go.jp > >>> ------------------------------------------------------------------ > >> _______________________________________________ > >> 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 Fri Mar 26 10:11:37 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5DE3A6B21 for ; Fri, 26 Mar 2010 10:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.609 X-Spam-Level: X-Spam-Status: No, score=-4.609 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX496-weggh1 for ; Fri, 26 Mar 2010 10:11:36 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id EBBB73A6AF4 for ; Fri, 26 Mar 2010 10:11:35 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 916B21022404A; Fri, 26 Mar 2010 10:11:59 -0700 (PDT) Received: from 130.129.26.143 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 26 Mar 2010 10:11:59 -0700 (PDT) Message-ID: In-Reply-To: <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> Date: Fri, 26 Mar 2010 10:11:59 -0700 (PDT) From: "Dan Harkins" To: "Kaz Kobara" 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 Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 17:11:37 -0000 Telling administrators what they can and cannot do is really not the function of our standards body. If someone wants to use a "long secret" or a password to authenticate gateways, hosts, clients, peers, or implementations (or whatever you want to call the box) it's none of our business. We shouldn't say, "nope, sorry you can't do that, this is a client and you should use a stand-alone AAA server because of the obvious benefits that have eluded you." We have RFCs on "host requirements" and "router requirements". There isn't an RFC on "peer requirements" or "client requirements". Those are terms that started in marketecture powerpoint slides and should not be used to constrain or neuter our protocols. Dan. On Fri, March 26, 2010 9:53 am, Kaz Kobara wrote: > Hi Yaron > > Thank you for your clarification. > >> "between gateways" as opposed to >> "between clients and gateways". So your assertion is correct. > > (Between gateways, administrators can set long secrets, so the necessity > of > PAKE seems smaller than between clients and gateways where passwords are > recorded in the gateways and users have to type the passwords.) > > Anyway, if the scope is limited only on "between gateways" but not > "between > clients and gateways," the title > "Password-Based Authentication in IKEv2: Selection Criteria and > Comparison" > seems misleading (since this itself misinforms that this criteria may be > applied to IKEv2 in any cases), and the above should be clearly mentioned > in > the document. > > Kaz > >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Friday, March 26, 2010 2:14 PM >> To: Kaz Kobara >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) >> >> Hi Kaz, >> >> I *thought* my intention was clear: "between gateways" as opposed to >> "between clients and gateways". So your assertion is correct. >> >> Thanks, >> Yaron >> >> On 26.3.2010 1:40, Kaz Kobara wrote: >> > Hi Yaron >> > >> >> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >> >> "This document is limited to the use of password-based authentication >> to >> >> achieve trust between gateways" >> > >> > I would like to make sure that >> > "gateway" in this document does not encompass VPN clients and hosts, > right? >> > >> > Kaz >> > >> >> -----Original Message----- >> >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >> Behalf >> Of >> >> Yaron Sheffer >> >> Sent: Friday, March 26, 2010 3:31 AM >> >> To: SeongHan Shin >> >> Cc: IPsecme WG; Kazukuni Kobara >> >> Subject: Re: [IPsec] New PAKE Criteria draft posted >> >> >> >> Hi Shin, >> >> >> >> Yes. For the typical remote access VPN, EAP is typically more useful. >> >> Note that there is still need for strong password-based mutual >> >> authentication EAP methods - but their home is the EMU working group. >> >> >> >> In addition, the IPsecME has another charter item designed to fit >> such >> >> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >> >> >> >> Please see again the group's charter, >> >> http://tools.ietf.org/wg/ipsecme/charters. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> On 25.3.2010 20:07, SeongHan Shin wrote: >> >>> Dear Yaron Sheffer, >> >>> >> >>> I have one question about the draft. >> >>> >> >>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >> >>> "This document is limited to the use of password-based >> authentication >> >> to >> >>> achieve trust between gateways" >> >>> >> >>> Is this a consensus of this WG? >> >>> >> >>> Best regards, >> >>> Shin >> >>> >> >>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer> >>> > wrote: >> >>> >> >>> Hi, >> >>> >> >>> after the good discussion in Anaheim, and with the help of > comments >> >>> received on and off the list, I have updated the PAKE Criteria >> draft >> >>> and posted it as >> >>> >> >> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >> >>> >> >>> I have added a number of criteria, clarified others, and added >> >>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >> >>> >> >>> Thanks, >> >>> Yaron >> >>> _______________________________________________ >> >>> IPsec mailing list >> >>> IPsec@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ipsec >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> ------------------------------------------------------------------ >> >>> SeongHan Shin >> >>> Research Center for Information Security (RCIS), >> >>> National Institute of Advanced Industrial Science and Technology >> (AIST), >> >>> Room no. 1003, Akihabara Daibiru 10F, >> >>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >> >>> Tel : +81-3-5298-2722 >> >>> Fax : +81-3-5298-4522 >> >>> E-mail : seonghan.shin@aist.go.jp >> >>> ------------------------------------------------------------------ >> >> _______________________________________________ >> >> 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 latten@austin.ibm.com Fri Mar 26 14:46:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB5F3A67D3 for ; Fri, 26 Mar 2010 14:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzX+gh6nu+0J for ; Fri, 26 Mar 2010 14:46:21 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 6BDBC3A63EC for ; Fri, 26 Mar 2010 14:46:21 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o2QLdsDH024153 for ; Fri, 26 Mar 2010 15:39:54 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o2QLkEn9145772 for ; Fri, 26 Mar 2010 15:46:14 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o2QEkEtx016868 for ; Fri, 26 Mar 2010 08:46:14 -0600 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o2QEkD7F016857; Fri, 26 Mar 2010 08:46:13 -0600 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id o2QLkDmm046370; Fri, 26 Mar 2010 16:46:13 -0500 From: Joy Latten To: mlepinski@bbn.com, kent@bbn.com Content-Type: text/plain; charset="UTF-8" Date: Fri, 26 Mar 2010 16:25:01 -0500 Message-Id: <1269638701.2838.303.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 8bit Cc: ipsec@ietf.org, avagarwa@redhat.com Subject: [IPsec] Question about RFC 5114 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 21:46:22 -0000 Hi, I am looking to implement modp groups 22, 23, and 24 into IKE but have a question. RFC 5114 gives the prime, p, the generator, g and a subgroup, q, with a specific size... Because prior rfcs for modp groups did not specify a "q", I was not sure if this was a new constant or just stating a size requirement? So I took a look at NIST 800-56A. In particular, 5.6.1 Private/Public Key Pair Generation 5.6.1.1 FFC Key Pair Generation For the FFC schemes, each static and ephemeral private key and public key shall be generated using an Approved method and the selected valid domain parameters (p, q, g{, SEED,pgenCounter}) (see Appendix B of FIPS 186-3). ... I then took a look at FIPS 186-3, Appendix B, which documents 2 methods for finite field cryptography (FFC) key pair generation. For example, one method is "Key Pair Generation Using Extra Random Bits". It actually states that "q" is an input and it is used to do an additional computation to compute "x". I am somewhat confused, are the modp groups 22, 23 & 24 suppose to use one of these new methods and that is why "q" is given in rfc 5114? Or am I to ignore this and just continue with existing way where "q" is not used and there aren't any additional computations to compute x. I am not even sure this is correct place to ask, but any advice would be welcome. regards, Joy (Cut-n-paste from FIPs 186-3 below to show input and process) Input: (p, q, g) The subset of the domain parameters that are used for this process. p, q and g shall either be provided as integers during input, or shall be converted to integers prior to use. Process: 1. N = len(q); L = len(p). Comment: Check that the (L, N) pair is specified in Section 4.2. 2. If the (L, N) pair is invalid, then return an ERROR indicator, Invalid_x, and Invalid_y. 3. requested_security_strength = the security strength associated with the (L, N) pair; see SP 800-57. 4. Obtain a string of N+64 returned_bits from an RBG with a security strength of requested_security_strength or more. If an ERROR indication is returned, then return an ERROR indication, Invalid_x, and Invalid_y. 5. Convert returned_bits to the (non-negative) integer c (see Appendix C.2.1). 6. x = (c mod (q–1)) + 1. Comment: 0 ≤ c mod (q–1) ≤ q–2 and implies that 1 ≤ x ≤ q–1. 7. y = gx mod p. 8. Return SUCCESS, x, and y. From kobara_conf@m.aist.go.jp Fri Mar 26 15:28:59 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E343A6C41 for ; Fri, 26 Mar 2010 15:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-uRgylgQqXy for ; Fri, 26 Mar 2010 15:28:59 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id 06F203A6B69 for ; Fri, 26 Mar 2010 15:28:57 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o2QMRjls017931; Sat, 27 Mar 2010 07:27:45 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=m.aist.go.jp; s=aist; t=1269642466; bh=vwwJRfsunJQZVN+3DQNfpOzYx43UyKshxCLxCUDzpaQ=; h=From:Date:Message-ID; b=pNdhWlvQc421D1ytQx/RzeoAyV6Pqogo3bmtz9qJYaW+d9TBNszrKAvEIeOL8UG6K 8eLD40ffR16p/SXRS2Wp0Y10xVdghL+Z8q57WF/F9WVtqyfIW1Da0wn5bZMu5iXSHc n8+FYyXjmm6RjksOVFg8hUBHNAPK6iK93KA76/7I= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o2QMRjqG016070; Sat, 27 Mar 2010 07:27:45 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id o2QMRgPl024021; Sat, 27 Mar 2010 07:27:42 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) From: "Kaz Kobara" To: , , Date: Sat, 27 Mar 2010 07:27:47 +0900 Message-ID: <019801cacd33$9129c3a0$b37d4ae0$@aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrNLd2v1FtQCtn+Toyd9NY0qei8ZgAAiiWgAADYLcA= Content-Language: ja Cc: ipsec@ietf.org, avagarwa@redhat.com Subject: Re: [IPsec] Question about RFC 5114 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 22:28:59 -0000 Hi Joy When one uses a subgroup like defined in RFC 5114, q (and (p-1)/2q ) = must be chosen carefully. Precisely: 1. q must be a prime number of 2k or more bits where k is a security = parameter. 2. q must be a divisor of ((p - 1) / 2). 3. Every factors of (p - 1) / (2q) must also be primes comparable to or = greater than q in size. =20 p corresponding such q is called a "secure prime." X is simply to shift the range of 0 to q-2 to 1 to q-1 to exclude 0 = (since g^0 mod p =3D 1). Kaz > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of > Joy Latten > Sent: Saturday, March 27, 2010 6:25 AM > To: mlepinski@bbn.com; kent@bbn.com > Cc: ipsec@ietf.org; avagarwa@redhat.com > Subject: [IPsec] Question about RFC 5114 >=20 > Hi, >=20 > I am looking to implement modp groups 22, 23, and 24 into IKE but have = a > question. >=20 > RFC 5114 gives the prime, p, the generator, g and a subgroup, q, with = a > specific size... >=20 > Because prior rfcs for modp groups did not specify a "q", I was not = sure > if this was a new constant or just stating a size requirement? > So I took a look at NIST 800-56A. In particular, >=20 > 5.6.1 Private/Public Key Pair Generation >=20 > 5.6.1.1 FFC Key Pair Generation > For the FFC schemes, each static and ephemeral private key and public > key shall be generated using an Approved method and the selected valid > domain parameters (p, q, g{, SEED,pgenCounter}) (see Appendix B of = FIPS > 186-3). > ... >=20 > I then took a look at FIPS 186-3, Appendix B, which documents 2 = methods > for finite field cryptography (FFC) key pair generation. > For example, one method is "Key Pair Generation Using Extra Random > Bits". It actually states that "q" is an input and it is used to do an > additional computation to compute "x". >=20 > I am somewhat confused, are the modp groups 22, 23 & 24 suppose to use > one of these new methods and that is why "q" is given in rfc 5114? > Or am I to ignore this and just continue with existing way > where "q" is not used and there aren't any additional computations > to compute x. >=20 > I am not even sure this is correct place to ask, but any advice > would be welcome. >=20 > regards, > Joy >=20 >=20 > (Cut-n-paste from FIPs 186-3 below to show input and process) >=20 > Input: > (p, q, g) The subset of the domain parameters that are used > for this process. p, q and g shall either be > provided as integers during input, or shall be > converted to integers prior to use. >=20 > Process: > 1. N =3D len(q); L =3D len(p). Comment: Check that the (L, N) pair > is specified in Section 4.2. > 2. If the (L, N) pair is invalid, then return an ERROR indicator, > Invalid_x, and Invalid_y. > 3. requested_security_strength =3D the security strength associated > with the (L, N) pair; see SP 800-57. > 4. Obtain a string of N+64 returned_bits from an RBG with a security > strength of requested_security_strength or more. If an ERROR > indication is returned, then return an ERROR indication, > Invalid_x, and Invalid_y. > 5. Convert returned_bits to the (non-negative) integer c (see > Appendix C.2.1). > 6. x =3D (c mod (q=E2=80=931)) + 1. Comment: 0 =E2=89=A4 c mod = (q=E2=80=931) =E2=89=A4 q=E2=80=932 and > implies that 1 =E2=89=A4 x =E2=89=A4 = q=E2=80=931. > 7. y =3D gx mod p. > 8. Return SUCCESS, x, and y. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From dharkins@lounge.org Fri Mar 26 16:55:32 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B413A6A7D for ; Fri, 26 Mar 2010 16:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN6TEMW3mVrw for ; Fri, 26 Mar 2010 16:55:31 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 539113A683C for ; Fri, 26 Mar 2010 16:55:31 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 386BE1022404A; Fri, 26 Mar 2010 16:55:55 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 26 Mar 2010 16:55:55 -0700 (PDT) Message-ID: <246830bbd70485253e0824df38f2fda5.squirrel@www.trepanning.net> In-Reply-To: <1269638701.2838.303.camel@faith.austin.ibm.com> References: <1269638701.2838.303.camel@faith.austin.ibm.com> Date: Fri, 26 Mar 2010 16:55:55 -0700 (PDT) From: "Dan Harkins" To: latten@austin.ibm.com 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, avagarwa@redhat.com, kent@bbn.com, mlepinski@bbn.com Subject: Re: [IPsec] Question about RFC 5114 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 23:55:32 -0000 Hi Joy, "q" is the order of the group defined by the "g". If you want to use the FIPS 186-3 process for generating a D-H key pair with the other MODP groups that don't have a defined order (like 5, 14, 15, 16...) you can just use (p-1/2) for the value "q". There are going to be q distinct elements in the group and while D-H will work with a private value x: q < x < p, you will be doing more modular exponentiation. The FIPS 186-3 process is ensuring that your private value, x, will be taken from a uniformly random distribution of numbers less than q and therefore the public value y=g^x mod p will be a random element in the group (which is what you need for D-H). regards, Dan. On Fri, March 26, 2010 2:25 pm, Joy Latten wrote: > Hi, > > I am looking to implement modp groups 22, 23, and 24 into IKE but have a > question. > > RFC 5114 gives the prime, p, the generator, g and a subgroup, q, with a > specific size... > > Because prior rfcs for modp groups did not specify a "q", I was not sure > if this was a new constant or just stating a size requirement? > So I took a look at NIST 800-56A. In particular, > > 5.6.1 Private/Public Key Pair Generation > > 5.6.1.1 FFC Key Pair Generation > For the FFC schemes, each static and ephemeral private key and public > key shall be generated using an Approved method and the selected valid > domain parameters (p, q, g{, SEED,pgenCounter}) (see Appendix B of FIPS > 186-3). > ... > > I then took a look at FIPS 186-3, Appendix B, which documents 2 methods > for finite field cryptography (FFC) key pair generation. > For example, one method is "Key Pair Generation Using Extra Random > Bits". It actually states that "q" is an input and it is used to do an > additional computation to compute "x". > > I am somewhat confused, are the modp groups 22, 23 & 24 suppose to use > one of these new methods and that is why "q" is given in rfc 5114? > Or am I to ignore this and just continue with existing way > where "q" is not used and there aren't any additional computations > to compute x. > > I am not even sure this is correct place to ask, but any advice > would be welcome. > > regards, > Joy > > > (Cut-n-paste from FIPs 186-3 below to show input and process) > > Input: > (p, q, g) The subset of the domain parameters that are used > for this process. p, q and g shall either be > provided as integers during input, or shall be > converted to integers prior to use. > > Process: > 1. N = len(q); L = len(p). Comment: Check that the (L, N) pair > is specified in Section 4.2. > 2. If the (L, N) pair is invalid, then return an ERROR indicator, > Invalid_x, and Invalid_y. > 3. requested_security_strength = the security strength associated > with the (L, N) pair; see SP 800-57. > 4. Obtain a string of N+64 returned_bits from an RBG with a security > strength of requested_security_strength or more. If an ERROR > indication is returned, then return an ERROR indication, > Invalid_x, and Invalid_y. > 5. Convert returned_bits to the (non-negative) integer c (see > Appendix C.2.1). > 6. x = (c mod (q–1)) + 1. Comment: 0 ≤ c mod (q–1) ≤ q–2 > and > implies that 1 ≤ x ≤ q–1. > 7. y = gx mod p. > 8. Return SUCCESS, x, and y. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From sfluhrer@cisco.com Fri Mar 26 19:48:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07DEE3A6C58 for ; Fri, 26 Mar 2010 19:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBMOtt7LTiOC for ; Fri, 26 Mar 2010 19:48:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D29FB3A6A2C for ; Fri, 26 Mar 2010 19:48:23 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAUPrUurR7H+/2dsb2JhbACDGZc4XHOlHog9kGCBK4JpagSDHg X-IronPort-AV: E=Sophos;i="4.51,318,1267401600"; d="scan'208";a="503792590" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 27 Mar 2010 02:48:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2R2mmin014987; Sat, 27 Mar 2010 02:48:48 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.3959); Fri, 26 Mar 2010 19:48:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 26 Mar 2010 19:48:42 -0700 Message-ID: In-Reply-To: <1269638701.2838.303.camel@faith.austin.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Question about RFC 5114 Thread-Index: AcrNLdpr6ZJzRGD+TzKMSY5v7IUs1QAAOhXw X-Priority: 5 Priority: Non-Urgent Importance: low References: <1269638701.2838.303.camel@faith.austin.ibm.com> From: "Scott Fluhrer (sfluhrer)" To: , , X-OriginalArrivalTime: 27 Mar 2010 02:48:48.0163 (UTC) FILETIME=[0665C730:01CACD58] Cc: ipsec@ietf.org, avagarwa@redhat.com Subject: Re: [IPsec] Question about RFC 5114 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 02:48:25 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXBzZWMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBK b3kgTGF0dGVuDQo+IFNlbnQ6IEZyaWRheSwgTWFyY2ggMjYsIDIwMTAgNToyNSBQTQ0KPiBUbzog bWxlcGluc2tpQGJibi5jb207IGtlbnRAYmJuLmNvbQ0KPiBDYzogaXBzZWNAaWV0Zi5vcmc7IGF2 YWdhcndhQHJlZGhhdC5jb20NCj4gU3ViamVjdDogW0lQc2VjXSBRdWVzdGlvbiBhYm91dCBSRkMg NTExNA0KPiANCj4gSGksDQo+IA0KPiBJIGFtIGxvb2tpbmcgdG8gaW1wbGVtZW50IG1vZHAgZ3Jv dXBzIDIyLCAyMywgYW5kIDI0IGludG8gSUtFIGJ1dCBoYXZlDQo+IGENCj4gcXVlc3Rpb24uDQo+ IA0KPiBSRkMgNTExNCBnaXZlcyB0aGUgcHJpbWUsIHAsIHRoZSBnZW5lcmF0b3IsIGcgYW5kIGEg c3ViZ3JvdXAsIHEsIHdpdGggYQ0KPiBzcGVjaWZpYyBzaXplLi4uDQo+IA0KPiBCZWNhdXNlIHBy aW9yIHJmY3MgZm9yIG1vZHAgZ3JvdXBzIGRpZCBub3Qgc3BlY2lmeSBhICJxIiwgSSB3YXMgbm90 DQo+IHN1cmUNCj4gaWYgdGhpcyB3YXMgYSBuZXcgY29uc3RhbnQgb3IganVzdCBzdGF0aW5nIGEg c2l6ZSByZXF1aXJlbWVudD8NCg0KcSBpcyB0aGUgb3JkZXIgb2YgdGhlIGdlbmVyYXRvci4gIEZv ciB0aGUgcHJldmlvdXMgKHRyYWRpdGlvbmFsKSBNT0RQIGdyb3VwcyAoMSwyLDUsMTQtMTgpLCB3 ZSBoYXZlIHE9KHAtMSkvMg0KDQo+IFNvIEkgdG9vayBhIGxvb2sgYXQgTklTVCA4MDAtNTZBLiBJ biBwYXJ0aWN1bGFyLA0KPiANCj4gNS42LjEgUHJpdmF0ZS9QdWJsaWMgS2V5IFBhaXIgR2VuZXJh dGlvbg0KPiANCj4gNS42LjEuMSBGRkMgS2V5IFBhaXIgR2VuZXJhdGlvbg0KPiBGb3IgdGhlIEZG QyBzY2hlbWVzLCBlYWNoIHN0YXRpYyBhbmQgZXBoZW1lcmFsIHByaXZhdGUga2V5IGFuZCBwdWJs aWMNCj4ga2V5IHNoYWxsIGJlIGdlbmVyYXRlZCB1c2luZyBhbiBBcHByb3ZlZCBtZXRob2QgYW5k IHRoZSBzZWxlY3RlZCB2YWxpZA0KPiBkb21haW4gcGFyYW1ldGVycyAocCwgcSwgZ3ssIFNFRUQs cGdlbkNvdW50ZXJ9KSAoc2VlIEFwcGVuZGl4IEIgb2YgRklQUw0KPiAxODYtMykuDQo+IC4uLg0K PiANCj4gSSB0aGVuIHRvb2sgYSBsb29rIGF0IEZJUFMgMTg2LTMsIEFwcGVuZGl4IEIsIHdoaWNo IGRvY3VtZW50cyAyIG1ldGhvZHMNCj4gZm9yIGZpbml0ZSBmaWVsZCBjcnlwdG9ncmFwaHkgKEZG Qykga2V5IHBhaXIgZ2VuZXJhdGlvbi4NCj4gRm9yIGV4YW1wbGUsIG9uZSBtZXRob2QgaXMgIktl eSBQYWlyIEdlbmVyYXRpb24gVXNpbmcgRXh0cmEgUmFuZG9tDQo+IEJpdHMiLiBJdCBhY3R1YWxs eSBzdGF0ZXMgdGhhdCAicSIgaXMgYW4gaW5wdXQgYW5kIGl0IGlzIHVzZWQgdG8gZG8gYW4NCj4g YWRkaXRpb25hbCBjb21wdXRhdGlvbiB0byBjb21wdXRlICJ4Ii4NCj4gDQo+IEkgYW0gc29tZXdo YXQgY29uZnVzZWQsIGFyZSB0aGUgbW9kcCBncm91cHMgMjIsIDIzICYgMjQgc3VwcG9zZSB0byB1 c2UNCj4gb25lIG9mIHRoZXNlIG5ldyBtZXRob2RzIGFuZCB0aGF0IGlzIHdoeSAicSIgaXMgZ2l2 ZW4gaW4gcmZjIDUxMTQ/DQo+IE9yIGFtIEkgdG8gaWdub3JlIHRoaXMgYW5kIGp1c3QgY29udGlu dWUgd2l0aCBleGlzdGluZyB3YXkNCj4gd2hlcmUgInEiIGlzIG5vdCB1c2VkIGFuZCB0aGVyZSBh cmVuJ3QgYW55IGFkZGl0aW9uYWwgY29tcHV0YXRpb25zDQo+IHRvIGNvbXB1dGUgeC4NCg0KU2hv cnQgYW5zd2VyOiBpdCBkb2Vzbid0IHJlYWxseSBtYXR0ZXI7IHRoZSBvbGQgd2F5IGlzIHNhZmUg KGZvciBESCkuDQoNCkxvbmdlciBhbnN3ZXI6IEZJUFMgMTg2LTMgd2FzIHdyaXR0ZW4gYWJvdXQg Z2VuZXJhdGluZyB2YWx1ZXMgZm9yIERTQSwgbm90IERILiAgTm93LCBmb3IgRFNBLCB0aGVyZSBp cyBhIGtub3duIHdlYWtuZXNzIGlmIHRoZSBleHBvbmVudHMgeW91IHVzZSBhcmUgYmlhc2VkOyB0 aGVzZSBhbGdvcml0aG1zIHVzZWQgaW4gRklQUyAxODYtMyB3ZXJlIGRlc2lnbmVkIHRvIG1ha2Ug c3VyZSB0aGF0IHRoZSBleHBvbmVudHMgYXJlIHVuYmlhc2VkIChvciBjbG9zZSBlbm91Z2ggbm90 IHRvIG1hdHRlcikuICBESCBkb2Vzbid0IGhhdmUgc2ltaWxhciBpc3N1ZXMsIGFuZCBzbyB0aGVz ZSBzdGVwcyBhcmVuJ3QgcmVxdWlyZWQgKGFsdGhvdWdoIHRoZXkgd291bGRuJ3QgaHVydCBlaXRo ZXIpLg0KDQpOb3csIHlvdSBkb27igJl0IG5lZWQgdG8gdXNlIHRoZSBzYW1lIGV4cG9uZW50IHNp emUgdGhhdCB5b3Ugd291bGQgdXNlIGZvciB0aGUgc2FtZSBzaXplIHRyYWRpdGlvbmFsIGdyb3Vw czsgZm9yIGV4YW1wbGUsIFJGQzM1MjYgc3VnZ2VzdHMgYW4gZXhwb25lbnQgb2YgYmV0d2VlbiAy MjAtMzIwIGJpdHMgZm9yIGdyb3VwIDE0OyBmb3IgZ3JvdXAgMjQsIHRoZXJlJ3Mgbm8gcG9pbnQg aW4gYW4gZXhwb25lbnQgZ3JlYXRlciB0aGFuIDI1NiBiaXRzLiAgVGhpcyBpcyBiZWNhdXNlIHRo ZSBleHBvbmVudCBpcyBlc3NlbnRpYWxseSB0YWtlbiAibW9kIHEiIGJ5IHRoZSBhbGdvcml0aG0s IGFuZCBzbyBtYWtpbmcgaXQgbGFyZ2VyIHRoYW4gcSBnaXZlcyB5b3UgbW9yZSB3b3JrIHdpdGhv dXQgZ2l2aW5nIGFueSBiZW5lZml0LiAgTm90ZSB0aGF0IHdoZW4gRklQUyAxODYtMyB0YWxrcyBh Ym91dCB1c2luZyAiZXh0cmEgcmFuZG9tIGJpdHMiLCB0aGV5IHJlZHVjZSB0aGUgbGFyZ2VyIHZh bHVlIHNvIHRoYXQgaXQgaXMgPHEgKHN0ZXAgNiBvZiBCLjEuMSkuDQoNCg0KT24gdGhlIG90aGVy IGhhbmQsIE5JU1QgU1AgODAwLTU2QSBhbHNvIGFza3MgeW91IHRvIHZhbGlkYXRlIHRoZSBwZWVy IHB1YmxpYyB2YWx1ZSAoc2VjdGlvbiA1LjYuMi40KSwgYW5kIHRoaXMgYWxzbyB1c2VzIHEgYXMg YW4gaW5wdXQuICBIZXJlJ3Mgd2h5IHRoYXQgcmVhbGx5IGRvZXMgbWF0dGVyIGZvciBncm91cHMg MjItMjQgKGFuZCBub3Qgc28gbXVjaCBmb3IgZ3JvdXBzIDEsMiw1LDE0LTE4KToNCg0KLSBJZiB5 b3UgcmV1c2UgREggZXhwb25lbnRzLCBhbmQgeW91IGRvbid0IHZhbGlkYXRlIHRoZSBwZWVyJ3Mg cHVibGljIHZhbHVlLCB0aGVuIHRoZXJlIGlzIGEgd2F5IGZvciBhbiBhdHRhY2tlciB0byBkZXRl cm1pbmUgdGhlIHZhbHVlIG9mIHlvdXIgZXhwb25lbnQgbW9kdWxvIHIsIHdoZXJlIHIgaXMgYSBz bWFsbCBmYWN0b3Igb2YgKHAtMSkvcS4NCi0gVGhpcyBhdHRhY2sgaW52b2x2ZXMgc2VuZGluZyBp bGxlZ2FsIHBlZXIgcHVibGljIHZhbHVlcyBhcyBhIHBhcnQgb2YgdGhlIElLRSBleGNoYW5nZSwg YW5kIHNlZWluZyB3aGF0IGtleWluZyBtYXRlcmlhbCB0aGUgdW5pdCBjb21lcyB1cCB3aXRoLiAg QmVjYXVzZSB0aGVzZSB2YWx1ZXMgYXJlIGlsbGVnYWwsIHZhbGlkYXRpbmcgdGhlIHZhbHVlcyBm b2lscyB0aGUgYXR0YWNrLg0KLSBUaGlzIHRha2VzIE8ocikgdGltZSBvbiB0aGUgYXR0YWNrZXIn cyBwYXJ0LCB3aGljaCBpcyB3aHkgciBjYW4ndCBiZSB0b28gbGFyZ2UuDQoNCkZvciB0aGUgdHJh ZGl0aW9uYWwgZ3JvdXBzLCAocC0xKS9xID09IDIsIGFuZCBzbyByPTIgaXMgdGhlIG9ubHkgb25l IHRoZSBhdHRhY2tlciBjYW4gdXNlIChoZW5jZSB0aGUgYXR0YWNrZXIgd291bGQgYmUgYWJsZSB0 byBkZXRlcm1pbmUgdGhlIGxzYml0IG9mIHlvdXIgZXhwb25lbnQgdmlhIHRoaXMgYXR0YWNrLCBi dXQgbm90aGluZyBlbHNlKS4gIEl0IHR1cm5zIG91dCB0aGF0IHRoZXJlJ3MgYSBzaG9ydCBjdXQg dG8gdGVzdCBvbiB0aGUgcGVlciBwdWJsaWMgdmFsdWUgaW4gdGhpcyBjYXNlIChjb21wdXRlIHRo ZSBMZWdlbmRyZSBzeW1ib2wpLCBidXQgZXZlbiBpZiB5b3UgZG9uJ3QsIHRoZSBhdHRhY2tlciBn ZXRzIG1pbmltYWwgaW5mb3JtYXRpb24uDQoNCkZvciB0aGVzZSBuZXcgZ3JvdXBzLCAocC0xKS9x IGlzIHF1aXRlIGxhcmdlLCBhbmQgaW4gYWxsIHRocmVlIGNhc2VzLCBoYXMgYSBudW1iZXIgb2Yg c21hbGwgZmFjdG9ycyAobm93LCBOSVNUIGNvdWxkIGhhdmUgZGVmaW5lZCBncm91cHMgd2hlcmUg KHAtMSkvcSBoYXMgMiBhcyB0aGUgb25seSBzbWFsbCBmYWN0b3I7IHRoZXkgZGVjbGluZWQgdG8g ZG8gc28pLiAgRm9yIGV4YW1wbGUsIGZvciBncm91cCAyMyAod2hpY2ggaXMgdGhlIHdvcnNlIG9m IHRoZSB0aHJlZSksIChwLTEpL3EgPT0gIDIgKiAzICogMyAqIDUgKiA0MyAqIDczICogMTU3ICog Mzg3NDkzICogNjA1OTIxICogNTIxMzg4MTE3NyAqIDM1Mjg5MTA3NjA3MTcgKiA4MzUwMTgwNzAy MDQ3MzQyOTM0OSAqIEM0ODkgKHdoZXJlIEM0ODkgaXMgYSA0ODkgZGlnaXQgY29tcG9zaXRlIG51 bWJlciB3aXRoIG5vIHNtYWxsIGZhY3RvcnMpLiAgVGhlIGF0dGFja2VyIGNvdWxkIHVzZSB0aGlz IChhZ2FpbiwgaWYgeW91IGRvbid0IHZhbGlkYXRlIHRoZSBwZWVyIHZhbHVlKSB0byBlZmZlY3Rp dmUgY3V0IHlvdXIgZXhwb25lbnQgc2l6ZSBieSBhYm91dCAxMzcgYml0cyB3aXRoIHVzaW5nIG9u bHkgIE8oMioqNDIpIHRpbWUpOyBpZiB5b3UgdXNlZCAyMjQgYml0IGV4cG9uZW50cywgdGhlbiB0 aGUgYXR0YWNrZXIgd291bGQgY3V0IHRoZSB3b3JrIHVzZWQgdG8gZmluZCB0aGUgcmVzdCBvZiB0 aGUgZXhwb25lbnQgdG8gYWJvdXQgTygyKio0NCkgdGltZS4gIE9idmlvdXNseSwgdGhpcyBpcyBu b3QgYWNjZXB0YWJsZS4NCg0KDQoNCj4gDQo+IEkgYW0gbm90IGV2ZW4gc3VyZSB0aGlzIGlzIGNv cnJlY3QgcGxhY2UgdG8gYXNrLCBidXQgYW55IGFkdmljZQ0KPiB3b3VsZCBiZSB3ZWxjb21lLg0K PiANCj4gcmVnYXJkcywNCj4gSm95DQo+IA0KPiANCj4gKEN1dC1uLXBhc3RlIGZyb20gRklQcyAx ODYtMyBiZWxvdyB0byBzaG93IGlucHV0IGFuZCBwcm9jZXNzKQ0KPiANCj4gIElucHV0Og0KPiAg ICAgKHAsIHEsIGcpICAgICAgVGhlIHN1YnNldCBvZiB0aGUgZG9tYWluIHBhcmFtZXRlcnMgdGhh dCBhcmUgdXNlZA0KPiAgICAgICAgICAgICAgICAgICAgZm9yIHRoaXMgcHJvY2Vzcy4gcCwgcSBh bmQgZyBzaGFsbCBlaXRoZXIgYmUNCj4gICAgICAgICAgICAgICAgICAgIHByb3ZpZGVkIGFzIGlu dGVnZXJzIGR1cmluZyBpbnB1dCwgb3Igc2hhbGwgYmUNCj4gICAgICAgICAgICAgICAgICAgIGNv bnZlcnRlZCB0byBpbnRlZ2VycyBwcmlvciB0byB1c2UuDQo+IA0KPiBQcm9jZXNzOg0KPiAxLiBO ID0gbGVuKHEpOyBMID0gbGVuKHApLiAgICBDb21tZW50OiBDaGVjayB0aGF0IHRoZSAoTCwgTikg cGFpcg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpcyBzcGVjaWZpZWQgaW4gU2Vj dGlvbiA0LjIuDQo+IDIuIElmIHRoZSAoTCwgTikgcGFpciBpcyBpbnZhbGlkLCB0aGVuIHJldHVy biBhbiBFUlJPUiBpbmRpY2F0b3IsDQo+ICAgIEludmFsaWRfeCwgYW5kIEludmFsaWRfeS4NCj4g My4gcmVxdWVzdGVkX3NlY3VyaXR5X3N0cmVuZ3RoID0gdGhlIHNlY3VyaXR5IHN0cmVuZ3RoIGFz c29jaWF0ZWQNCj4gICAgd2l0aCB0aGUgKEwsIE4pIHBhaXI7ICAgICAgc2VlIFNQIDgwMC01Ny4N Cj4gNC4gT2J0YWluIGEgc3RyaW5nIG9mIE4rNjQgcmV0dXJuZWRfYml0cyBmcm9tIGFuIFJCRyB3 aXRoIGEgc2VjdXJpdHkNCj4gICAgc3RyZW5ndGggb2YgcmVxdWVzdGVkX3NlY3VyaXR5X3N0cmVu Z3RoIG9yIG1vcmUuIElmIGFuIEVSUk9SDQo+ICAgIGluZGljYXRpb24gaXMgcmV0dXJuZWQsIHRo ZW4gcmV0dXJuIGFuIEVSUk9SIGluZGljYXRpb24sDQo+ICAgIEludmFsaWRfeCwgYW5kIEludmFs aWRfeS4NCj4gNS4gQ29udmVydCByZXR1cm5lZF9iaXRzIHRvIHRoZSAobm9uLW5lZ2F0aXZlKSBp bnRlZ2VyIGMgKHNlZQ0KPiAgICBBcHBlbmRpeCBDLjIuMSkuDQo+IDYuIHggPSAoYyBtb2QgKHHi gJMxKSkgKyAxLiAgICAgICBDb21tZW50OiAwIOKJpCBjIG1vZCAoceKAkzEpIOKJpCBx4oCTMiBh bmQNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbXBsaWVzIHRoYXQgMSDiiaQg eCDiiaQgceKAkzEuDQo+IDcuIHkgPSBneCBtb2QgcC4NCj4gOC4gUmV0dXJuIFNVQ0NFU1MsIHgs IGFuZCB5Lg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gSVBzZWMgbWFpbGluZyBsaXN0DQo+IElQc2VjQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg== From yaronf.ietf@gmail.com Sat Mar 27 07:05:12 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3213A67F3 for ; Sat, 27 Mar 2010 07:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2R17FY+x4FL for ; Sat, 27 Mar 2010 07:05:11 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 9E2403A63EB for ; Sat, 27 Mar 2010 07:05:09 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2581281fga.13 for ; Sat, 27 Mar 2010 07:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=G7Z2MtFulPpcI/2SCRrIm8Kcy3B9IYA03jN4NBT6NGg=; b=Od8Lnc/gJYyUhLSYPqAIULk7MAi7ujrOWZYpJVpN9S2oqA/wQH0ok5W2VG76tbBbXB lOwfYFIEzve8uE4RzliZohMjNMUWE2L4VyKp2xsteI8ImIibxlRWBoWjP9oGUthbl6Qt QqSlO93EaQP8fO1aTzI4rKDOu0ByDUvoqDou8= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=hSeeqSOSJxueuZi0FGSgRlOXB5CUoQ1WnO/yaBCeAH09SElvWdDxRfUrhi5dg+67vz EPwslYM1PK+dp+enTPKCBnBkRwSZvVQjCK6XSar4bfWVdWK7cHqkicrN+xe34N4SElmE L0pdvnmfBRF/Q4KsZJYjReXWBsRZqt+D9lJLk= Received: by 10.86.6.15 with SMTP id 15mr2655827fgf.42.1269698730829; Sat, 27 Mar 2010 07:05:30 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id d4sm3646922fga.0.2010.03.27.07.05.28 (version=SSLv3 cipher=RC4-MD5); Sat, 27 Mar 2010 07:05:30 -0700 (PDT) Message-ID: <4BAE10BC.7090401@gmail.com> Date: Sat, 27 Mar 2010 17:05:48 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Kaz Kobara References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> In-Reply-To: <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 14:05:12 -0000 Hi Kaz, the deployment experience has been that between gateways, people abuse PSK authentication by using it with short passwords. Even though in principle they could do better. Thanks, Yaron On 26.3.2010 19:53, Kaz Kobara wrote: > Hi Yaron > > Thank you for your clarification. > >> "between gateways" as opposed to >> "between clients and gateways". So your assertion is correct. > > (Between gateways, administrators can set long secrets, so the necessity of > PAKE seems smaller than between clients and gateways where passwords are > recorded in the gateways and users have to type the passwords.) > > Anyway, if the scope is limited only on "between gateways" but not "between > clients and gateways," the title > "Password-Based Authentication in IKEv2: Selection Criteria and Comparison" > seems misleading (since this itself misinforms that this criteria may be > applied to IKEv2 in any cases), and the above should be clearly mentioned in > the document. > > Kaz > >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Friday, March 26, 2010 2:14 PM >> To: Kaz Kobara >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) >> >> Hi Kaz, >> >> I *thought* my intention was clear: "between gateways" as opposed to >> "between clients and gateways". So your assertion is correct. >> >> Thanks, >> Yaron >> >> On 26.3.2010 1:40, Kaz Kobara wrote: >>> Hi Yaron >>> >>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>> "This document is limited to the use of password-based authentication >> to >>>> achieve trust between gateways" >>> >>> I would like to make sure that >>> "gateway" in this document does not encompass VPN clients and hosts, > right? >>> >>> Kaz >>> >>>> -----Original Message----- >>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of >>>> Yaron Sheffer >>>> Sent: Friday, March 26, 2010 3:31 AM >>>> To: SeongHan Shin >>>> Cc: IPsecme WG; Kazukuni Kobara >>>> Subject: Re: [IPsec] New PAKE Criteria draft posted >>>> >>>> Hi Shin, >>>> >>>> Yes. For the typical remote access VPN, EAP is typically more useful. >>>> Note that there is still need for strong password-based mutual >>>> authentication EAP methods - but their home is the EMU working group. >>>> >>>> In addition, the IPsecME has another charter item designed to fit such >>>> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >>>> >>>> Please see again the group's charter, >>>> http://tools.ietf.org/wg/ipsecme/charters. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 25.3.2010 20:07, SeongHan Shin wrote: >>>>> Dear Yaron Sheffer, >>>>> >>>>> I have one question about the draft. >>>>> >>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>> "This document is limited to the use of password-based authentication >>>> to >>>>> achieve trust between gateways" >>>>> >>>>> Is this a consensus of this WG? >>>>> >>>>> Best regards, >>>>> Shin >>>>> >>>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer>>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> after the good discussion in Anaheim, and with the help of > comments >>>>> received on and off the list, I have updated the PAKE Criteria >> draft >>>>> and posted it as >>>>> >>>> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >>>>> >>>>> I have added a number of criteria, clarified others, and added >>>>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >>>>> >>>>> Thanks, >>>>> Yaron >>>>> _______________________________________________ >>>>> IPsec mailing list >>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------------ >>>>> SeongHan Shin >>>>> Research Center for Information Security (RCIS), >>>>> National Institute of Advanced Industrial Science and Technology >> (AIST), >>>>> Room no. 1003, Akihabara Daibiru 10F, >>>>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >>>>> Tel : +81-3-5298-2722 >>>>> Fax : +81-3-5298-4522 >>>>> E-mail : seonghan.shin@aist.go.jp >>>>> ------------------------------------------------------------------ >>>> _______________________________________________ >>>> 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 yaronf.ietf@gmail.com Sat Mar 27 07:30:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4D63A6926 for ; Sat, 27 Mar 2010 07:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I7H7TiiTqge for ; Sat, 27 Mar 2010 07:30:28 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id CA7993A67FD for ; Sat, 27 Mar 2010 07:30:18 -0700 (PDT) Received: by fxm5 with SMTP id 5so2675535fxm.29 for ; Sat, 27 Mar 2010 07:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/HflRntruucE6GKL/GZVDYYsReZH5jnK2gQmR8XjMvo=; b=O+ZYJyZ6f3nxkwuaXE4/6aQWxRHtMq1NVfxlbZA0Y/Vmzxjn1BmzinmE1L+VUOa7TR 4z9v3WCbIp+E7/pg5gN2Xp3J9uOYt5ZdpIs/6cu+UUXTZrvh26LHzwQhhCKjRhY7SZW9 ym8Cgrs9KgHAXPEUe23c92RP5C5g4McU2yCP4= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=MDCbmRcqbph5Ig5d5OGinhvUssQv8VljQHkoQx2K3OmjFGP+eefmuK7DuMRJOwmblr F+hznneje6wWDSln9KYDHgaQSkE52PVz8gayZ9tNnJ//LkmMj94lSSbyRezIxOM6KwZs VpED/VB23ePuE4du4Kqq5+RbqYRFYVlZ+ww40= Received: by 10.87.45.33 with SMTP id x33mr6233084fgj.68.1269700242126; Sat, 27 Mar 2010 07:30:42 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id e20sm1749629fga.21.2010.03.27.07.30.39 (version=SSLv3 cipher=RC4-MD5); Sat, 27 Mar 2010 07:30:41 -0700 (PDT) Message-ID: <4BAE16A4.60108@gmail.com> Date: Sat, 27 Mar 2010 17:31:00 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Dan Harkins References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Kaz Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 14:30:29 -0000 Hi Dan, I'm afraid I disagree with you on several counts. See below. Thanks, Yaron On 26.3.2010 20:11, Dan Harkins wrote: > > Telling administrators what they can and cannot do is really not > the function of our standards body. If someone wants to use a > "long secret" or a password to authenticate gateways, hosts, clients, > peers, or implementations (or whatever you want to call the box) it's > none of our business. We shouldn't say, "nope, sorry you can't do that, > this is a client and you should use a stand-alone AAA server because of > the obvious benefits that have eluded you." We cannot tell administrators anything for the simple reason that they're not looking to us for guidance. However we do have some influence over vendors, and we should tell vendors what we think makes sense, i.e. what is the architecturally correct way to use the protocol. More importantly, we should optimize the protocol (only) for the cases that we think are reasonable. So we should care very much about usage scenarios. As a concrete example, password management arguably matters much more to remote access than to gateway-to-gateway scenarios. Should we support it? Depends on the scenario(s) we want to work on. > > We have RFCs on "host requirements" and "router requirements". There > isn't an RFC on "peer requirements" or "client requirements". Those are > terms that started in marketecture powerpoint slides and should not be > used to constrain or neuter our protocols. No. For years we've had specific IPsec work items on remote access, it's nothing new. If a protocol can be specified for the general use case, that's very well. But there will be protocols that are only applicable to some specific use cases, and that's fine, too. > > Dan. > > On Fri, March 26, 2010 9:53 am, Kaz Kobara wrote: >> Hi Yaron >> >> Thank you for your clarification. >> >>> "between gateways" as opposed to >>> "between clients and gateways". So your assertion is correct. >> >> (Between gateways, administrators can set long secrets, so the necessity >> of >> PAKE seems smaller than between clients and gateways where passwords are >> recorded in the gateways and users have to type the passwords.) >> >> Anyway, if the scope is limited only on "between gateways" but not >> "between >> clients and gateways," the title >> "Password-Based Authentication in IKEv2: Selection Criteria and >> Comparison" >> seems misleading (since this itself misinforms that this criteria may be >> applied to IKEv2 in any cases), and the above should be clearly mentioned >> in >> the document. >> >> Kaz >> >>> -----Original Message----- >>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>> Sent: Friday, March 26, 2010 2:14 PM >>> To: Kaz Kobara >>> Cc: ipsec@ietf.org >>> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) >>> >>> Hi Kaz, >>> >>> I *thought* my intention was clear: "between gateways" as opposed to >>> "between clients and gateways". So your assertion is correct. >>> >>> Thanks, >>> Yaron >>> >>> On 26.3.2010 1:40, Kaz Kobara wrote: >>>> Hi Yaron >>>> >>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>> "This document is limited to the use of password-based authentication >>> to >>>>> achieve trust between gateways" >>>> >>>> I would like to make sure that >>>> "gateway" in this document does not encompass VPN clients and hosts, >> right? >>>> >>>> Kaz >>>> >>>>> -----Original Message----- >>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> Behalf >>> Of >>>>> Yaron Sheffer >>>>> Sent: Friday, March 26, 2010 3:31 AM >>>>> To: SeongHan Shin >>>>> Cc: IPsecme WG; Kazukuni Kobara >>>>> Subject: Re: [IPsec] New PAKE Criteria draft posted >>>>> >>>>> Hi Shin, >>>>> >>>>> Yes. For the typical remote access VPN, EAP is typically more useful. >>>>> Note that there is still need for strong password-based mutual >>>>> authentication EAP methods - but their home is the EMU working group. >>>>> >>>>> In addition, the IPsecME has another charter item designed to fit >>> such >>>>> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >>>>> >>>>> Please see again the group's charter, >>>>> http://tools.ietf.org/wg/ipsecme/charters. >>>>> >>>>> Thanks, >>>>> Yaron >>>>> >>>>> On 25.3.2010 20:07, SeongHan Shin wrote: >>>>>> Dear Yaron Sheffer, >>>>>> >>>>>> I have one question about the draft. >>>>>> >>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>>> "This document is limited to the use of password-based >>> authentication >>>>> to >>>>>> achieve trust between gateways" >>>>>> >>>>>> Is this a consensus of this WG? >>>>>> >>>>>> Best regards, >>>>>> Shin >>>>>> >>>>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer>>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> after the good discussion in Anaheim, and with the help of >> comments >>>>>> received on and off the list, I have updated the PAKE Criteria >>> draft >>>>>> and posted it as >>>>>> >>>>> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >>>>>> >>>>>> I have added a number of criteria, clarified others, and added >>>>>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >>>>>> >>>>>> Thanks, >>>>>> Yaron >>>>>> _______________________________________________ >>>>>> IPsec mailing list >>>>>> IPsec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------ >>>>>> SeongHan Shin >>>>>> Research Center for Information Security (RCIS), >>>>>> National Institute of Advanced Industrial Science and Technology >>> (AIST), >>>>>> Room no. 1003, Akihabara Daibiru 10F, >>>>>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >>>>>> Tel : +81-3-5298-2722 >>>>>> Fax : +81-3-5298-4522 >>>>>> E-mail : seonghan.shin@aist.go.jp >>>>>> ------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> 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 >> > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kobara_conf@m.aist.go.jp Sat Mar 27 11:03:55 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACEE3A6A1D for ; Sat, 27 Mar 2010 11:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAowOv+EUoFc for ; Sat, 27 Mar 2010 11:03:53 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id C55353A6A25 for ; Sat, 27 Mar 2010 10:59:44 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o2RI074R024389 for ; Sun, 28 Mar 2010 03:00:07 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=m.aist.go.jp; s=aist; t=1269712808; bh=ZwAx8/HVlwgKSJxrqYjZwfinhLwcXaBCV94qeNvuuhc=; h=From:Date:Message-ID; b=RHvZKtfKlUnUeMUVrgq0FAi2/oa3YCgba6b39rnbXNYuSnkH1U+v4fIclgrSIrJt7 wrE3XcSGrTCytDnZv/mcjegnqO9Fv+GZ5jvw8tgyt1Pqa8VSd7KglU0Cq5ln5XcQP7 HX5y8Rr2NM+UOZkIkZX+iImYf0NOkG0fG2qEQmbQ= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o2RI07Zh026292 for ; Sun, 28 Mar 2010 03:00:07 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id o2RI06EH006890 for ; Sun, 28 Mar 2010 03:00:06 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) From: "Kaz Kobara" To: References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> In-Reply-To: <4BAE10BC.7090401@gmail.com> Date: Sun, 28 Mar 2010 03:00:05 +0900 Message-ID: <001001cacdd7$557f0190$007d04b0$@aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrNtpMmMMIoC/ViRI+gPGrJRa/rwAAIJx9Q Content-Language: ja Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 18:03:55 -0000 > between gateways, people abuse > PSK authentication by using it with short passwords. I agree, but what I wanted to say was this is also true (and even worse) "between clients and gateways". > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Saturday, March 27, 2010 11:06 PM > To: Kaz Kobara > Cc: ipsec@ietf.org > Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) > > Hi Kaz, > > the deployment experience has been that between gateways, people abuse > PSK authentication by using it with short passwords. Even though in > principle they could do better. > > Thanks, > Yaron > > On 26.3.2010 19:53, Kaz Kobara wrote: > > Hi Yaron > > > > Thank you for your clarification. > > > >> "between gateways" as opposed to > >> "between clients and gateways". So your assertion is correct. > > > > (Between gateways, administrators can set long secrets, so the necessity > of > > PAKE seems smaller than between clients and gateways where passwords are > > recorded in the gateways and users have to type the passwords.) > > > > Anyway, if the scope is limited only on "between gateways" but not "between > > clients and gateways," the title > > "Password-Based Authentication in IKEv2: Selection Criteria and > Comparison" > > seems misleading (since this itself misinforms that this criteria may > be > > applied to IKEv2 in any cases), and the above should be clearly mentioned > in > > the document. > > > > Kaz > > > >> -----Original Message----- > >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > >> Sent: Friday, March 26, 2010 2:14 PM > >> To: Kaz Kobara > >> Cc: ipsec@ietf.org > >> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) > >> > >> Hi Kaz, > >> > >> I *thought* my intention was clear: "between gateways" as opposed to > >> "between clients and gateways". So your assertion is correct. > >> > >> Thanks, > >> Yaron > >> > >> On 26.3.2010 1:40, Kaz Kobara wrote: > >>> Hi Yaron > >>> > >>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 > >>>> "This document is limited to the use of password-based authentication > >> to > >>>> achieve trust between gateways" > >>> > >>> I would like to make sure that > >>> "gateway" in this document does not encompass VPN clients and hosts, > > right? > >>> > >>> Kaz > >>> > >>>> -----Original Message----- > >>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >> Of > >>>> Yaron Sheffer > >>>> Sent: Friday, March 26, 2010 3:31 AM > >>>> To: SeongHan Shin > >>>> Cc: IPsecme WG; Kazukuni Kobara > >>>> Subject: Re: [IPsec] New PAKE Criteria draft posted > >>>> > >>>> Hi Shin, > >>>> > >>>> Yes. For the typical remote access VPN, EAP is typically more useful. > >>>> Note that there is still need for strong password-based mutual > >>>> authentication EAP methods - but their home is the EMU working group. > >>>> > >>>> In addition, the IPsecME has another charter item designed to fit such > >>>> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. > >>>> > >>>> Please see again the group's charter, > >>>> http://tools.ietf.org/wg/ipsecme/charters. > >>>> > >>>> Thanks, > >>>> Yaron > >>>> > >>>> On 25.3.2010 20:07, SeongHan Shin wrote: > >>>>> Dear Yaron Sheffer, > >>>>> > >>>>> I have one question about the draft. > >>>>> > >>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 > >>>>> "This document is limited to the use of password-based authentication > >>>> to > >>>>> achieve trust between gateways" > >>>>> > >>>>> Is this a consensus of this WG? > >>>>> > >>>>> Best regards, > >>>>> Shin > >>>>> > >>>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron Sheffer >>>>> > wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> after the good discussion in Anaheim, and with the help of > > comments > >>>>> received on and off the list, I have updated the PAKE Criteria > >> draft > >>>>> and posted it as > >>>>> > >>>> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. > >>>>> > >>>>> I have added a number of criteria, clarified others, and added > >>>>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). > >>>>> > >>>>> Thanks, > >>>>> Yaron > >>>>> _______________________________________________ > >>>>> IPsec mailing list > >>>>> IPsec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ipsec > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > ------------------------------------------------------------------ > >>>>> SeongHan Shin > >>>>> Research Center for Information Security (RCIS), > >>>>> National Institute of Advanced Industrial Science and Technology > >> (AIST), > >>>>> Room no. 1003, Akihabara Daibiru 10F, > >>>>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan > >>>>> Tel : +81-3-5298-2722 > >>>>> Fax : +81-3-5298-4522 > >>>>> E-mail : seonghan.shin@aist.go.jp > >>>>> > ------------------------------------------------------------------ > >>>> _______________________________________________ > >>>> 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 dharkins@lounge.org Sat Mar 27 12:15:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB3E3A6827 for ; Sat, 27 Mar 2010 12:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.759 X-Spam-Level: X-Spam-Status: No, score=-4.759 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkbO3PI0Rrw4 for ; Sat, 27 Mar 2010 12:15:20 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 950A33A689A for ; Sat, 27 Mar 2010 12:15:17 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6477B1022404A; Sat, 27 Mar 2010 12:15:42 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 27 Mar 2010 12:15:42 -0700 (PDT) Message-ID: In-Reply-To: <4BAE16A4.60108@gmail.com> References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE16A4.60108@gmail.com> Date: Sat, 27 Mar 2010 12:15: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: ipsec@ietf.org, Dan Harkins , Kaz Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 19:15:22 -0000 Hi Yaron, You say below, "If a protocol can be specified for the general use case, that's very well. But there will be protocols that are only applicable to some specific use cases, and that's fine, too." But then the criteria document says, "This document is limited to the use of password-based authentication to achieve trust between gateways." So basically the criteria document is specifying it for a particular use only when there is no protocol issue that would prevent it from being used in the general case. It should be "very well" if it worked "for the general use case" but the criteria draft is preventing it from doing so. In RFC 2409 it was not possible to do the "remote access" thing with a PSK because protocol limitations forced the PSK to be bound to one IP address. That's an example of a protocol limiting usage. But I don't see that now. What could possibly limit what we're talking about _right now_ to some narrow uses? Maybe when we get around to designing the protocol we'll run into something, and as you say "that's fine". But now, there is nothing to limit us and no reason to, a priori, say something is for "gateways" only. Of course, I could be wrong. So maybe you could explain why there is some protocol issue that prevents using password-based authentication in the general case. Dan. On Sat, March 27, 2010 7:31 am, Yaron Sheffer wrote: > Hi Dan, > > I'm afraid I disagree with you on several counts. See below. > > Thanks, > Yaron > > On 26.3.2010 20:11, Dan Harkins wrote: >> >> Telling administrators what they can and cannot do is really not >> the function of our standards body. If someone wants to use a >> "long secret" or a password to authenticate gateways, hosts, clients, >> peers, or implementations (or whatever you want to call the box) it's >> none of our business. We shouldn't say, "nope, sorry you can't do that, >> this is a client and you should use a stand-alone AAA server because of >> the obvious benefits that have eluded you." > > We cannot tell administrators anything for the simple reason that > they're not looking to us for guidance. However we do have some > influence over vendors, and we should tell vendors what we think makes > sense, i.e. what is the architecturally correct way to use the protocol. > > More importantly, we should optimize the protocol (only) for the cases > that we think are reasonable. So we should care very much about usage > scenarios. As a concrete example, password management arguably matters > much more to remote access than to gateway-to-gateway scenarios. Should > we support it? Depends on the scenario(s) we want to work on. >> >> We have RFCs on "host requirements" and "router requirements". There >> isn't an RFC on "peer requirements" or "client requirements". Those are >> terms that started in marketecture powerpoint slides and should not be >> used to constrain or neuter our protocols. > No. For years we've had specific IPsec work items on remote access, it's > nothing new. If a protocol can be specified for the general use case, > that's very well. But there will be protocols that are only applicable > to some specific use cases, and that's fine, too. >> >> Dan. >> >> On Fri, March 26, 2010 9:53 am, Kaz Kobara wrote: >>> Hi Yaron >>> >>> Thank you for your clarification. >>> >>>> "between gateways" as opposed to >>>> "between clients and gateways". So your assertion is correct. >>> >>> (Between gateways, administrators can set long secrets, so the >>> necessity >>> of >>> PAKE seems smaller than between clients and gateways where passwords >>> are >>> recorded in the gateways and users have to type the passwords.) >>> >>> Anyway, if the scope is limited only on "between gateways" but not >>> "between >>> clients and gateways," the title >>> "Password-Based Authentication in IKEv2: Selection Criteria and >>> Comparison" >>> seems misleading (since this itself misinforms that this criteria may >>> be >>> applied to IKEv2 in any cases), and the above should be clearly >>> mentioned >>> in >>> the document. >>> >>> Kaz >>> >>>> -----Original Message----- >>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>>> Sent: Friday, March 26, 2010 2:14 PM >>>> To: Kaz Kobara >>>> Cc: ipsec@ietf.org >>>> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) >>>> >>>> Hi Kaz, >>>> >>>> I *thought* my intention was clear: "between gateways" as opposed to >>>> "between clients and gateways". So your assertion is correct. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 26.3.2010 1:40, Kaz Kobara wrote: >>>>> Hi Yaron >>>>> >>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>>> "This document is limited to the use of password-based >>>>>> authentication >>>> to >>>>>> achieve trust between gateways" >>>>> >>>>> I would like to make sure that >>>>> "gateway" in this document does not encompass VPN clients and hosts, >>> right? >>>>> >>>>> Kaz >>>>> >>>>>> -----Original Message----- >>>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>>> Behalf >>>> Of >>>>>> Yaron Sheffer >>>>>> Sent: Friday, March 26, 2010 3:31 AM >>>>>> To: SeongHan Shin >>>>>> Cc: IPsecme WG; Kazukuni Kobara >>>>>> Subject: Re: [IPsec] New PAKE Criteria draft posted >>>>>> >>>>>> Hi Shin, >>>>>> >>>>>> Yes. For the typical remote access VPN, EAP is typically more >>>>>> useful. >>>>>> Note that there is still need for strong password-based mutual >>>>>> authentication EAP methods - but their home is the EMU working >>>>>> group. >>>>>> >>>>>> In addition, the IPsecME has another charter item designed to fit >>>> such >>>>>> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >>>>>> >>>>>> Please see again the group's charter, >>>>>> http://tools.ietf.org/wg/ipsecme/charters. >>>>>> >>>>>> Thanks, >>>>>> Yaron >>>>>> >>>>>> On 25.3.2010 20:07, SeongHan Shin wrote: >>>>>>> Dear Yaron Sheffer, >>>>>>> >>>>>>> I have one question about the draft. >>>>>>> >>>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>>>> "This document is limited to the use of password-based >>>> authentication >>>>>> to >>>>>>> achieve trust between gateways" >>>>>>> >>>>>>> Is this a consensus of this WG? >>>>>>> >>>>>>> Best regards, >>>>>>> Shin >>>>>>> >>>>>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron >>>>>>> Sheffer>>>>>> > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> after the good discussion in Anaheim, and with the help of >>> comments >>>>>>> received on and off the list, I have updated the PAKE >>>>>>> Criteria >>>> draft >>>>>>> and posted it as >>>>>>> >>>>>> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >>>>>>> >>>>>>> I have added a number of criteria, clarified others, and >>>>>>> added >>>>>>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >>>>>>> >>>>>>> Thanks, >>>>>>> Yaron >>>>>>> _______________________________________________ >>>>>>> IPsec mailing list >>>>>>> IPsec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------------------------------------------------ >>>>>>> SeongHan Shin >>>>>>> Research Center for Information Security (RCIS), >>>>>>> National Institute of Advanced Industrial Science and Technology >>>> (AIST), >>>>>>> Room no. 1003, Akihabara Daibiru 10F, >>>>>>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >>>>>>> Tel : +81-3-5298-2722 >>>>>>> Fax : +81-3-5298-4522 >>>>>>> E-mail : seonghan.shin@aist.go.jp >>>>>>> ------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> 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 >>> >> >> >> _______________________________________________ >> 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 k-kobara@aist.go.jp Fri Mar 26 15:26:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713553A686D for ; Fri, 26 Mar 2010 15:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxoRdnzK50zI for ; Fri, 26 Mar 2010 15:26:57 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id C81BC3A67D6 for ; Fri, 26 Mar 2010 15:26:55 -0700 (PDT) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id o2QMPfp0017128; Sat, 27 Mar 2010 07:25:41 +0900 (JST) env-from (k-kobara@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1269642341; bh=vwwJRfsunJQZVN+3DQNfpOzYx43UyKshxCLxCUDzpaQ=; h=From:Date:Message-ID; b=fXQyIIYrAHeQdqgCsCpjC39hm7aF0mAN43R3Da4F2De45ESZbAQedisytViHLNV1M NN0sAi9ehV1VQydAT20cnUGSXI3g3oKVNnzClVqkEeucTGz8OwIRHnB0d1KVpHyPBZ edOjs9qTep3qa/giyzRZ0spSQn1N9nIWW+aOevbo= Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id o2QMPeBq024647; Sat, 27 Mar 2010 07:25:41 +0900 (JST) env-from (k-kobara@aist.go.jp) Received: by smtp2.aist.go.jp with ESMTP id o2QMPbrf021678; Sat, 27 Mar 2010 07:25:38 +0900 (JST) env-from (k-kobara@aist.go.jp) From: "Kaz Kobara" To: , , References: <1269638701.2838.303.camel@faith.austin.ibm.com> In-Reply-To: <1269638701.2838.303.camel@faith.austin.ibm.com> Date: Sat, 27 Mar 2010 07:25:41 +0900 Message-ID: <019701cacd33$46d4fc70$d47ef550$@go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrNLd2v1FtQCtn+Toyd9NY0qei8ZgAAiiWg Content-Language: ja X-Mailman-Approved-At: Sat, 27 Mar 2010 13:35:11 -0700 Cc: ipsec@ietf.org, avagarwa@redhat.com Subject: Re: [IPsec] Question about RFC 5114 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 22:26:58 -0000 Hi Joy When one uses a subgroup like defined in RFC 5114, q (and (p-1)/2q ) = must be chosen carefully. Precisely: 1. q must be a prime number of 2k or more bits where k is a security = parameter. 2. q must be a divisor of ((p - 1) / 2). 3. Every factors of (p - 1) / (2q) must also be primes comparable to or = greater than q in size. =20 p corresponding such q is called a "secure prime." X is simply to shift the range of 0 to q-2 to 1 to q-1 to exclude 0 = (since g^0 mod p =3D 1). Kaz > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of > Joy Latten > Sent: Saturday, March 27, 2010 6:25 AM > To: mlepinski@bbn.com; kent@bbn.com > Cc: ipsec@ietf.org; avagarwa@redhat.com > Subject: [IPsec] Question about RFC 5114 >=20 > Hi, >=20 > I am looking to implement modp groups 22, 23, and 24 into IKE but have = a > question. >=20 > RFC 5114 gives the prime, p, the generator, g and a subgroup, q, with = a > specific size... >=20 > Because prior rfcs for modp groups did not specify a "q", I was not = sure > if this was a new constant or just stating a size requirement? > So I took a look at NIST 800-56A. In particular, >=20 > 5.6.1 Private/Public Key Pair Generation >=20 > 5.6.1.1 FFC Key Pair Generation > For the FFC schemes, each static and ephemeral private key and public > key shall be generated using an Approved method and the selected valid > domain parameters (p, q, g{, SEED,pgenCounter}) (see Appendix B of = FIPS > 186-3). > ... >=20 > I then took a look at FIPS 186-3, Appendix B, which documents 2 = methods > for finite field cryptography (FFC) key pair generation. > For example, one method is "Key Pair Generation Using Extra Random > Bits". It actually states that "q" is an input and it is used to do an > additional computation to compute "x". >=20 > I am somewhat confused, are the modp groups 22, 23 & 24 suppose to use > one of these new methods and that is why "q" is given in rfc 5114? > Or am I to ignore this and just continue with existing way > where "q" is not used and there aren't any additional computations > to compute x. >=20 > I am not even sure this is correct place to ask, but any advice > would be welcome. >=20 > regards, > Joy >=20 >=20 > (Cut-n-paste from FIPs 186-3 below to show input and process) >=20 > Input: > (p, q, g) The subset of the domain parameters that are used > for this process. p, q and g shall either be > provided as integers during input, or shall be > converted to integers prior to use. >=20 > Process: > 1. N =3D len(q); L =3D len(p). Comment: Check that the (L, N) pair > is specified in Section 4.2. > 2. If the (L, N) pair is invalid, then return an ERROR indicator, > Invalid_x, and Invalid_y. > 3. requested_security_strength =3D the security strength associated > with the (L, N) pair; see SP 800-57. > 4. Obtain a string of N+64 returned_bits from an RBG with a security > strength of requested_security_strength or more. If an ERROR > indication is returned, then return an ERROR indication, > Invalid_x, and Invalid_y. > 5. Convert returned_bits to the (non-negative) integer c (see > Appendix C.2.1). > 6. x =3D (c mod (q=E2=80=931)) + 1. Comment: 0 =E2=89=A4 c mod = (q=E2=80=931) =E2=89=A4 q=E2=80=932 and > implies that 1 =E2=89=A4 x =E2=89=A4 = q=E2=80=931. > 7. y =3D gx mod p. > 8. Return SUCCESS, x, and y. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From dharkins@lounge.org Sat Mar 27 13:45:48 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23AF83A69D6 for ; Sat, 27 Mar 2010 13:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.806 X-Spam-Level: X-Spam-Status: No, score=-4.806 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwJmY4LfiF0O for ; Sat, 27 Mar 2010 13:45:47 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 788013A68F6 for ; Sat, 27 Mar 2010 13:45:47 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 12D741022404A; Sat, 27 Mar 2010 13:46:12 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 27 Mar 2010 13:46:12 -0700 (PDT) Message-ID: <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> In-Reply-To: <001001cacdd7$557f0190$007d04b0$@aist.go.jp> References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> Date: Sat, 27 Mar 2010 13:46:12 -0700 (PDT) From: "Dan Harkins" To: "Kaz Kobara" 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 Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 20:45:48 -0000 Kaz, On Sat, March 27, 2010 11:00 am, Kaz Kobara wrote: >> between gateways, people abuse >> PSK authentication by using it with short passwords. > > I agree, but what I wanted to say was > this is also true (and even worse) "between clients and gateways". So is there a reason you don't want to fix this "between clients and gateways"? Dan. From yaronf.ietf@gmail.com Sat Mar 27 13:53:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239E43A69B8 for ; Sat, 27 Mar 2010 13:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApLqwESlqVRO for ; Sat, 27 Mar 2010 13:53:04 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 283353A63C9 for ; Sat, 27 Mar 2010 13:53:03 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so434664fgb.13 for ; Sat, 27 Mar 2010 13:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=VkZ4cNHJQqrImYIT+TexN5c8taoXDGvVwq8Fyy8LpY0=; b=C3AdyGFGUYlGlu2+wdf5vSAL5cbhhUV6U7jua25Ivzl/CzZSbC1nCqIvcFrCHeIcch QFyZhQ5cCChDptWwZ0gd4P1Dam9kilpCOJ7xMJqRN9NY/LMt4h/9AjpVhqBXoxj5hat9 ar5uXdtWEd64MZPQQSq35I345t/NmalP5ta4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=TVse49fRtBDidqAp2pvtyZByVHQTqOShwNNq8FA45uqd9Ct7yRcDoTvRbFitpZQbP5 j0SdKb3ovN2Ub8tvfCKvmQ//Wyfr/7BpAq/KRpeg1syi0+L9/hxE3bREm0OJLMieMNLP 2Ca/Jc34PiSTPJ3LNRALo5nDUjV/eTDlsw5uQ= Received: by 10.87.15.14 with SMTP id s14mr6886394fgi.8.1269723204534; Sat, 27 Mar 2010 13:53:24 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id d6sm2135633fga.18.2010.03.27.13.53.23 (version=SSLv3 cipher=RC4-MD5); Sat, 27 Mar 2010 13:53:24 -0700 (PDT) Message-ID: <4BAE7057.9050403@gmail.com> Date: Sat, 27 Mar 2010 23:53:43 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Dan Harkins References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> In-Reply-To: <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Kaz Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 20:53:05 -0000 Actually I do want to fix it. All you have to do is use IKEv2 with one of the shining new EAP methods. Such as http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-13. Thanks, Yaron On 27.3.2010 23:46, Dan Harkins wrote: > > Kaz, > > On Sat, March 27, 2010 11:00 am, Kaz Kobara wrote: >>> between gateways, people abuse >>> PSK authentication by using it with short passwords. >> >> I agree, but what I wanted to say was >> this is also true (and even worse) "between clients and gateways". > > So is there a reason you don't want to fix this "between clients > and gateways"? > > Dan. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Sat Mar 27 14:20:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D761A3A6802 for ; Sat, 27 Mar 2010 14:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1HHhslMMHlM for ; Sat, 27 Mar 2010 14:20:22 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id E6D9D3A67E3 for ; Sat, 27 Mar 2010 14:20:20 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so438437fgb.13 for ; Sat, 27 Mar 2010 14:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=493tTVL1F05Z65d0nF6X04irEClpFodKq96SOh5rmgk=; b=bj2zfpyi5TScwx/PPROucB/ikkr6ji/kcF9fmKu3VdwDKx9EEemIQvHY0L7PiZkQvF J6tUxdd0Q06wYInv/nh3UNw+pxf53yvCGUUCQHy4T2+cMe3RgKPPjAP/v3+1P9pUs8IJ s8tgIFf+8CiNDYca0WBKuU8wK//s5IDNBIl10= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=HN5EUhb9kKhAcNcYii+6IwQHqLxlgvTUVpVgNSpS4EL4IT8DBQZzlXUmvETkWb1uqh nHaM32ubnAV5lDqbB1BTRSy9qxCdQ1XcFV4ogX3ucle+V9bkYVSlNa9RVSwyHffWrTck j/BH9r7ZQjQsadDL4sp9PMNlw5vkw+K8f8oDQ= Received: by 10.87.55.11 with SMTP id h11mr1942406fgk.56.1269724842742; Sat, 27 Mar 2010 14:20:42 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id l12sm3070878fgb.17.2010.03.27.14.20.40 (version=SSLv3 cipher=RC4-MD5); Sat, 27 Mar 2010 14:20:42 -0700 (PDT) Message-ID: <4BAE76BC.9060508@gmail.com> Date: Sun, 28 Mar 2010 00:21:00 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Dan Harkins References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE16A4.60108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Kaz Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 21:20:25 -0000 Hi Dan, Again, the criteria document is just following the charter in mentioning this constraint. The protocol we end up with might have all sorts of nice-to-have features and behaviors. But for the criteria, we have to focus on what's important. Use cases that were excluded in the charter (and for good reason, because we have a perfectly good solution for them today) do not fall into this category. Thanks, Yaron On 27.3.2010 22:15, Dan Harkins wrote: > > Hi Yaron, > > You say below, "If a protocol can be specified for the general use case, > that's very well. But there will be protocols that are only applicable > to some specific use cases, and that's fine, too." But then the criteria > document says, "This document is limited to the use of password-based > authentication to achieve trust between gateways." > > So basically the criteria document is specifying it for a particular > use only when there is no protocol issue that would prevent it from being > used in the general case. It should be "very well" if it worked "for the > general use case" but the criteria draft is preventing it from doing so. > > In RFC 2409 it was not possible to do the "remote access" thing with a > PSK because protocol limitations forced the PSK to be bound to one IP > address. That's an example of a protocol limiting usage. But I don't see > that now. What could possibly limit what we're talking about _right now_ > to some narrow uses? Maybe when we get around to designing the protocol > we'll run into something, and as you say "that's fine". But now, there is > nothing to limit us and no reason to, a priori, say something is for > "gateways" only. > > Of course, I could be wrong. So maybe you could explain why there is > some protocol issue that prevents using password-based authentication in > the general case. > > Dan. > > On Sat, March 27, 2010 7:31 am, Yaron Sheffer wrote: >> Hi Dan, >> >> I'm afraid I disagree with you on several counts. See below. >> >> Thanks, >> Yaron >> >> On 26.3.2010 20:11, Dan Harkins wrote: >>> >>> Telling administrators what they can and cannot do is really not >>> the function of our standards body. If someone wants to use a >>> "long secret" or a password to authenticate gateways, hosts, clients, >>> peers, or implementations (or whatever you want to call the box) it's >>> none of our business. We shouldn't say, "nope, sorry you can't do that, >>> this is a client and you should use a stand-alone AAA server because of >>> the obvious benefits that have eluded you." >> >> We cannot tell administrators anything for the simple reason that >> they're not looking to us for guidance. However we do have some >> influence over vendors, and we should tell vendors what we think makes >> sense, i.e. what is the architecturally correct way to use the protocol. >> >> More importantly, we should optimize the protocol (only) for the cases >> that we think are reasonable. So we should care very much about usage >> scenarios. As a concrete example, password management arguably matters >> much more to remote access than to gateway-to-gateway scenarios. Should >> we support it? Depends on the scenario(s) we want to work on. >>> >>> We have RFCs on "host requirements" and "router requirements". There >>> isn't an RFC on "peer requirements" or "client requirements". Those are >>> terms that started in marketecture powerpoint slides and should not be >>> used to constrain or neuter our protocols. >> No. For years we've had specific IPsec work items on remote access, it's >> nothing new. If a protocol can be specified for the general use case, >> that's very well. But there will be protocols that are only applicable >> to some specific use cases, and that's fine, too. >>> >>> Dan. >>> >>> On Fri, March 26, 2010 9:53 am, Kaz Kobara wrote: >>>> Hi Yaron >>>> >>>> Thank you for your clarification. >>>> >>>>> "between gateways" as opposed to >>>>> "between clients and gateways". So your assertion is correct. >>>> >>>> (Between gateways, administrators can set long secrets, so the >>>> necessity >>>> of >>>> PAKE seems smaller than between clients and gateways where passwords >>>> are >>>> recorded in the gateways and users have to type the passwords.) >>>> >>>> Anyway, if the scope is limited only on "between gateways" but not >>>> "between >>>> clients and gateways," the title >>>> "Password-Based Authentication in IKEv2: Selection Criteria and >>>> Comparison" >>>> seems misleading (since this itself misinforms that this criteria may >>>> be >>>> applied to IKEv2 in any cases), and the above should be clearly >>>> mentioned >>>> in >>>> the document. >>>> >>>> Kaz >>>> >>>>> -----Original Message----- >>>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>>>> Sent: Friday, March 26, 2010 2:14 PM >>>>> To: Kaz Kobara >>>>> Cc: ipsec@ietf.org >>>>> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) >>>>> >>>>> Hi Kaz, >>>>> >>>>> I *thought* my intention was clear: "between gateways" as opposed to >>>>> "between clients and gateways". So your assertion is correct. >>>>> >>>>> Thanks, >>>>> Yaron >>>>> >>>>> On 26.3.2010 1:40, Kaz Kobara wrote: >>>>>> Hi Yaron >>>>>> >>>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>>>> "This document is limited to the use of password-based >>>>>>> authentication >>>>> to >>>>>>> achieve trust between gateways" >>>>>> >>>>>> I would like to make sure that >>>>>> "gateway" in this document does not encompass VPN clients and hosts, >>>> right? >>>>>> >>>>>> Kaz >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>>>> Behalf >>>>> Of >>>>>>> Yaron Sheffer >>>>>>> Sent: Friday, March 26, 2010 3:31 AM >>>>>>> To: SeongHan Shin >>>>>>> Cc: IPsecme WG; Kazukuni Kobara >>>>>>> Subject: Re: [IPsec] New PAKE Criteria draft posted >>>>>>> >>>>>>> Hi Shin, >>>>>>> >>>>>>> Yes. For the typical remote access VPN, EAP is typically more >>>>>>> useful. >>>>>>> Note that there is still need for strong password-based mutual >>>>>>> authentication EAP methods - but their home is the EMU working >>>>>>> group. >>>>>>> >>>>>>> In addition, the IPsecME has another charter item designed to fit >>>>> such >>>>>>> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >>>>>>> >>>>>>> Please see again the group's charter, >>>>>>> http://tools.ietf.org/wg/ipsecme/charters. >>>>>>> >>>>>>> Thanks, >>>>>>> Yaron >>>>>>> >>>>>>> On 25.3.2010 20:07, SeongHan Shin wrote: >>>>>>>> Dear Yaron Sheffer, >>>>>>>> >>>>>>>> I have one question about the draft. >>>>>>>> >>>>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>>>>> "This document is limited to the use of password-based >>>>> authentication >>>>>>> to >>>>>>>> achieve trust between gateways" >>>>>>>> >>>>>>>> Is this a consensus of this WG? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Shin >>>>>>>> >>>>>>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron >>>>>>>> Sheffer>>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> after the good discussion in Anaheim, and with the help of >>>> comments >>>>>>>> received on and off the list, I have updated the PAKE >>>>>>>> Criteria >>>>> draft >>>>>>>> and posted it as >>>>>>>> >>>>>>> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >>>>>>>> >>>>>>>> I have added a number of criteria, clarified others, and >>>>>>>> added >>>>>>>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Yaron >>>>>>>> _______________________________________________ >>>>>>>> IPsec mailing list >>>>>>>> IPsec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ------------------------------------------------------------------ >>>>>>>> SeongHan Shin >>>>>>>> Research Center for Information Security (RCIS), >>>>>>>> National Institute of Advanced Industrial Science and Technology >>>>> (AIST), >>>>>>>> Room no. 1003, Akihabara Daibiru 10F, >>>>>>>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >>>>>>>> Tel : +81-3-5298-2722 >>>>>>>> Fax : +81-3-5298-4522 >>>>>>>> E-mail : seonghan.shin@aist.go.jp >>>>>>>> ------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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 paul.hoffman@vpnc.org Sat Mar 27 15:07:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5343A6895 for ; Sat, 27 Mar 2010 15:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yjK-T6Y9cjD for ; Sat, 27 Mar 2010 15:07:57 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 71B113A69D6 for ; Sat, 27 Mar 2010 15:07:57 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2RM8KRa093249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 27 Mar 2010 15:08:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sat, 27 Mar 2010 14:49:07 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] National Institute of Advanced Industrial Science and Technology (AIST)'s Statement about IPR related to draft-shin-augmented-pake-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 22:07:58 -0000 Of interesting to this WG: --Paul Hoffman, Director --VPN Consortium From dharkins@lounge.org Sat Mar 27 17:39:07 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E973A69FF for ; Sat, 27 Mar 2010 17:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.843 X-Spam-Level: X-Spam-Status: No, score=-4.843 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-vFUpo+htDh for ; Sat, 27 Mar 2010 17:39:05 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 087B33A69B0 for ; Sat, 27 Mar 2010 17:39:05 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9131A1022404A; Sat, 27 Mar 2010 17:39:30 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 27 Mar 2010 17:39:30 -0700 (PDT) Message-ID: <3dd80c2646eeb2ddf00ce35d10a47a9a.squirrel@www.trepanning.net> In-Reply-To: <4BAE76BC.9060508@gmail.com> References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE16A4.60108@gmail.com> <4BAE76BC.9060508@gmail.com> Date: Sat, 27 Mar 2010 17:39:30 -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: ipsec@ietf.org, Dan Harkins , Kaz Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 00:39:07 -0000 Hi Yaron, Since you did not respond to my question, I guess I can infer then that there is no protocol issue _right now_ that would prevent some password authentication scheme from being used with a "client" and a "gateway". That being the case, the criteria document should not constrain any possible solution. The charter mentions these use cases because you have to justify _why_ you want to change the charter, what problem are you solving. Those use cases were used to illustrate a problem to solve and justify why the charter had to be changed. Just because you happen to solve problem A with some protocol does not mean that the protocol must be prevented from also solving problem B. If you want to use EAP then knock yourself out. If you're happy with pointless encapsulation and more state machines and code you have to implement then please have at it. But don't make a different protocol hamstrung just because it might be used instead of EAP. There is no TECHNICAL reason to prevent a password authentication scheme in IKE(v2) from being used between a "client" and a "gateway". Since we're a working group that deals with technical issues we can therefore safely dispense with any artificial constraints on our protocols. Dan. On Sat, March 27, 2010 2:21 pm, Yaron Sheffer wrote: > Hi Dan, > > Again, the criteria document is just following the charter in mentioning > this constraint. > > The protocol we end up with might have all sorts of nice-to-have > features and behaviors. But for the criteria, we have to focus on what's > important. Use cases that were excluded in the charter (and for good > reason, because we have a perfectly good solution for them today) do not > fall into this category. > > Thanks, > Yaron > > On 27.3.2010 22:15, Dan Harkins wrote: >> >> Hi Yaron, >> >> You say below, "If a protocol can be specified for the general use >> case, >> that's very well. But there will be protocols that are only applicable >> to some specific use cases, and that's fine, too." But then the criteria >> document says, "This document is limited to the use of password-based >> authentication to achieve trust between gateways." >> >> So basically the criteria document is specifying it for a particular >> use only when there is no protocol issue that would prevent it from >> being >> used in the general case. It should be "very well" if it worked "for the >> general use case" but the criteria draft is preventing it from doing so. >> >> In RFC 2409 it was not possible to do the "remote access" thing with >> a >> PSK because protocol limitations forced the PSK to be bound to one IP >> address. That's an example of a protocol limiting usage. But I don't see >> that now. What could possibly limit what we're talking about _right now_ >> to some narrow uses? Maybe when we get around to designing the protocol >> we'll run into something, and as you say "that's fine". But now, there >> is >> nothing to limit us and no reason to, a priori, say something is for >> "gateways" only. >> >> Of course, I could be wrong. So maybe you could explain why there is >> some protocol issue that prevents using password-based authentication in >> the general case. >> >> Dan. >> >> On Sat, March 27, 2010 7:31 am, Yaron Sheffer wrote: >>> Hi Dan, >>> >>> I'm afraid I disagree with you on several counts. See below. >>> >>> Thanks, >>> Yaron >>> >>> On 26.3.2010 20:11, Dan Harkins wrote: >>>> >>>> Telling administrators what they can and cannot do is really not >>>> the function of our standards body. If someone wants to use a >>>> "long secret" or a password to authenticate gateways, hosts, clients, >>>> peers, or implementations (or whatever you want to call the box) it's >>>> none of our business. We shouldn't say, "nope, sorry you can't do >>>> that, >>>> this is a client and you should use a stand-alone AAA server because >>>> of >>>> the obvious benefits that have eluded you." >>> >>> We cannot tell administrators anything for the simple reason that >>> they're not looking to us for guidance. However we do have some >>> influence over vendors, and we should tell vendors what we think makes >>> sense, i.e. what is the architecturally correct way to use the >>> protocol. >>> >>> More importantly, we should optimize the protocol (only) for the cases >>> that we think are reasonable. So we should care very much about usage >>> scenarios. As a concrete example, password management arguably matters >>> much more to remote access than to gateway-to-gateway scenarios. Should >>> we support it? Depends on the scenario(s) we want to work on. >>>> >>>> We have RFCs on "host requirements" and "router requirements". >>>> There >>>> isn't an RFC on "peer requirements" or "client requirements". Those >>>> are >>>> terms that started in marketecture powerpoint slides and should not be >>>> used to constrain or neuter our protocols. >>> No. For years we've had specific IPsec work items on remote access, >>> it's >>> nothing new. If a protocol can be specified for the general use case, >>> that's very well. But there will be protocols that are only applicable >>> to some specific use cases, and that's fine, too. >>>> >>>> Dan. >>>> >>>> On Fri, March 26, 2010 9:53 am, Kaz Kobara wrote: >>>>> Hi Yaron >>>>> >>>>> Thank you for your clarification. >>>>> >>>>>> "between gateways" as opposed to >>>>>> "between clients and gateways". So your assertion is correct. >>>>> >>>>> (Between gateways, administrators can set long secrets, so the >>>>> necessity >>>>> of >>>>> PAKE seems smaller than between clients and gateways where passwords >>>>> are >>>>> recorded in the gateways and users have to type the passwords.) >>>>> >>>>> Anyway, if the scope is limited only on "between gateways" but not >>>>> "between >>>>> clients and gateways," the title >>>>> "Password-Based Authentication in IKEv2: Selection Criteria and >>>>> Comparison" >>>>> seems misleading (since this itself misinforms that this criteria may >>>>> be >>>>> applied to IKEv2 in any cases), and the above should be clearly >>>>> mentioned >>>>> in >>>>> the document. >>>>> >>>>> Kaz >>>>> >>>>>> -----Original Message----- >>>>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>>>>> Sent: Friday, March 26, 2010 2:14 PM >>>>>> To: Kaz Kobara >>>>>> Cc: ipsec@ietf.org >>>>>> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of >>>>>> gateway) >>>>>> >>>>>> Hi Kaz, >>>>>> >>>>>> I *thought* my intention was clear: "between gateways" as opposed to >>>>>> "between clients and gateways". So your assertion is correct. >>>>>> >>>>>> Thanks, >>>>>> Yaron >>>>>> >>>>>> On 26.3.2010 1:40, Kaz Kobara wrote: >>>>>>> Hi Yaron >>>>>>> >>>>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>>>>> "This document is limited to the use of password-based >>>>>>>> authentication >>>>>> to >>>>>>>> achieve trust between gateways" >>>>>>> >>>>>>> I would like to make sure that >>>>>>> "gateway" in this document does not encompass VPN clients and >>>>>>> hosts, >>>>> right? >>>>>>> >>>>>>> Kaz >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>>>>> Behalf >>>>>> Of >>>>>>>> Yaron Sheffer >>>>>>>> Sent: Friday, March 26, 2010 3:31 AM >>>>>>>> To: SeongHan Shin >>>>>>>> Cc: IPsecme WG; Kazukuni Kobara >>>>>>>> Subject: Re: [IPsec] New PAKE Criteria draft posted >>>>>>>> >>>>>>>> Hi Shin, >>>>>>>> >>>>>>>> Yes. For the typical remote access VPN, EAP is typically more >>>>>>>> useful. >>>>>>>> Note that there is still need for strong password-based mutual >>>>>>>> authentication EAP methods - but their home is the EMU working >>>>>>>> group. >>>>>>>> >>>>>>>> In addition, the IPsecME has another charter item designed to fit >>>>>> such >>>>>>>> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >>>>>>>> >>>>>>>> Please see again the group's charter, >>>>>>>> http://tools.ietf.org/wg/ipsecme/charters. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Yaron >>>>>>>> >>>>>>>> On 25.3.2010 20:07, SeongHan Shin wrote: >>>>>>>>> Dear Yaron Sheffer, >>>>>>>>> >>>>>>>>> I have one question about the draft. >>>>>>>>> >>>>>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>>>>>> "This document is limited to the use of password-based >>>>>> authentication >>>>>>>> to >>>>>>>>> achieve trust between gateways" >>>>>>>>> >>>>>>>>> Is this a consensus of this WG? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Shin >>>>>>>>> >>>>>>>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron >>>>>>>>> Sheffer>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> after the good discussion in Anaheim, and with the help of >>>>> comments >>>>>>>>> received on and off the list, I have updated the PAKE >>>>>>>>> Criteria >>>>>> draft >>>>>>>>> and posted it as >>>>>>>>> >>>>>>>> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >>>>>>>>> >>>>>>>>> I have added a number of criteria, clarified others, and >>>>>>>>> added >>>>>>>>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Yaron >>>>>>>>> _______________________________________________ >>>>>>>>> IPsec mailing list >>>>>>>>> IPsec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> SeongHan Shin >>>>>>>>> Research Center for Information Security (RCIS), >>>>>>>>> National Institute of Advanced Industrial Science and Technology >>>>>> (AIST), >>>>>>>>> Room no. 1003, Akihabara Daibiru 10F, >>>>>>>>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >>>>>>>>> Tel : +81-3-5298-2722 >>>>>>>>> Fax : +81-3-5298-4522 >>>>>>>>> E-mail : >>>>>>>>> seonghan.shin@aist.go.jp >>>>>>>>> ------------------------------------------------------------------ >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 sfluhrer@cisco.com Sat Mar 27 19:22:46 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334733A6933 for ; Sat, 27 Mar 2010 19:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhPVgUXxKAPX for ; Sat, 27 Mar 2010 19:22:40 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 349663A6A27 for ; Sat, 27 Mar 2010 19:22:40 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGNarkurR7Ht/2dsb2JhbACDGZc8XnOkH4g9j3+BK4JsagSDHg X-IronPort-AV: E=Sophos;i="4.51,320,1267401600"; d="scan'208";a="173418361" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 28 Mar 2010 02:23:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2S2N5C1022723; Sun, 28 Mar 2010 02:23:05 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Mar 2010 19:23:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sat, 27 Mar 2010 19:23:00 -0700 Message-ID: In-Reply-To: <019701cacd33$46d4fc70$d47ef550$@go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Question about RFC 5114 Thread-Index: AcrNLd2v1FtQCtn+Toyd9NY0qei8ZgAAiiWgADqMShA= X-Priority: 5 Priority: Non-Urgent Importance: low References: <1269638701.2838.303.camel@faith.austin.ibm.com> <019701cacd33$46d4fc70$d47ef550$@go.jp> From: "Scott Fluhrer (sfluhrer)" To: "Kaz Kobara" , , , X-OriginalArrivalTime: 28 Mar 2010 02:23:05.0984 (UTC) FILETIME=[9999B000:01CACE1D] Cc: ipsec@ietf.org, avagarwa@redhat.com Subject: Re: [IPsec] Question about RFC 5114 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 02:22:46 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXBzZWMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBL YXogS29iYXJhDQo+IFNlbnQ6IEZyaWRheSwgTWFyY2ggMjYsIDIwMTAgNjoyNiBQTQ0KPiBUbzog bGF0dGVuQGF1c3Rpbi5pYm0uY29tOyBtbGVwaW5za2lAYmJuLmNvbTsga2VudEBiYm4uY29tDQo+ IENjOiBpcHNlY0BpZXRmLm9yZzsgYXZhZ2Fyd2FAcmVkaGF0LmNvbQ0KPiBTdWJqZWN0OiBSZTog W0lQc2VjXSBRdWVzdGlvbiBhYm91dCBSRkMgNTExNA0KPiANCj4gSGkgSm95DQo+IA0KPiBXaGVu IG9uZSB1c2VzIGEgc3ViZ3JvdXAgbGlrZSBkZWZpbmVkIGluIFJGQyA1MTE0LCBxIChhbmQgKHAt MSkvMnEgKQ0KPiBtdXN0IGJlIGNob3NlbiBjYXJlZnVsbHkuDQo+IA0KPiBQcmVjaXNlbHk6DQo+ IDEuIHEgbXVzdCBiZSBhIHByaW1lIG51bWJlciBvZiAyayBvciBtb3JlIGJpdHMgd2hlcmUgayBp cyBhIHNlY3VyaXR5DQo+IHBhcmFtZXRlci4NCj4gMi4gcSBtdXN0IGJlIGEgZGl2aXNvciBvZiAo KHAgLSAxKSAvIDIpLg0KPiAzLiBFdmVyeSBmYWN0b3JzIG9mIChwIC0gMSkgLyAoMnEpIG11c3Qg YWxzbyBiZSBwcmltZXMgY29tcGFyYWJsZSB0byBvcg0KPiBncmVhdGVyIHRoYW4gcSBpbiBzaXpl Lg0KDQpJIG11c3QgcG9pbnQgb3V0IHRoYXQgdGhlIE1PRFAgZ3JvdXBzIGRlZmluZWQgaW4gUkZD IDUxMTQgZG8gbm90IG1lZXQgY3JpdGVyaWEgMy4NCg0KPiANCj4gcCBjb3JyZXNwb25kaW5nIHN1 Y2ggcSBpcyBjYWxsZWQgYSAic2VjdXJlIHByaW1lLiINCj4gDQo+IFggaXMgc2ltcGx5IHRvIHNo aWZ0IHRoZSByYW5nZSBvZiAwIHRvIHEtMiB0byAxIHRvIHEtMSB0byBleGNsdWRlIDANCj4gKHNp bmNlIGdeMCBtb2QgcCA9IDEpLg0KPiANCj4gS2F6DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogaXBzZWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlwc2Vj LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZg0KPiA+IEpveSBMYXR0ZW4NCj4gPiBT ZW50OiBTYXR1cmRheSwgTWFyY2ggMjcsIDIwMTAgNjoyNSBBTQ0KPiA+IFRvOiBtbGVwaW5za2lA YmJuLmNvbTsga2VudEBiYm4uY29tDQo+ID4gQ2M6IGlwc2VjQGlldGYub3JnOyBhdmFnYXJ3YUBy ZWRoYXQuY29tDQo+ID4gU3ViamVjdDogW0lQc2VjXSBRdWVzdGlvbiBhYm91dCBSRkMgNTExNA0K PiA+DQo+ID4gSGksDQo+ID4NCj4gPiBJIGFtIGxvb2tpbmcgdG8gaW1wbGVtZW50IG1vZHAgZ3Jv dXBzIDIyLCAyMywgYW5kIDI0IGludG8gSUtFIGJ1dA0KPiBoYXZlIGENCj4gPiBxdWVzdGlvbi4N Cj4gPg0KPiA+IFJGQyA1MTE0IGdpdmVzIHRoZSBwcmltZSwgcCwgdGhlIGdlbmVyYXRvciwgZyBh bmQgYSBzdWJncm91cCwgcSwgd2l0aA0KPiBhDQo+ID4gc3BlY2lmaWMgc2l6ZS4uLg0KPiA+DQo+ ID4gQmVjYXVzZSBwcmlvciByZmNzIGZvciBtb2RwIGdyb3VwcyBkaWQgbm90IHNwZWNpZnkgYSAi cSIsIEkgd2FzIG5vdA0KPiBzdXJlDQo+ID4gaWYgdGhpcyB3YXMgYSBuZXcgY29uc3RhbnQgb3Ig anVzdCBzdGF0aW5nIGEgc2l6ZSByZXF1aXJlbWVudD8NCj4gPiBTbyBJIHRvb2sgYSBsb29rIGF0 IE5JU1QgODAwLTU2QS4gSW4gcGFydGljdWxhciwNCj4gPg0KPiA+IDUuNi4xIFByaXZhdGUvUHVi bGljIEtleSBQYWlyIEdlbmVyYXRpb24NCj4gPg0KPiA+IDUuNi4xLjEgRkZDIEtleSBQYWlyIEdl bmVyYXRpb24NCj4gPiBGb3IgdGhlIEZGQyBzY2hlbWVzLCBlYWNoIHN0YXRpYyBhbmQgZXBoZW1l cmFsIHByaXZhdGUga2V5IGFuZCBwdWJsaWMNCj4gPiBrZXkgc2hhbGwgYmUgZ2VuZXJhdGVkIHVz aW5nIGFuIEFwcHJvdmVkIG1ldGhvZCBhbmQgdGhlIHNlbGVjdGVkDQo+IHZhbGlkDQo+ID4gZG9t YWluIHBhcmFtZXRlcnMgKHAsIHEsIGd7LCBTRUVELHBnZW5Db3VudGVyfSkgKHNlZSBBcHBlbmRp eCBCIG9mDQo+IEZJUFMNCj4gPiAxODYtMykuDQo+ID4gLi4uDQo+ID4NCj4gPiBJIHRoZW4gdG9v ayBhIGxvb2sgYXQgRklQUyAxODYtMywgQXBwZW5kaXggQiwgd2hpY2ggZG9jdW1lbnRzIDINCj4g bWV0aG9kcw0KPiA+IGZvciBmaW5pdGUgZmllbGQgY3J5cHRvZ3JhcGh5IChGRkMpIGtleSBwYWly IGdlbmVyYXRpb24uDQo+ID4gRm9yIGV4YW1wbGUsIG9uZSBtZXRob2QgaXMgIktleSBQYWlyIEdl bmVyYXRpb24gVXNpbmcgRXh0cmEgUmFuZG9tDQo+ID4gQml0cyIuIEl0IGFjdHVhbGx5IHN0YXRl cyB0aGF0ICJxIiBpcyBhbiBpbnB1dCBhbmQgaXQgaXMgdXNlZCB0byBkbw0KPiBhbg0KPiA+IGFk ZGl0aW9uYWwgY29tcHV0YXRpb24gdG8gY29tcHV0ZSAieCIuDQo+ID4NCj4gPiBJIGFtIHNvbWV3 aGF0IGNvbmZ1c2VkLCBhcmUgdGhlIG1vZHAgZ3JvdXBzIDIyLCAyMyAmIDI0IHN1cHBvc2UgdG8N Cj4gdXNlDQo+ID4gb25lIG9mIHRoZXNlIG5ldyBtZXRob2RzIGFuZCB0aGF0IGlzIHdoeSAicSIg aXMgZ2l2ZW4gaW4gcmZjIDUxMTQ/DQo+ID4gT3IgYW0gSSB0byBpZ25vcmUgdGhpcyBhbmQganVz dCBjb250aW51ZSB3aXRoIGV4aXN0aW5nIHdheQ0KPiA+IHdoZXJlICJxIiBpcyBub3QgdXNlZCBh bmQgdGhlcmUgYXJlbid0IGFueSBhZGRpdGlvbmFsIGNvbXB1dGF0aW9ucw0KPiA+IHRvIGNvbXB1 dGUgeC4NCj4gPg0KPiA+IEkgYW0gbm90IGV2ZW4gc3VyZSB0aGlzIGlzIGNvcnJlY3QgcGxhY2Ug dG8gYXNrLCBidXQgYW55IGFkdmljZQ0KPiA+IHdvdWxkIGJlIHdlbGNvbWUuDQo+ID4NCj4gPiBy ZWdhcmRzLA0KPiA+IEpveQ0KPiA+DQo+ID4NCj4gPiAoQ3V0LW4tcGFzdGUgZnJvbSBGSVBzIDE4 Ni0zIGJlbG93IHRvIHNob3cgaW5wdXQgYW5kIHByb2Nlc3MpDQo+ID4NCj4gPiAgSW5wdXQ6DQo+ ID4gICAgIChwLCBxLCBnKSAgICAgIFRoZSBzdWJzZXQgb2YgdGhlIGRvbWFpbiBwYXJhbWV0ZXJz IHRoYXQgYXJlIHVzZWQNCj4gPiAgICAgICAgICAgICAgICAgICAgZm9yIHRoaXMgcHJvY2Vzcy4g cCwgcSBhbmQgZyBzaGFsbCBlaXRoZXIgYmUNCj4gPiAgICAgICAgICAgICAgICAgICAgcHJvdmlk ZWQgYXMgaW50ZWdlcnMgZHVyaW5nIGlucHV0LCBvciBzaGFsbCBiZQ0KPiA+ICAgICAgICAgICAg ICAgICAgICBjb252ZXJ0ZWQgdG8gaW50ZWdlcnMgcHJpb3IgdG8gdXNlLg0KPiA+DQo+ID4gUHJv Y2VzczoNCj4gPiAxLiBOID0gbGVuKHEpOyBMID0gbGVuKHApLiAgICBDb21tZW50OiBDaGVjayB0 aGF0IHRoZSAoTCwgTikgcGFpcg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlz IHNwZWNpZmllZCBpbiBTZWN0aW9uIDQuMi4NCj4gPiAyLiBJZiB0aGUgKEwsIE4pIHBhaXIgaXMg aW52YWxpZCwgdGhlbiByZXR1cm4gYW4gRVJST1IgaW5kaWNhdG9yLA0KPiA+ICAgIEludmFsaWRf eCwgYW5kIEludmFsaWRfeS4NCj4gPiAzLiByZXF1ZXN0ZWRfc2VjdXJpdHlfc3RyZW5ndGggPSB0 aGUgc2VjdXJpdHkgc3RyZW5ndGggYXNzb2NpYXRlZA0KPiA+ICAgIHdpdGggdGhlIChMLCBOKSBw YWlyOyAgICAgIHNlZSBTUCA4MDAtNTcuDQo+ID4gNC4gT2J0YWluIGEgc3RyaW5nIG9mIE4rNjQg cmV0dXJuZWRfYml0cyBmcm9tIGFuIFJCRyB3aXRoIGEgc2VjdXJpdHkNCj4gPiAgICBzdHJlbmd0 aCBvZiByZXF1ZXN0ZWRfc2VjdXJpdHlfc3RyZW5ndGggb3IgbW9yZS4gSWYgYW4gRVJST1INCj4g PiAgICBpbmRpY2F0aW9uIGlzIHJldHVybmVkLCB0aGVuIHJldHVybiBhbiBFUlJPUiBpbmRpY2F0 aW9uLA0KPiA+ICAgIEludmFsaWRfeCwgYW5kIEludmFsaWRfeS4NCj4gPiA1LiBDb252ZXJ0IHJl dHVybmVkX2JpdHMgdG8gdGhlIChub24tbmVnYXRpdmUpIGludGVnZXIgYyAoc2VlDQo+ID4gICAg QXBwZW5kaXggQy4yLjEpLg0KPiA+IDYuIHggPSAoYyBtb2QgKHHigJMxKSkgKyAxLiAgICAgICBD b21tZW50OiAwIOKJpCBjIG1vZCAoceKAkzEpIOKJpCBx4oCTMiBhbmQNCj4gPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGltcGxpZXMgdGhhdCAxIOKJpCB4IOKJpCBx4oCTMS4NCj4g PiA3LiB5ID0gZ3ggbW9kIHAuDQo+ID4gOC4gUmV0dXJuIFNVQ0NFU1MsIHgsIGFuZCB5Lg0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gPiBJUHNlY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJUHNlYyBtYWlsaW5nIGxpc3QN Cj4gSVBzZWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHNlYw0K From kobara_conf@m.aist.go.jp Sat Mar 27 23:40:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA083A6A51 for ; Sat, 27 Mar 2010 23:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.34 X-Spam-Level: ** X-Spam-Status: No, score=2.34 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZZDvrOR3qDJ for ; Sat, 27 Mar 2010 23:40:24 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id BEF083A6A4F for ; Sat, 27 Mar 2010 23:40:23 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o2S6elBS017083 for ; Sun, 28 Mar 2010 15:40:48 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=m.aist.go.jp; s=aist; t=1269758448; bh=fmuC2ykf81FsGrRRu7BLS6m0SPRl4o8dtMlMQSUNg/w=; h=From:Date:Message-ID; b=kBypB3EWH4WEmVSqyC0SPV+iHBqUXMreeD4AsitbmvLru66oQIh1Up1O23MMY5FMy Tq23AaUy9dc7qyAP3hxFJw/B4IyqfjqWdZgVetCGpiKyTYCPnQEz9idSyewROmkKlD GMzmFLS6SYx8stktbf1P7zOOxjogDHoPpH3Zp4J8= Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o2S6ell2026635 for ; Sun, 28 Mar 2010 15:40:47 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) Received: by smtp1.aist.go.jp with ESMTP id o2S6ekiE010166 for ; Sun, 28 Mar 2010 15:40:46 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) From: "Kaz Kobara" To: References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> In-Reply-To: <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> Date: Sun, 28 Mar 2010 15:40:46 +0900 Message-ID: <001801cace41$98e87e10$cab97a30$@aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrN7owbc1//mc3YQq+KpCrtA+hPoQAUCmGw Content-Language: ja Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 06:40:25 -0000 > So is there a reason you don't want to fix this "between clients > and gateways"? (As most of this WG members have already noticed) PSK in IKE is foolish in the sense that it is vulnerable against off-line dictionary attack while using heavy DH calculation. There is no reason not to fix this foolish PSK (regardless of "between gateways" and "between clients and gateways".) Kaz From yaronf.ietf@gmail.com Sun Mar 28 01:40:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E423A67DB for ; Sun, 28 Mar 2010 01:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_33=0.6, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t-9XhV5+Rp2 for ; Sun, 28 Mar 2010 01:40:10 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 6A2003A6452 for ; Sun, 28 Mar 2010 01:40:10 -0700 (PDT) Received: by fxm5 with SMTP id 5so3037935fxm.29 for ; Sun, 28 Mar 2010 01:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=oC4w9/6DYetjtdlzOigcoSePdEKm8fH6CF0Jt4KMsu4=; b=EkjkUQlYujjJDGDbQt5u40jbpDM4pe1Q532Jdz7nbYYoLb/zT3slXOdu/JvwvGZjhG 76zcQl0WDtbeIX95NLi8M5XJwvCIhtHhgfabiNKRnnumIAkD4RjYcfSt64RbEcDePl2+ 1DcvRy1qi12lqDPOo0IVVILxlyQ+N6HVtsjv4= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Gy0tZwj9b8RGzHzENzmx5Qrqjjf4gDU7Gma2uUNf8F7XGt3moVKIEwbkNx4iJt75z1 2HKZ95Z06swSHjM/XOIPhbWYXLU7a3dmc9++KRy6uC62O4zKK6XXm2WZHNfaMweT25bM Y3SFrwnnUKgZyNOHPC+4LoDTjumyYFF7ASevc= Received: by 10.86.221.34 with SMTP id t34mr1834389fgg.36.1269765633279; Sun, 28 Mar 2010 01:40:33 -0700 (PDT) Received: from [10.20.30.13] ([62.219.129.160]) by mx.google.com with ESMTPS id d4sm4704351fga.5.2010.03.28.01.40.31 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Mar 2010 01:40:32 -0700 (PDT) Message-ID: <4BAF1610.8050004@gmail.com> Date: Sun, 28 Mar 2010 11:40:48 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Kaz Kobara References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> <001801cace41$98e87e10$cab97a30$@aist.go.jp> In-Reply-To: <001801cace41$98e87e10$cab97a30$@aist.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 08:40:11 -0000 Hi Kaz, Most of the WG members are aware of the whole picture: - The standard is clear that PSK must not be used with passwords. - The standard contains a good solution for the client-gateway case, which is already widely implemented, namely EAP. EAP is implemented by many AAA servers, is available on endpoints and simple to integrate into gateways, and is therefore the best way to set up a remote access solution if you have more than, say, 5 users. - Having two ways to do the same thing (e.g. IKE+EAP with a mutual auth method, and IKEv2 with the new proposed mode) is bad for interoperability and ultimately, for the success of the standard. Thanks, Yaron On 28.3.2010 9:40, Kaz Kobara wrote: >> So is there a reason you don't want to fix this "between clients >> and gateways"? > > (As most of this WG members have already noticed) > PSK in IKE is foolish in the sense that it is vulnerable against off-line > dictionary attack while using heavy DH calculation. > > There is no reason not to fix this foolish PSK (regardless of "between > gateways" and "between clients and gateways".) > > Kaz > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Sun Mar 28 02:41:57 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D475F3A693D for ; Sun, 28 Mar 2010 02:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3faummqYEZH for ; Sun, 28 Mar 2010 02:41:56 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id AC6BC3A6953 for ; Sun, 28 Mar 2010 02:41:55 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so537013fgb.13 for ; Sun, 28 Mar 2010 02:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2CaVS2cVY6wqtyrM2ZVg4s6YAi+mYfoQHVYITk2Dv7E=; b=UtVTpqjkG64oY46a4ofQ77kR+XHWToqLzsJKhP2uNqNEa7UU8wIaGFkf90I0bdwzCe UrMsvagSVZERaneh4+jxlwaSOoDFgTzCGuPil3QSJl3b5tFrn+c8mWHfl+gkYJ5kai5z AiEr4MxiuDydvtXbLyj4rXOwxkJvzOVx+2FjU= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=D7laD6zUsi0DaDixAI8jPTXiAT7Se4nVMMhiliREEc5ZXRJlbQc5WLS9VYVHn3pKpr qZrxlq82rw9N44tZimO/zW+Wb9BelBVPjEYlAZjZacu9Tt90Tu98YQnBbza/b9OT9hcl yeI2PXq7gU+kbBESJ9urDuxa3jUGCapCE8ExA= Received: by 10.86.22.31 with SMTP id 31mr5850224fgv.24.1269769338587; Sun, 28 Mar 2010 02:42:18 -0700 (PDT) Received: from [172.24.251.92] ([192.114.87.4]) by mx.google.com with ESMTPS id l12sm3586615fgb.2.2010.03.28.02.42.16 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Mar 2010 02:42:17 -0700 (PDT) Message-ID: <4BAF23A4.9010301@gmail.com> Date: Sun, 28 Mar 2010 12:38:44 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Dan Harkins References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE16A4.60108@gmail.com> <4BAE76BC.9060508@gmail.com> <3dd80c2646eeb2ddf00ce35d10a47a9a.squirrel@www.trepanning.net> In-Reply-To: <3dd80c2646eeb2ddf00ce35d10a47a9a.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Kaz Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 09:41:57 -0000 Hi Dan, I'm not suggesting to constrain the protocol. I'm trying to focus the discussion, and focus the criteria. We both know that integrating an existing PAKE into IKEv2 is not such a big deal. But we can spend months debating password management: - Do we specify a password policy? - Is the policy somehow exposed in the protocol? - Do you need special error handling to support password policy ("Your password will be expiring in 3 days")? - Do you need special protocol building blocks for password policy, e.g. to allow password change? - Do the IKE transport rules (timeouts) need to change to accommodate human input? And so on and so forth. This would all be highly important if we're going after the client-gateway case. I am trying to completely avoid this mess by focusing on the problem at hand, rather than trying to solve *everything*. The charter defines the problem we want to solve, based on WG consensus and IESG input. I suggest that we stick to it rather than continue arguing about it. Thanks, Yaron On 28.3.2010 3:39, Dan Harkins wrote: > > Hi Yaron, > > Since you did not respond to my question, I guess I can infer then that > there is no protocol issue _right now_ that would prevent some password > authentication scheme from being used with a "client" and a "gateway". > That being the case, the criteria document should not constrain any > possible solution. > > The charter mentions these use cases because you have to justify _why_ > you want to change the charter, what problem are you solving. Those > use cases were used to illustrate a problem to solve and justify why the > charter had to be changed. Just because you happen to solve problem A > with some protocol does not mean that the protocol must be prevented from > also solving problem B. > > If you want to use EAP then knock yourself out. If you're happy with > pointless encapsulation and more state machines and code you have to > implement then please have at it. But don't make a different protocol > hamstrung just because it might be used instead of EAP. > > There is no TECHNICAL reason to prevent a password authentication scheme > in IKE(v2) from being used between a "client" and a "gateway". Since we're > a working group that deals with technical issues we can therefore safely > dispense with any artificial constraints on our protocols. > > Dan. > > On Sat, March 27, 2010 2:21 pm, Yaron Sheffer wrote: >> Hi Dan, >> >> Again, the criteria document is just following the charter in mentioning >> this constraint. >> >> The protocol we end up with might have all sorts of nice-to-have >> features and behaviors. But for the criteria, we have to focus on what's >> important. Use cases that were excluded in the charter (and for good >> reason, because we have a perfectly good solution for them today) do not >> fall into this category. >> >> Thanks, >> Yaron >> >> On 27.3.2010 22:15, Dan Harkins wrote: >>> >>> Hi Yaron, >>> >>> You say below, "If a protocol can be specified for the general use >>> case, >>> that's very well. But there will be protocols that are only applicable >>> to some specific use cases, and that's fine, too." But then the criteria >>> document says, "This document is limited to the use of password-based >>> authentication to achieve trust between gateways." >>> >>> So basically the criteria document is specifying it for a particular >>> use only when there is no protocol issue that would prevent it from >>> being >>> used in the general case. It should be "very well" if it worked "for the >>> general use case" but the criteria draft is preventing it from doing so. >>> >>> In RFC 2409 it was not possible to do the "remote access" thing with >>> a >>> PSK because protocol limitations forced the PSK to be bound to one IP >>> address. That's an example of a protocol limiting usage. But I don't see >>> that now. What could possibly limit what we're talking about _right now_ >>> to some narrow uses? Maybe when we get around to designing the protocol >>> we'll run into something, and as you say "that's fine". But now, there >>> is >>> nothing to limit us and no reason to, a priori, say something is for >>> "gateways" only. >>> >>> Of course, I could be wrong. So maybe you could explain why there is >>> some protocol issue that prevents using password-based authentication in >>> the general case. >>> >>> Dan. >>> >>> On Sat, March 27, 2010 7:31 am, Yaron Sheffer wrote: >>>> Hi Dan, >>>> >>>> I'm afraid I disagree with you on several counts. See below. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 26.3.2010 20:11, Dan Harkins wrote: >>>>> >>>>> Telling administrators what they can and cannot do is really not >>>>> the function of our standards body. If someone wants to use a >>>>> "long secret" or a password to authenticate gateways, hosts, clients, >>>>> peers, or implementations (or whatever you want to call the box) it's >>>>> none of our business. We shouldn't say, "nope, sorry you can't do >>>>> that, >>>>> this is a client and you should use a stand-alone AAA server because >>>>> of >>>>> the obvious benefits that have eluded you." >>>> >>>> We cannot tell administrators anything for the simple reason that >>>> they're not looking to us for guidance. However we do have some >>>> influence over vendors, and we should tell vendors what we think makes >>>> sense, i.e. what is the architecturally correct way to use the >>>> protocol. >>>> >>>> More importantly, we should optimize the protocol (only) for the cases >>>> that we think are reasonable. So we should care very much about usage >>>> scenarios. As a concrete example, password management arguably matters >>>> much more to remote access than to gateway-to-gateway scenarios. Should >>>> we support it? Depends on the scenario(s) we want to work on. >>>>> >>>>> We have RFCs on "host requirements" and "router requirements". >>>>> There >>>>> isn't an RFC on "peer requirements" or "client requirements". Those >>>>> are >>>>> terms that started in marketecture powerpoint slides and should not be >>>>> used to constrain or neuter our protocols. >>>> No. For years we've had specific IPsec work items on remote access, >>>> it's >>>> nothing new. If a protocol can be specified for the general use case, >>>> that's very well. But there will be protocols that are only applicable >>>> to some specific use cases, and that's fine, too. >>>>> >>>>> Dan. >>>>> >>>>> On Fri, March 26, 2010 9:53 am, Kaz Kobara wrote: >>>>>> Hi Yaron >>>>>> >>>>>> Thank you for your clarification. >>>>>> >>>>>>> "between gateways" as opposed to >>>>>>> "between clients and gateways". So your assertion is correct. >>>>>> >>>>>> (Between gateways, administrators can set long secrets, so the >>>>>> necessity >>>>>> of >>>>>> PAKE seems smaller than between clients and gateways where passwords >>>>>> are >>>>>> recorded in the gateways and users have to type the passwords.) >>>>>> >>>>>> Anyway, if the scope is limited only on "between gateways" but not >>>>>> "between >>>>>> clients and gateways," the title >>>>>> "Password-Based Authentication in IKEv2: Selection Criteria and >>>>>> Comparison" >>>>>> seems misleading (since this itself misinforms that this criteria may >>>>>> be >>>>>> applied to IKEv2 in any cases), and the above should be clearly >>>>>> mentioned >>>>>> in >>>>>> the document. >>>>>> >>>>>> Kaz >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>>>>>> Sent: Friday, March 26, 2010 2:14 PM >>>>>>> To: Kaz Kobara >>>>>>> Cc: ipsec@ietf.org >>>>>>> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of >>>>>>> gateway) >>>>>>> >>>>>>> Hi Kaz, >>>>>>> >>>>>>> I *thought* my intention was clear: "between gateways" as opposed to >>>>>>> "between clients and gateways". So your assertion is correct. >>>>>>> >>>>>>> Thanks, >>>>>>> Yaron >>>>>>> >>>>>>> On 26.3.2010 1:40, Kaz Kobara wrote: >>>>>>>> Hi Yaron >>>>>>>> >>>>>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>>>>>> "This document is limited to the use of password-based >>>>>>>>> authentication >>>>>>> to >>>>>>>>> achieve trust between gateways" >>>>>>>> >>>>>>>> I would like to make sure that >>>>>>>> "gateway" in this document does not encompass VPN clients and >>>>>>>> hosts, >>>>>> right? >>>>>>>> >>>>>>>> Kaz >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>>>>>> Behalf >>>>>>> Of >>>>>>>>> Yaron Sheffer >>>>>>>>> Sent: Friday, March 26, 2010 3:31 AM >>>>>>>>> To: SeongHan Shin >>>>>>>>> Cc: IPsecme WG; Kazukuni Kobara >>>>>>>>> Subject: Re: [IPsec] New PAKE Criteria draft posted >>>>>>>>> >>>>>>>>> Hi Shin, >>>>>>>>> >>>>>>>>> Yes. For the typical remote access VPN, EAP is typically more >>>>>>>>> useful. >>>>>>>>> Note that there is still need for strong password-based mutual >>>>>>>>> authentication EAP methods - but their home is the EMU working >>>>>>>>> group. >>>>>>>>> >>>>>>>>> In addition, the IPsecME has another charter item designed to fit >>>>>>> such >>>>>>>>> EAP methods (such as the future EAP-AugPAKE :-) into IKEv2. >>>>>>>>> >>>>>>>>> Please see again the group's charter, >>>>>>>>> http://tools.ietf.org/wg/ipsecme/charters. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Yaron >>>>>>>>> >>>>>>>>> On 25.3.2010 20:07, SeongHan Shin wrote: >>>>>>>>>> Dear Yaron Sheffer, >>>>>>>>>> >>>>>>>>>> I have one question about the draft. >>>>>>>>>> >>>>>>>>>> draft-sheffer-ipsecme-pake-criteria-02.txt says in Page 4 >>>>>>>>>> "This document is limited to the use of password-based >>>>>>> authentication >>>>>>>>> to >>>>>>>>>> achieve trust between gateways" >>>>>>>>>> >>>>>>>>>> Is this a consensus of this WG? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Shin >>>>>>>>>> >>>>>>>>>> On Thu, Mar 25, 2010 at 3:46 PM, Yaron >>>>>>>>>> Sheffer>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> after the good discussion in Anaheim, and with the help of >>>>>> comments >>>>>>>>>> received on and off the list, I have updated the PAKE >>>>>>>>>> Criteria >>>>>>> draft >>>>>>>>>> and posted it as >>>>>>>>>> >>>>>>>>> http://www.ietf.org/id/draft-sheffer-ipsecme-pake-criteria-02.txt. >>>>>>>>>> >>>>>>>>>> I have added a number of criteria, clarified others, and >>>>>>>>>> added >>>>>>>>>> numbering (SEC1-SEC6, IPR1-IPR3 etc.). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Yaron >>>>>>>>>> _______________________________________________ >>>>>>>>>> IPsec mailing list >>>>>>>>>> IPsec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> SeongHan Shin >>>>>>>>>> Research Center for Information Security (RCIS), >>>>>>>>>> National Institute of Advanced Industrial Science and Technology >>>>>>> (AIST), >>>>>>>>>> Room no. 1003, Akihabara Daibiru 10F, >>>>>>>>>> 1-18-13, Sotokannda, Chiyoda-ku, Tokyo 101-0021 Japan >>>>>>>>>> Tel : +81-3-5298-2722 >>>>>>>>>> Fax : +81-3-5298-4522 >>>>>>>>>> E-mail : >>>>>>>>>> seonghan.shin@aist.go.jp >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 kobara_conf@m.aist.go.jp Sun Mar 28 05:06:26 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 724A23A6864 for ; Sun, 28 Mar 2010 05:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.665 X-Spam-Level: * X-Spam-Status: No, score=1.665 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiM0YKGoFCsX for ; Sun, 28 Mar 2010 05:06:25 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id 2330F3A67F2 for ; Sun, 28 Mar 2010 05:06:24 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o2SC6nlo017632 for ; Sun, 28 Mar 2010 21:06:49 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=m.aist.go.jp; s=aist; t=1269778009; bh=ZVaIQrSCedpN6dhzTFebuBQbAC6HBZ9/V4uKoiId7Lk=; h=From:Date:Message-ID; b=hygzJHJ0M8rrPYxH6VGEb2vznreO1z7JurkGzMyMmRCQVQuqMmOQBeysJmlGzzHNI NnCr4/xFuPaDj/hMLnYlQ0EjaC1EgJdVgEzjJRNUCiR/tHtPEf+3mnAydZYL8xD6Kn K6YfatuZap8kDcRn8wc7LXjwzedDUNb+HO9xdxS8= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o2SC6mrZ009178 for ; Sun, 28 Mar 2010 21:06:48 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id o2SC6hgx002946 for ; Sun, 28 Mar 2010 21:06:47 +0900 (JST) env-from (kobara_conf@m.aist.go.jp) From: "Kaz Kobara" To: References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> <001801cace41$98e87e10$cab97a30$@aist.go.jp> <4BAF1610.8050004@gmail.com> In-Reply-To: <4BAF1610.8050004@gmail.com> Date: Sun, 28 Mar 2010 21:06:43 +0900 Message-ID: <000301cace6f$24b23170$6e169450$@aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrOUlfZ2wZitPfTSwWVs+GYOp7O2QAGRoWw Content-Language: ja Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 12:06:26 -0000 Hi Yaron, I see. Your "client-gateway" means "client-gateway-AAA". OK, now we can go back to the title. Why don't you make it more specific, like "Password-Based Authentication between Gateways in IKEv2: Selection Criteria and Comparison" or something like that? This is really what you want to do, I bet. Regards, Kaz > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Sunday, March 28, 2010 5:41 PM > To: Kaz Kobara > Cc: ipsec@ietf.org > Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) > > Hi Kaz, > > Most of the WG members are aware of the whole picture: > > - The standard is clear that PSK must not be used with passwords. > - The standard contains a good solution for the client-gateway case, > which is already widely implemented, namely EAP. EAP is implemented by > many AAA servers, is available on endpoints and simple to integrate into > gateways, and is therefore the best way to set up a remote access > solution if you have more than, say, 5 users. > - Having two ways to do the same thing (e.g. IKE+EAP with a mutual auth > method, and IKEv2 with the new proposed mode) is bad for > interoperability and ultimately, for the success of the standard. > > Thanks, > Yaron > > On 28.3.2010 9:40, Kaz Kobara wrote: > >> So is there a reason you don't want to fix this "between clients > >> and gateways"? > > > > (As most of this WG members have already noticed) > > PSK in IKE is foolish in the sense that it is vulnerable against off-line > > dictionary attack while using heavy DH calculation. > > > > There is no reason not to fix this foolish PSK (regardless of "between > > gateways" and "between clients and gateways".) > > > > Kaz > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Sun Mar 28 06:17:13 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B573A6864 for ; Sun, 28 Mar 2010 06:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhsAd6TkmtnF for ; Sun, 28 Mar 2010 06:17:12 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 2E3AD3A6890 for ; Sun, 28 Mar 2010 06:17:07 -0700 (PDT) Received: by fxm5 with SMTP id 5so3138965fxm.29 for ; Sun, 28 Mar 2010 06:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2mP9zTf996cVxzKAQWltTeeJS7jNHtBaerX6QvYxfEo=; b=wgeK5oc3A7b0ymp5UBXulKb6NjZXEgBcb/tBHMJzsQ3VmJ3AG2Y5V/RviFKGXHl4iS HqzVSeyH2MhmejevI8mtjocSEsAVbZoJ4UnhbfyT4ahM3BJ/461dVMI7Kr34nrLw/Nog RnVPLQrYnpSzD6FU0VWj9bH8LRNl/alsavBIU= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=cwWJrs7kEDFDLpHP0YCO5NukFxVTULJ7E8mujH0fM1Ok9fdPjx+dl7qk3jdE5wc5JR +w1KlPDsbGDdmu+wfvBWLtDr5QiNXhSzgyFxKQzGIZRGc1hjeYzVSeHE9WC2KH6SJOTR 85jFJ0qBqX+nJ44kt06zCAgH1fTtDLICHAlXk= Received: by 10.86.221.34 with SMTP id t34mr2238601fgg.36.1269782249715; Sun, 28 Mar 2010 06:17:29 -0700 (PDT) Received: from [172.24.251.92] ([192.114.87.4]) by mx.google.com with ESMTPS id 4sm33692fge.23.2010.03.28.06.17.28 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Mar 2010 06:17:29 -0700 (PDT) Message-ID: <4BAF56E7.6040909@gmail.com> Date: Sun, 28 Mar 2010 16:17:27 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Kaz Kobara References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> <001801cace41$98e87e10$cab97a30$@aist.go.jp> <4BAF1610.8050004@gmail.com> <000301cace6f$24b23170$6e169450$@aist.go.jp> In-Reply-To: <000301cace6f$24b23170$6e169450$@aist.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 13:17:13 -0000 Hi Kaz, Sure. That would be an appropriate title. Thanks for helping to clarify this point! Regards, Yaron On 28.3.2010 15:06, Kaz Kobara wrote: > Hi Yaron, > > I see. > Your "client-gateway" means "client-gateway-AAA". > > OK, now we can go back to the title. > > Why don't you make it more specific, like > "Password-Based Authentication between Gateways in IKEv2: Selection Criteria > and Comparison" or something like that? > > This is really what you want to do, I bet. > > Regards, > Kaz > >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Sunday, March 28, 2010 5:41 PM >> To: Kaz Kobara >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) >> >> Hi Kaz, >> >> Most of the WG members are aware of the whole picture: >> >> - The standard is clear that PSK must not be used with passwords. >> - The standard contains a good solution for the client-gateway case, >> which is already widely implemented, namely EAP. EAP is implemented by >> many AAA servers, is available on endpoints and simple to integrate into >> gateways, and is therefore the best way to set up a remote access >> solution if you have more than, say, 5 users. >> - Having two ways to do the same thing (e.g. IKE+EAP with a mutual auth >> method, and IKEv2 with the new proposed mode) is bad for >> interoperability and ultimately, for the success of the standard. >> >> Thanks, >> Yaron >> >> On 28.3.2010 9:40, Kaz Kobara wrote: >>>> So is there a reason you don't want to fix this "between clients >>>> and gateways"? >>> >>> (As most of this WG members have already noticed) >>> PSK in IKE is foolish in the sense that it is vulnerable against > off-line >>> dictionary attack while using heavy DH calculation. >>> >>> There is no reason not to fix this foolish PSK (regardless of "between >>> gateways" and "between clients and gateways".) >>> >>> Kaz >>> >>> >>> _______________________________________________ >>> 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 paul.hoffman@vpnc.org Sun Mar 28 07:39:55 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684AA3A6894 for ; Sun, 28 Mar 2010 07:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.616 X-Spam-Level: X-Spam-Status: No, score=-3.616 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A55BMXQbTlrk for ; Sun, 28 Mar 2010 07:39:54 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2DB363A63EB for ; Sun, 28 Mar 2010 07:39:54 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2SEeJIF042366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 28 Mar 2010 07:40:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4BAF56E7.6040909@gmail.com> References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> <001801cace41$98e87e10$cab97a30$@aist.go.jp> <4BAF1610.8050004@gmail.com> <000301cace6f$24b23170$6e169450$@aist.go.jp> <4BAF56E7.6040909@gmail.com> Date: Sun, 28 Mar 2010 07:39:50 -0700 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 14:39:55 -0000 The disagreement between Dan and Yaron is over wording in the not-at-all normative criteria draft. This draft is not intended to become an RFC, and is not binding on the WG. It currently is being edited by Yaron; soon it will be edited by both Yaron and Dan. >From the active thread the past few days, it seems that Dan disagrees with Yaron's view that people thinking about the PAKE primarily as a gateway-to-gateway solution. That's fine: others in the WG might take one view or the other. I ask that Dan and Yaron produce an -03 with both views in it. I note that the current WG charter does not insist that the PAKE we choose be for gateway-to-gateway, but that it does list "authentication between two servers or routers" as a motivating scenario, and does not list remote access as a motivating scenario for the proposed new work. As WG members consider which criteria are important to them, they should also consider what scenarios we want to emphasize in the eventual document. I use the word "emphasize" here because we cannot prevent implementers and administrators from using the new authentication mechanism however they want; we have plenty of experience with IKE and IPsec documents saying "you should use this in that way" that are merrily ignored by large parts of the market. --Paul Hoffman, Director --VPN Consortium From kivinen@iki.fi Mon Mar 29 05:33:02 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FC33A694F for ; Mon, 29 Mar 2010 05:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLiVaaT4MrIr for ; Mon, 29 Mar 2010 05:33:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6083A67DA for ; Mon, 29 Mar 2010 05:33:00 -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 o2TCXIn6004424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Mar 2010 15:33:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o2TCXE8d012245; Mon, 29 Mar 2010 15:33:14 +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: <19376.40458.363401.49968@fireball.kivinen.iki.fi> Date: Mon, 29 Mar 2010 15:33:14 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <4BAF23A4.9010301@gmail.com> References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <4BAC4283.9010002@gmail.com> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE16A4.60108@gmail.com> <4BAE76BC.9060508@gmail.com> <3dd80c2646eeb2ddf00ce35d10a47a9a.squirrel@www.trepanning.net> <4BAF23A4.9010301@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: ipsec@ietf.org, Dan Harkins , Kaz Kobara Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 12:33:02 -0000 Yaron Sheffer writes: > I'm not suggesting to constrain the protocol. I'm trying to focus the > discussion, and focus the criteria. We both know that integrating an > existing PAKE into IKEv2 is not such a big deal. But we can spend months > debating password management: > > - Do we specify a password policy? > - Is the policy somehow exposed in the protocol? > - Do you need special error handling to support password policy ("Your > password will be expiring in 3 days")? > - Do you need special protocol building blocks for password policy, e.g. > to allow password change? > - Do the IKE transport rules (timeouts) need to change to accommodate > human input? As far as I can think all of those would be outside the charter. > And so on and so forth. This would all be highly important if we're > going after the client-gateway case. I disagree on that. I do not think those are important for the protocol point of view regardless whether we have client there or not. > The charter defines the problem we want to solve, based on WG consensus > and IESG input. I suggest that we stick to it rather than continue > arguing about it. The charter does not rule client-server or client-gateway out, it mostly just says that we need to define simplier solution than EAP, but I do not think it only limits you to server-server or router-router cases. For example for home or small office solutions there is no AAA server and using EAP to do remote access would not be feasible, thus I would expect most of the people currently use plain PSK in those environments, and they also do use weak passwords, thus would need something better. Also I think that kind of scenario is completely within our charter (if not, point me to the text which rules that out in our charter, note that it is still within charter even when that specific example is not given as example in charter). Most of the scenario text in charter uses words like "such as", "usually" etc, i.e they are not limiting charter to only those exact examples. The goal is defined as: "The WG will develop a standards-track extension to IKEv2 to allow mutual authentication based on "weak" (low-entropy) shared secrets. The goal is to avoid off-line dictionary attacks without requiring the use of certificates or EAP. " http://datatracker.ietf.org/wg/ipsecme/charter/ -- kivinen@iki.fi From rsjenwar@gmail.com Mon Mar 29 06:58:10 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41123A6A5C for ; Mon, 29 Mar 2010 06:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuRr6+Ft+8Xz for ; Mon, 29 Mar 2010 06:58:10 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 22E4A3A6A1A for ; Mon, 29 Mar 2010 06:58:01 -0700 (PDT) Received: by gxk9 with SMTP id 9so1590257gxk.8 for ; Mon, 29 Mar 2010 06:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=e7PJgsblF9l4tsKX62/t4rL/KwFeYCsmuG65Nysu6gM=; b=uGgJVYCeHvQkTwYHHERHM9D/CdgmfyG3O2HC8XDzYRtatAyy0NCemtpv4LYJc4I+2X UID/zds5N+JTLU1CEDgRhIBG6q2KvhQuYJNZMPMfURzi5B1zZ6R0S+jTaUXkAgj/8Umb nJ8gyIcIjxNQJu+uDl1NHBUZfnzYsD2Ab9Tng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sPbf2JjjJz8kU/pTS9etHixvn5ZPJTjv+M7DZkvCx3f5rc489PgqhdegJIDyPgdJcj /o8LapCDB+3W7hlONV7hOYC69py5WvMFyBbvz9gGRA/X8oYEPQjtVzd5pdDdsXEhelEx gYE6vAL7pKSUPdTnn0F/irt1VOJppnaMdGiVU= MIME-Version: 1.0 Received: by 10.90.73.11 with HTTP; Mon, 29 Mar 2010 06:58:24 -0700 (PDT) In-Reply-To: References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> <001801cace41$98e87e10$cab97a30$@aist.go.jp> <4BAF1610.8050004@gmail.com> <000301cace6f$24b23170$6e169450$@aist.go.jp> <4BAF56E7.6040909@gmail.com> Date: Mon, 29 Mar 2010 19:28:24 +0530 Received: by 10.90.4.32 with SMTP id 32mr1427202agd.25.1269871104662; Mon, 29 Mar 2010 06:58:24 -0700 (PDT) Message-ID: <7ccecf671003290658i4c4c33bbse9b006cd31320854@mail.gmail.com> From: Raj Singh To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016363105b71a9c6e0482f0e8e2 Cc: ipsec Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 13:58:10 -0000 --0016363105b71a9c6e0482f0e8e2 Content-Type: text/plain; charset=UTF-8 Hi Team, The similar scenarios are beautifully handled by Redirect RFC-5685. The Redirect RFC emphasize on client-gateway terminology, which is typical use of Redirect mechanism in IKEv2 where Gateway redirects client to another less loaded gateway but at the same time RFC is also applicable to router-router scenario when one router decides to off-load all existing IKEv2 sessions to another gateway when it goes down for maintenance etc. I totally agree with Paul. Best regards, Raj On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman wrote: > > > The disagreement between Dan and Yaron is over wording in the not-at-all > normative criteria draft. This draft is not intended to become an RFC, and > is not binding on the WG. It currently is being edited by Yaron; soon it > will be edited by both Yaron and Dan. > > From the active thread the past few days, it seems that Dan disagrees with > Yaron's view that people thinking about the PAKE primarily as a > gateway-to-gateway solution. That's fine: others in the WG might take one > view or the other. I ask that Dan and Yaron produce an -03 with both views > in it. I note that the current WG charter does not insist that the PAKE we > choose be for gateway-to-gateway, but that it does list "authentication > between two servers or routers" as a motivating scenario, and does not list > remote access as a motivating scenario for the proposed new work. > > As WG members consider which criteria are important to them, they should > also consider what scenarios we want to emphasize in the eventual document. > I use the word "emphasize" here because we cannot prevent implementers and > administrators from using the new authentication mechanism however they > want; we have plenty of experience with IKE and IPsec documents saying "you > should use this in that way" that are merrily ignored by large parts of the > market. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016363105b71a9c6e0482f0e8e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Team,

The similar scenarios are beautifully handled b= y Redirect RFC-5685.
The Redirect RFC emphasize on client-gateway= terminology, which is typical use of Redirect mechanism in IKEv2 where Gat= eway redirects client to another less loaded gateway but at the same time R= FC is also applicable to router-router scenario when one router decides to = off-load all existing IKEv2 sessions to another gateway when it goes down f= or maintenance etc.
I totally agree with Paul.

Best regards,
Raj

On Sun, Mar 28, 2010 at 8:09 PM= , Paul Hoffman <paul.hoffman@vpnc.org> wrote:
<wg-co-chair-hat on>

The disagreement between Dan and Yaron is over wording in the not-at-all no= rmative criteria draft. This draft is not intended to become an RFC, and is= not binding on the WG. It currently is being edited by Yaron; soon it will= be edited by both Yaron and Dan.

>From the active thread the past few days, it seems that Dan disagrees with = Yaron's view that people thinking about the PAKE primarily as a gateway= -to-gateway solution. That's fine: others in the WG might take one view= or the other. I ask that Dan and Yaron produce an -03 with both views in i= t. I note that the current WG charter does not insist that the PAKE we choo= se be for gateway-to-gateway, but that it does list "authentication be= tween two servers or routers" as a motivating scenario, and does not l= ist remote access as a motivating scenario for the proposed new work.

As WG members consider which criteria are important to them, they should al= so consider what scenarios we want to emphasize in the eventual document. I= use the word "emphasize" here because we cannot prevent implemen= ters and administrators from using the new authentication mechanism however= they want; we have plenty of experience with IKE and IPsec documents sayin= g "you should use this in that way" that are merrily ignored by l= arge parts of the market.

--Paul Hoffman, Director
--VPN Consortium
__________________________________= _____________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--0016363105b71a9c6e0482f0e8e2-- From turners@ieca.com Mon Mar 29 18:56:00 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8024B3A683F for ; Mon, 29 Mar 2010 18:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K+hQITCNJ2u for ; Mon, 29 Mar 2010 18:55:59 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id 5E3CE3A682E for ; Mon, 29 Mar 2010 18:55:56 -0700 (PDT) Received: (qmail 38333 invoked from network); 30 Mar 2010 01:56:22 -0000 Received: from thunderfish.local (turners@96.231.124.131 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 29 Mar 2010 18:56:21 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: rzr_EVUVM1nngNGWXdKkrj55VbVjwdOmprbNzZ9LurfHlgACd8qedPm2nf0rYutmsTTZAzPrVK.dpULzBOmv27BlYjw6XDC.N4jUGJPCGdOUyYJbkfb9zISEU4gC39DWj7rQZ2dPqDJYpeD37NSVIyVzCM_cnU6gCD2gP.xXvdhklO7T5PdcuM0S.sMtbYf9lLWZXDPT9cukSYxsXQ7fkpWLkUr3wMIXm5ms9Jxa0aWDmePcl7F4iB55yVXQTqMCwx2voUdpXMDCbjh9cUFVonGPS5YtCytGXHWDDgIF4X0gX_RRDNTQwJV4fgTURruTYhEtOU3L_XUrk8YWPsM7aHCYJPIqsuMhJP2tffty1l6Q6J8qkORkjYgBeH.QuSgSy51TRSldOAjpFCMRci.zVh.fO86CPZFdvLiEc07rOVI3YjywVkSP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BB15A44.8060205@ieca.com> Date: Mon, 29 Mar 2010 21:56:20 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] AD review comments for draft-ietf-ipsecme-ikev2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 01:56:00 -0000 Here is my AD review for draft-ietf-ipsecme-ikev2bis-08. I read this from the perspective of: I just picked this up how do I implement this. I found nothing wrong with the protocol, but there were lots of things that could be done to make this a bit easier to read (at least from my perspective of not having been eating and sleeping IPsec for years). As such, I consider all of my comments as editorial/nits. Sec 1: "exchange" is introduced in the 4th paragraph but abandoned in the 6th and 7th: r/"request/response"/"exchange". Sec 1.1: (IKE is deployed right) r/IKE is expected to be used to negotiate/IKE is used to negotiate Sec 1.1.3: At the end of the last paragraph add: (see Section 2.23) Sec 1.2: Should the 2nd and 3rd paragraph be swapped? Could also remove one of the two references to Section 2.14 for derived keys and then add the reference in later when SKEYSEED is introduced. Sec 1.2: Sometimes initiator and responder are split out in the notation/payload table and sometime they are not. There's also some notations missing that are used later (e.g., "Derived" for SK_d, as well as SK_pi, SK_pr, SK_ai, SK_er, SK_ei, SK_er, g^ir). Should the table be expanded to include these other notations? Also, N and CP always uses () in the figures so should () be in the table? Sec 1.2: r/DH/Diffie-Hellman or r/Diffie-Hellman exchange [DH]/Diffie-Hellman (DH) exchange [DH] Sec 1.2/1.3/3.3.4/3.4/D.9: D-H group, DH group, DH Group? Sec 1.2/2.6.1/2.13/2.15/3.4: (1.2) r/Diffie-Hellman group/Diffie-Hellman (DH) group. (elsewhere) r/Diffie-Hellman group/DH group and Diffie-Hellman Group/DH group and DH Group/DH group Sec 1.2: Should there be some discussion about traffic selectors after message #3 and #4? All of the fields are discussed except the TSi and TSr fields. Sec 1.2: 2nd paragraph after the 4th message refers to messages by number # (also occurs later in the document). Should we add text that says "later we sometimes refer to this as message number 1, 2, 3, or 4"? Sec 1.2: 3rd to last paragraph mentions responses that do not prevent an IKE_SA from being set up. Should the list (or a pointer to a list) of messages that do prevent a set up be listed here? Sec 1.2, 3rd to last para: r/The list of responses/The list of Notify Message Types Sec 1.2, 2nd to last para: r/(for example, AUTHENTICATION_FAILED)/(for example, the AUTHENTICATION_FAILED Notify Message Type error is returned) General: It would be really nice if the Notify Message Type (error vs status) was included every time a Notify Message Type is discussed. Sec 1.2, 2nd to last para: r/notification has/notification message has Sec 1.2, 2nd to last para: r/the error indication/the Notify Message Type indicating the error Sec 1.2/1.3: The third paragraph in 1.2 is repeated as the second paragraph in 1.3. Was this intentional? Sec 1.3: The fourth paragraph says that an implementation MAY refuse all CREATE_CHILD_SA requests within an IKE SA. Is there text somewhere that says doing so will result in x, y, z? Sec 1.3: r/the INVALID_KE_PAYLOAD/the INVALID_KE_PAYLOAD Notify payload Sec 1.3 (last para): r/This notify/This NOTIFY message Sec 1.3.1 (3rd para after response): r/NOT/not Sec 1.3.1: r/Failure of an attempt to create/A failed attempt to create Sec 1.3.3: r/Notify type/Notify Message Type Sec 1.4.1: r/delete payloads/Delete payloads X2 Sec 1.4.1: r/Informational exchange/INFORMATIONAL exchange Sec 1.4.3: r/Note that this specification nowhere specifies time periods/Note that this specification does not specifies time periods Sec 1.5: A reply is sent to "whence it came". Is that a loop or should "it" be replace the "the request"? Text as follows: The message is a response message, and thus it is sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID and Exchange Type are copied from the request. Sec 1.7: Figures and references are "bit more regular - are we giving them more fiber? :) Not sure what you mean by regular - maybe uniform? Sec 1.7: What is GMAC. I searched in the document and couldn't find it. Is it supposed to be HMAC? Sec 1.7: r/All of Section 2.25 was added to/Added Section 2.25 to Sec 2: r/oversize UDP messages/oversized UDP messages Sec 2.3: r/This Notify/This Notify Message Type Sec 2.3 (last pra): Should the optional be OPTIONAL? Sec 2.4: r/unprotected notifications/unprotected Notify messages Sec 2.4: r/This notification/This Notify Message Type Sec 2.4: Should INFORMATIONAL message be informational message. The earlier section differentiated between "INFORMATIONAL exchange" and "informational message." Sec 2.4: I noted the same thing Elwyn did about the 4th paragraph. Sec 2.4: r/There is a denial of service attack on the initiator of an IKE SA that can be avoided if the initiator takes the proper care./If the initiator takes proper care, then a denial of service attack on the initiator can be avoided. Sec 2.4 (X2)/2.6/2.21.1/2.21.4/2.23/3.6/3.10.1/5: r/denial of service/DoS Sec 2.5: r/notification message/Notify Message Type Sec 2.2/2.6: In 2.2 it's (I)nitiator in 2.6 it's I(nitiator). They ought to be consistent. Sec 2.6: is state and CPU exhaustion one attack or two? r/An expected attack against IKE is state and CPU exhaustion/Expected attacks against IKE are state and CPU exhaustion Sec 2.6: r/if an implementation of a responder /if a responder Sec 2.6: r/DOS/DoS Sec 2.6: r/this notification/this Notify Message Type Sec 2.7: r/combined mode/combined-mode X2 Sec 2.8.3: r/notify payload/Notify payload Sec 2.8.3: r/notify payloads/Notify payloads Sec 2.9: r/TS_UNACCEPTABLE/a Notify payload that contains TS_UNACCEPTABLE.* Sec 2.9: r/SINGLE_PAIR_REQUIRED/a Notify payload that contains SINGLE_PAIR_REQUIRED. Sec 2.11: Often times, I've seen DH qualified with ephemeral-ephemeral/ephemeral-static/static-static. Should it just be "ephemeral DH"? Sec 2.11: r/Since the computing of/Since computation of Sec 1.2/2.16/App C: If AUTH is optional in message 3, shouldn't AUTH be included as [AUTH] in Section 1.2 message 3? If you're not going to do the previous change: Sec 2.16: r/from message 3/from message 3 (compared to message 3 in Section 1.2 that does include the AUTH payload). Sec 2.18: Is it "DH transform" or "D-H transform"? Sec 2.19: Which message 3, #3 in 1.2 is different than 2.16 or does it not matter? Sec 1.2/2.19: Shouldn't "[CP()]" be in message 3 and 4 in Section 1.2? Sec 2.21.2, last sentence: I have the same question Elwyn has. Sec 2.23: Sometimes "traffic selectors" is "Traffic Selectors". Sec 2.23.1: r/it may hve a/it may have a Sec 2.23.1: r/normally looks the/normally looks at the Sec 2.23.1: (I think Elwyn also noted this) spell out first instance of PAD/SAD Sec 3.1: R(esponse) is (R)esponse in Sec 2.2; shouldn't it match 2.2? Sec 3.1: Version isn't set by senders (is there some subtlety about it not be an initiator?) and is ignored by responders. What good is this field? Sec 3.3: Should "proposal" and "transform" always be capitalized? Sec 3.3: Spell out ESN on first use. Sec 3.5: r/component,the/component, the Sec 3.5: Should [X.501] an [X.509] be replaced by [PKIX]? PKIX profiles these and PKIX certificates are referenced in section 4. Sec 3.10: Notification Data they're either status or error types: r/Notification Data (variable length) - Informational or error /Notification Data (variable length) - Status or error Sec 4: "PKIX Certificates" is used in Section 4, but Sec 8.1: Update reference for 3280 to 5280. App B: I did not verify the DH groups. App D: I did not verify all that was said that was done was. spt From yaronf.ietf@gmail.com Tue Mar 30 05:15:47 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583E13A6A49 for ; Tue, 30 Mar 2010 05:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.633 X-Spam-Level: X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvFyc06edXqB for ; Tue, 30 Mar 2010 05:15:46 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 664243A6A17 for ; Tue, 30 Mar 2010 05:15:10 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so3339301fga.13 for ; Tue, 30 Mar 2010 05:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YIraCdHJgy3TrNQ/hvrRJoydxegfYFA4/zKA3SJr8Xs=; b=Bj8OjEsacIGZAjiC0I6AXdiG1fDr/5V0EsP1jS1mCRs5TnImWr+aTvb/Zzc8ZTcDUB gHjou+bAzRuDJBwjO8rSUGQfPXX3BVbx21f7naXkEPPSqr4tgDXdDb5GlKMYZsxeRHGE MAgRhBZm6Fs+pXdiBRoc1eFPqcaaObrNNXZ6k= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=sfO0oNoI/ImI46UypddiYt3phCcY7G05Q+gqhxgRCswVhS21UYfC2TQN6Z5/raD2fe 0BTO+v7l6vNkBqA2ys/Ohrs9hfxcLhnzVE0EED/+nnWXB6t6RyGydFcKljKd/BUT2KAJ aZaVVuVMMBMrM8KF4/U1NFaGpnaXDyIFOVbOU= Received: by 10.86.6.15 with SMTP id 15mr8524315fgf.42.1269951335423; Tue, 30 Mar 2010 05:15:35 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id l19sm5572055fgb.26.2010.03.30.05.15.34 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 05:15:35 -0700 (PDT) Message-ID: <4BB1EB7A.6000403@gmail.com> Date: Tue, 30 Mar 2010 15:15:54 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Raj Singh References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <018001cacd04$d59efc50$80dcf4f0$@aist.go.jp> <4BAE10BC.7090401@gmail.com> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> <001801cace41$98e87e10$cab97a30$@aist.go.jp> <4BAF1610.8050004@gmail.com> <000301cace6f$24b23170$6e169450$@aist.go.jp> <4BAF56E7.6040909@gmail.com> <7ccecf671003290658i4c4c33bbse9b006cd31320854@mail.gmail.com> In-Reply-To: <7ccecf671003290658i4c4c33bbse9b006cd31320854@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec , Paul Hoffman Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 12:15:47 -0000 Hi Raj, this in fact is the perfect counter-example: RFC 5685 started out with the client-gateway scenario, and when we woke up to see how it can be generalized to the symmetric gateway-gateway case, it was too late. Hence Sec. 10, which says that the resulting protocol is a very partial solution for this case. 10. Use of the Redirect Mechanism between IKEv2 Peers The redirect mechanism described in this document is mainly intended for use in client-gateway scenarios. However, the mechanism can also be used between any two IKEv2 peers. But this protocol is asymmetric, meaning that only the original responder can redirect the original initiator to another server. I'm not saying that we were right in ignoring this case. I'm saying that you can only get the protocol that you want if you define the requirements clearly up front. Thanks, Yaron On 29.3.2010 16:58, Raj Singh wrote: > Hi Team, > > The similar scenarios are beautifully handled by Redirect RFC-5685. > The Redirect RFC emphasize on client-gateway terminology, which is > typical use of Redirect mechanism in IKEv2 where Gateway redirects > client to another less loaded gateway but at the same time RFC is also > applicable to router-router scenario when one router decides to off-load > all existing IKEv2 sessions to another gateway when it goes down for > maintenance etc. > I totally agree with Paul. > > Best regards, > Raj > > On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman > wrote: > > > > The disagreement between Dan and Yaron is over wording in the > not-at-all normative criteria draft. This draft is not intended to > become an RFC, and is not binding on the WG. It currently is being > edited by Yaron; soon it will be edited by both Yaron and Dan. > > From the active thread the past few days, it seems that Dan > disagrees with Yaron's view that people thinking about the PAKE > primarily as a gateway-to-gateway solution. That's fine: others in > the WG might take one view or the other. I ask that Dan and Yaron > produce an -03 with both views in it. I note that the current WG > charter does not insist that the PAKE we choose be for > gateway-to-gateway, but that it does list "authentication between > two servers or routers" as a motivating scenario, and does not list > remote access as a motivating scenario for the proposed new work. > > As WG members consider which criteria are important to them, they > should also consider what scenarios we want to emphasize in the > eventual document. I use the word "emphasize" here because we cannot > prevent implementers and administrators from using the new > authentication mechanism however they want; we have plenty of > experience with IKE and IPsec documents saying "you should use this > in that way" that are merrily ignored by large parts of the market. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > 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 rsjenwar@gmail.com Tue Mar 30 05:43:49 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329F83A68A9 for ; Tue, 30 Mar 2010 05:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.724 X-Spam-Level: X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO0onBs8c3vc for ; Tue, 30 Mar 2010 05:43:48 -0700 (PDT) Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.210.184]) by core3.amsl.com (Postfix) with ESMTP id 5F7A13A6A3E for ; Tue, 30 Mar 2010 05:43:41 -0700 (PDT) Received: by yxe14 with SMTP id 14so1434267yxe.5 for ; Tue, 30 Mar 2010 05:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=9myxBUKQ8Qu5A2P/uadyv3wigvJbvitZgJZGTvbgy20=; b=YVZuIvN4xFVR+kDGW+8fndQMjlNlVJp5/S+rF9ILXM0gB9BEDtbv/bPOmFg8DqGtQQ B9aVkIFQEFkthRIvIp0VxGctcNigL9UzUDjUP/U8l7iqsSTgQ4i4MT0j17EtSrucEvWM jju0emrqbnAV8MLuKvFb6vdh0d9JwyD099Uv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ducX2L/16ZB3jOmRDc8VtNEUFaoWGbRFcqifY9qUZiFthdepn0cLSGGjne7dj6wvWn MLAZXvHXVjrm7L1lWbkP/Hd8iQ/MKt6E5DWcw5/xNZeR+NUz1HXe5k18b7b0oZ/mxCI+ ifOGXH8ZUNkNNclkcu+nRBMxa5lsOHC+14sls= MIME-Version: 1.0 Received: by 10.90.73.11 with HTTP; Tue, 30 Mar 2010 05:43:56 -0700 (PDT) In-Reply-To: <4BB1EB7A.6000403@gmail.com> References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> <001801cace41$98e87e10$cab97a30$@aist.go.jp> <4BAF1610.8050004@gmail.com> <000301cace6f$24b23170$6e169450$@aist.go.jp> <4BAF56E7.6040909@gmail.com> <7ccecf671003290658i4c4c33bbse9b006cd31320854@mail.gmail.com> <4BB1EB7A.6000403@gmail.com> Date: Tue, 30 Mar 2010 18:13:56 +0530 Received: by 10.90.59.25 with SMTP id h25mr3832708aga.108.1269953038568; Tue, 30 Mar 2010 05:43:58 -0700 (PDT) Message-ID: <7ccecf671003300543p7e9678d6n1b638eb25165dade@mail.gmail.com> From: Raj Singh To: Yaron Sheffer Content-Type: multipart/alternative; boundary=0016363107dfc0287f048303fb62 Cc: ipsec , Paul Hoffman Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 12:43:49 -0000 --0016363107dfc0287f048303fb62 Content-Type: text/plain; charset=UTF-8 Hi Yaron, You are saying the same things what i am saying, then i am not able to understand how its counter example? The point i want to make here, "We can emphasize the main use case scenario the draft, but protocol should have a space for generality". According to me RFC - 5685 is good example of the above. Best regards, Raj On Tue, Mar 30, 2010 at 5:45 PM, Yaron Sheffer wrote: > Hi Raj, > > this in fact is the perfect counter-example: RFC 5685 started out with the > client-gateway scenario, and when we woke up to see how it can be > generalized to the symmetric gateway-gateway case, it was too late. Hence > Sec. 10, which says that the resulting protocol is a very partial solution > for this case. > > 10. Use of the Redirect Mechanism between IKEv2 Peers > > The redirect mechanism described in this document is mainly intended > for use in client-gateway scenarios. However, the mechanism can also > be used between any two IKEv2 peers. But this protocol is > asymmetric, meaning that only the original responder can redirect the > original initiator to another server. > > I'm not saying that we were right in ignoring this case. I'm saying that > you can only get the protocol that you want if you define the requirements > clearly up front. > > Thanks, > Yaron > > > On 29.3.2010 16:58, Raj Singh wrote: > >> Hi Team, >> >> The similar scenarios are beautifully handled by Redirect RFC-5685. >> The Redirect RFC emphasize on client-gateway terminology, which is >> typical use of Redirect mechanism in IKEv2 where Gateway redirects >> client to another less loaded gateway but at the same time RFC is also >> applicable to router-router scenario when one router decides to off-load >> all existing IKEv2 sessions to another gateway when it goes down for >> maintenance etc. >> I totally agree with Paul. >> >> Best regards, >> Raj >> >> On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman > > wrote: >> >> >> >> The disagreement between Dan and Yaron is over wording in the >> not-at-all normative criteria draft. This draft is not intended to >> become an RFC, and is not binding on the WG. It currently is being >> edited by Yaron; soon it will be edited by both Yaron and Dan. >> >> From the active thread the past few days, it seems that Dan >> disagrees with Yaron's view that people thinking about the PAKE >> primarily as a gateway-to-gateway solution. That's fine: others in >> the WG might take one view or the other. I ask that Dan and Yaron >> produce an -03 with both views in it. I note that the current WG >> charter does not insist that the PAKE we choose be for >> gateway-to-gateway, but that it does list "authentication between >> two servers or routers" as a motivating scenario, and does not list >> remote access as a motivating scenario for the proposed new work. >> >> As WG members consider which criteria are important to them, they >> should also consider what scenarios we want to emphasize in the >> eventual document. I use the word "emphasize" here because we cannot >> prevent implementers and administrators from using the new >> authentication mechanism however they want; we have plenty of >> experience with IKE and IPsec documents saying "you should use this >> in that way" that are merrily ignored by large parts of the market. >> >> --Paul Hoffman, Director >> --VPN Consortium >> _______________________________________________ >> 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 >> > --0016363107dfc0287f048303fb62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yaron,

You are saying the same things what i am sayin= g, then i am not able to understand how its counter example?
The = point i want to make here,=C2=A0
"We can emphasize the main = use case scenario the draft, but protocol should have a space for generalit= y".
According to me RFC - 5685 is good example of the above.
Best regards,
Raj


=
On Tue, Mar 30, 2010 at 5:45 PM, Yaron Shef= fer <yaronf.i= etf@gmail.com> wrote:
Hi Raj,

this in fact is the perfect counter-example: RFC 5685 started out with the = client-gateway scenario, and when we woke up to see how it can be generaliz= ed to the symmetric gateway-gateway case, it was too late. Hence Sec. 10, w= hich says that the resulting protocol is a very partial solution for this c= ase.

10. =C2=A0Use of the Redirect Mechanism between IKEv2 Peers

=C2=A0 The redirect mechanism described in this document is mainly intende= d
=C2=A0 for use in client-gateway scenarios. =C2=A0However, the mechanism c= an also
=C2=A0 be used between any two IKEv2 peers. =C2=A0But this protocol is
=C2=A0 asymmetric, meaning that only the original responder can redirect t= he
=C2=A0 original initiator to another server.

I'm not saying that we were right in ignoring this case. I'm saying= that you can only get the protocol that you want if you define the require= ments clearly up front.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron


On 29.3.2010 16:58, Raj Singh wrote:
Hi Team,

The similar scenarios are beautifully handled by Redirect RFC-5685.
The Redirect RFC emphasize on client-gateway terminology, which is
typical use of Redirect mechanism in IKEv2 where Gateway redirects
client to another less loaded gateway but at the same time RFC is also
applicable to router-router scenario when one router decides to off-load all existing IKEv2 sessions to another gateway when it goes down for
maintenance etc.
I totally agree with Paul.

Best regards,
Raj

On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman <paul.hoffman@vpnc.org
<= div>
<mailto:paul.= hoffman@vpnc.org>> wrote:

=C2=A0 =C2=A0<wg-co-chair-hat on>

=C2=A0 =C2=A0The disagreement between Dan and Yaron is over wording in the=
=C2=A0 =C2=A0not-at-all normative criteria draft. This draft is not intend= ed to
=C2=A0 =C2=A0become an RFC, and is not binding on the WG. It currently is = being
=C2=A0 =C2=A0edited by Yaron; soon it will be edited by both Yaron and Dan= .

=C2=A0 =C2=A0 From the active thread the past few days, it seems that Dan<= br> =C2=A0 =C2=A0disagrees with Yaron's view that people thinking about th= e PAKE
=C2=A0 =C2=A0primarily as a gateway-to-gateway solution. That's fine: = others in
=C2=A0 =C2=A0the WG might take one view or the other. I ask that Dan and Y= aron
=C2=A0 =C2=A0produce an -03 with both views in it. I note that the current= WG
=C2=A0 =C2=A0charter does not insist that the PAKE we choose be for
=C2=A0 =C2=A0gateway-to-gateway, but that it does list "authenticatio= n between
=C2=A0 =C2=A0two servers or routers" as a motivating scenario, and do= es not list
=C2=A0 =C2=A0remote access as a motivating scenario for the proposed new w= ork.

=C2=A0 =C2=A0As WG members consider which criteria are important to them, = they
=C2=A0 =C2=A0should also consider what scenarios we want to emphasize in t= he
=C2=A0 =C2=A0eventual document. I use the word "emphasize" here = because we cannot
=C2=A0 =C2=A0prevent implementers and administrators from using the new =C2=A0 =C2=A0authentication mechanism however they want; we have plenty of=
=C2=A0 =C2=A0experience with IKE and IPsec documents saying "you shou= ld use this
=C2=A0 =C2=A0in that way" that are merrily ignored by large parts of = the market.

=C2=A0 =C2=A0--Paul Hoffman, Director
=C2=A0 =C2=A0--VPN Consortium
=C2=A0 =C2=A0_______________________________________________
=C2=A0 =C2=A0IPsec mailing list
=C2=A0 =C2=A0IPsec@iet= f.org <mailto:IP= sec@ietf.org>

=C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/ipsec




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

--0016363107dfc0287f048303fb62-- From yaronf.ietf@gmail.com Tue Mar 30 05:50:36 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60723A6A09 for ; Tue, 30 Mar 2010 05:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM0XKoo6sQ61 for ; Tue, 30 Mar 2010 05:50:35 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id D84EB3A686E for ; Tue, 30 Mar 2010 05:50:30 -0700 (PDT) Received: by fxm5 with SMTP id 5so4613234fxm.29 for ; Tue, 30 Mar 2010 05:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+ctBohOTrULIK4OVSaGBJAi0H02U7wY17o58/rkOk0A=; b=ZP/kgELVPuZhSD7rMUtABBMWl7Qa9uhH/kHNB98mTO8Pt912vNUxIh4gn87wsag2Tr i3Wr7ygs5kSrI/NfltTrLc1ZDMFROPSK9b4YYILeHqiWf8JtlRrPeU5m0OHxd96LkrNI 9Jw1JHD6driMtRdpolFiX9F2kRBxS6j+jqNco= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=m5Kgs9br400BipRqBm9oAQkVmW7y3sTsUXGxjhJco+pYvWMxIWfZ2GTWAia3YAvfrs 2KOk6jBRoXJ9qDpteYhthQMeJrcuhWb/c1nAOCiFeuEwCUicXRLnrhzu5aAK2ecu724+ MZOSSkCOqpCi57xRVqSqhTPRu+04ri1P7U6Z0= Received: by 10.87.47.25 with SMTP id z25mr3831632fgj.13.1269953455736; Tue, 30 Mar 2010 05:50:55 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id e20sm553690fga.21.2010.03.30.05.50.53 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 05:50:54 -0700 (PDT) Message-ID: <4BB1F3C2.1080509@gmail.com> Date: Tue, 30 Mar 2010 15:51:14 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Raj Singh References: <015701cacc74$9b0f3c20$d12db460$@aist.go.jp> <001001cacdd7$557f0190$007d04b0$@aist.go.jp> <3b12564381bb3d1b9eea9b3276a68487.squirrel@www.trepanning.net> <001801cace41$98e87e10$cab97a30$@aist.go.jp> <4BAF1610.8050004@gmail.com> <000301cace6f$24b23170$6e169450$@aist.go.jp> <4BAF56E7.6040909@gmail.com> <7ccecf671003290658i4c4c33bbse9b006cd31320854@mail.gmail.com> <4BB1EB7A.6000403@gmail.com> <7ccecf671003300543p7e9678d6n1b638eb25165dade@mail.gmail.com> In-Reply-To: <7ccecf671003300543p7e9678d6n1b638eb25165dade@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec , Paul Hoffman Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 12:50:36 -0000 Hi Raj, No, RFC 5685 tried for generality without defining the usage scenario in advance, and this attempt failed. The solution cannot be used gateway-gateway, because it depends on the (arbitrary) initiator/responder distinction. Thanks, Yaron On 30.3.2010 15:43, Raj Singh wrote: > Hi Yaron, > > You are saying the same things what i am saying, then i am not able to > understand how its counter example? > The point i want to make here, > "We can emphasize the main use case scenario the draft, but protocol > should have a space for generality". > According to me RFC - 5685 is good example of the above. > > Best regards, > Raj > > > On Tue, Mar 30, 2010 at 5:45 PM, Yaron Sheffer > wrote: > > Hi Raj, > > this in fact is the perfect counter-example: RFC 5685 started out > with the client-gateway scenario, and when we woke up to see how it > can be generalized to the symmetric gateway-gateway case, it was too > late. Hence Sec. 10, which says that the resulting protocol is a > very partial solution for this case. > > 10. Use of the Redirect Mechanism between IKEv2 Peers > > The redirect mechanism described in this document is mainly intended > for use in client-gateway scenarios. However, the mechanism can also > be used between any two IKEv2 peers. But this protocol is > asymmetric, meaning that only the original responder can redirect the > original initiator to another server. > > I'm not saying that we were right in ignoring this case. I'm saying > that you can only get the protocol that you want if you define the > requirements clearly up front. > > Thanks, > Yaron > > > On 29.3.2010 16:58, Raj Singh wrote: > > Hi Team, > > The similar scenarios are beautifully handled by Redirect RFC-5685. > The Redirect RFC emphasize on client-gateway terminology, which is > typical use of Redirect mechanism in IKEv2 where Gateway redirects > client to another less loaded gateway but at the same time RFC > is also > applicable to router-router scenario when one router decides to > off-load > all existing IKEv2 sessions to another gateway when it goes down for > maintenance etc. > I totally agree with Paul. > > Best regards, > Raj > > On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman > > >> > wrote: > > > > The disagreement between Dan and Yaron is over wording in the > not-at-all normative criteria draft. This draft is not > intended to > become an RFC, and is not binding on the WG. It currently is > being > edited by Yaron; soon it will be edited by both Yaron and Dan. > > From the active thread the past few days, it seems that Dan > disagrees with Yaron's view that people thinking about the PAKE > primarily as a gateway-to-gateway solution. That's fine: > others in > the WG might take one view or the other. I ask that Dan and > Yaron > produce an -03 with both views in it. I note that the current WG > charter does not insist that the PAKE we choose be for > gateway-to-gateway, but that it does list "authentication > between > two servers or routers" as a motivating scenario, and does > not list > remote access as a motivating scenario for the proposed new > work. > > As WG members consider which criteria are important to them, > they > should also consider what scenarios we want to emphasize in the > eventual document. I use the word "emphasize" here because > we cannot > prevent implementers and administrators from using the new > authentication mechanism however they want; we have plenty of > experience with IKE and IPsec documents saying "you should > use this > in that way" that are merrily ignored by large parts of the > market. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > 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 rbriscoe@jungle.bt.co.uk Tue Mar 30 09:20:24 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A873A6A02 for ; Tue, 30 Mar 2010 09:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.486 X-Spam-Level: ** X-Spam-Status: No, score=2.486 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_40=-0.185, DATE_IN_PAST_96_XX=1.69, DNS_FROM_OPENWHOIS=1.13, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5riQo9JG-4X for ; Tue, 30 Mar 2010 09:20:15 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 3DAF13A6A6E for ; Tue, 30 Mar 2010 09:19:58 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 17:20:28 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 17:20:28 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1269966026605; Tue, 30 Mar 2010 17:20:26 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.128.107]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2UGKMVA006770; Tue, 30 Mar 2010 17:20:23 +0100 Message-Id: <201003301620.o2UGKMVA006770@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Mar 2010 17:13:49 +0000 To: ipsec@ietf.org From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Mar 2010 16:20:28.0035 (UTC) FILETIME=[E905C530:01CAD024] Cc: tsvwg chair Subject: [IPsec] draft-ietf-tsvwg-ecn-tunnel: backwd compat RFC4301 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 16:20:24 -0000 IPsecME folks, I would like to draw your attention to from the transport area w-g. You may recall I gave early warning of this work to the Security Area open meeting back in July'09. A formal SecDir review has just been requested, but voluntary reviews from other people who live & breath IPsec would also be greatly appreciated. We want to get this right. Please include me in the distr if you post any issues (or non-issues), as I'm not permantently subscribed to . Ideally cc . You will notice it updates 4301 decap. I want to emphasise that the update only affects a combination of inner & outer that is currently unused (CU) - existing 4301 behaviour remains completely unchanged, and it adds no modes or options. Abstract is below. Cheers Bob ======================================================================== Transport Area Working Group B. Briscoe Internet-Draft BT Updates: 3168, 4301 March 03, 2010 (if approved) Intended status: Standards Track Expires: September 4, 2010 Tunnelling of Explicit Congestion Notification draft-ietf-tsvwg-ecn-tunnel-08 Abstract This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP in IP tunnel. On encapsulation it updates RFC3168 to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec ECN processing. On decapsulation it updates both RFC3168 and RFC4301 to add new behaviours for previously unused combinations of inner and outer header. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion, whereas before only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, providing backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g. for pre-congestion notification--PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC4774 gives guidance on designing alternate ECN semantics and this document extends that to include tunnelling issues. ________________________________________________________________ Bob Briscoe, BT Innovate & Design From paul.hoffman@vpnc.org Tue Mar 30 16:59:36 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20443A68E4 for ; Tue, 30 Mar 2010 16:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.842 X-Spam-Level: X-Spam-Status: No, score=-2.842 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgGosML8rT12 for ; Tue, 30 Mar 2010 16:59:36 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 1CA193A686C for ; Tue, 30 Mar 2010 16:59:35 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2V004Jd037368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Mar 2010 17:00:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 30 Mar 2010 16:59:18 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] ikev2bis issue #181: Section 2.4 unclear on Child SA failing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 23:59:36 -0000 Section 2.4 says "If Child SAs can fail independently from one another without the associated IKE SA being able to send a delete message, then they MUST be negotiated by separate IKE SAs". It is not clear what this means. Does it apply to implementations? If so, how can an implementation know whether or not the first clause is true? I propose removing the sentence, or greatly clarifying it. From paul.hoffman@vpnc.org Tue Mar 30 16:59:37 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2B93A6C31 for ; Tue, 30 Mar 2010 16:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.964 X-Spam-Level: X-Spam-Status: No, score=-3.964 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9Zf7p2E5Ecc for ; Tue, 30 Mar 2010 16:59:36 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 813213A68C2 for ; Tue, 30 Mar 2010 16:59:36 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2V004Jf037368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Mar 2010 17:00:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 30 Mar 2010 16:59:24 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] ikev2bis issue #182: Marking CP() as optional in early sections X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 23:59:37 -0000 Sean Turner asks: Sec 1.2/2.19: Shouldn't "[CP()]" be in message 3 and 4 in Section 1.2? From paul.hoffman@vpnc.org Tue Mar 30 16:59:38 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD083A6C36 for ; Tue, 30 Mar 2010 16:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.155 X-Spam-Level: X-Spam-Status: No, score=-4.155 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdHJWP0lCV2p for ; Tue, 30 Mar 2010 16:59:37 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2CB6B3A686C for ; Tue, 30 Mar 2010 16:59:37 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2V004Jh037368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Mar 2010 17:00:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 30 Mar 2010 16:59:30 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] ikev2bis issue #183: Replace "X.509" with "PKIX" throughout? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 23:59:39 -0000 We use "X.509" when we probably mean "PKIX". That is, we only care about the PKIX profile of X.509, not just the base X.509 spec. However, X.509 appears in some of the protocol element names. Can we change it throughout to PKIX, or are we stuck with the old name? From paul.hoffman@vpnc.org Tue Mar 30 16:59:39 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D183A6C43 for ; Tue, 30 Mar 2010 16:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.282 X-Spam-Level: X-Spam-Status: No, score=-4.282 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2r1oqe7KlBx for ; Tue, 30 Mar 2010 16:59:38 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CC2763A6C2C for ; Tue, 30 Mar 2010 16:59:37 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2V004Jj037368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Mar 2010 17:00:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 30 Mar 2010 16:59:35 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] ikev2bis issue #184: Interaction of rekeying of the IKE_SA and windows X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 23:59:39 -0000 s2.3: Should there be some discussion of the interaction of rekeying of the IKE_SA and windows? Presumably a rekey message should not be actioned until all previous messages have been responded to. Likewise receiving a Message ID with a sequence number bigger than that in the rekey message should be very suspect! Should the INVALID_MESSAGE_ID notification be sent in this case (and before or after the rekey?) There might be some knock on into s2.8 where rekeying is discussed. And maybe into s2.25? From paul.hoffman@vpnc.org Tue Mar 30 17:14:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF283A6C3D for ; Tue, 30 Mar 2010 17:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.372 X-Spam-Level: X-Spam-Status: No, score=-4.372 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nclpR-uNiRnm for ; Tue, 30 Mar 2010 17:14:02 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 618473A6C38 for ; Tue, 30 Mar 2010 17:14:01 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2V004Jn037368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Mar 2010 17:00:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 30 Mar 2010 16:59:48 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] ikev2bis issue #186: Generating and accepting which types? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 00:14:05 -0000 s3.5, para after ID Field types table: 'Implementations SHOULD be capable of generating and accepting all of these types.' Does 'all' here mean the four types in the previous sentence or 'all' the types in the full table? From paul.hoffman@vpnc.org Tue Mar 30 17:14:09 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E4D3A6C3D for ; Tue, 30 Mar 2010 17:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.44 X-Spam-Level: X-Spam-Status: No, score=-4.44 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaHPxpvI8XKN for ; Tue, 30 Mar 2010 17:14:05 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 49A423A6C54 for ; Tue, 30 Mar 2010 17:14:02 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2V004Jl037368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Mar 2010 17:00:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 30 Mar 2010 16:59:40 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] ikev2bis issue #185: What do to if you don't ignore INITIAL_CONTACT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 00:14:09 -0000 s2.4, para 2, says "The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response, not as a separate exchange afterwards; receiving parties MAY ignore it in other messages." What should receiving parties do if they *do* receive it and *don't* ignore it? Since it 'MUST be sent in the first IKE_AUTH' receiving at any other time is a protocol error and should cause some response (like dropping the IKE_SA perhaps). From paul.hoffman@vpnc.org Tue Mar 30 17:14:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A463A6C5B for ; Tue, 30 Mar 2010 17:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.493 X-Spam-Level: X-Spam-Status: No, score=-4.493 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk7W6BQCNLM8 for ; Tue, 30 Mar 2010 17:14:09 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B79803A6C55 for ; Tue, 30 Mar 2010 17:14:02 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2V004Jp037368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Mar 2010 17:00:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 30 Mar 2010 17:00:01 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] ikev2bis issue #187: EAP introduction wording X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 00:14:12 -0000 The first paragraph of 3.16 now says: The Extensible Authentication Protocol Payload, denoted EAP in this document, allows IKE SAs to be authenticated using the protocol defined in RFC 3748 and subsequent extensions to that protocol. The full set of acceptable values for the payload is defined elsewhere, but a short summary of RFC 3748 is included here to make this document stand alone in the common cases. Where is "defined elsewhere"? We should be specific. Also, we agreed to remove the short list of EAP methods, but we didn't fix the last phrase above. Suggested wording would be appreciated. From yaronf.ietf@gmail.com Wed Mar 31 02:17:24 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB1A3A6BEE for ; Wed, 31 Mar 2010 02:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJUpehoDxE3O for ; Wed, 31 Mar 2010 02:17:21 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 010B63A6BD9 for ; Wed, 31 Mar 2010 02:17:17 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so3640695fga.13 for ; Wed, 31 Mar 2010 02:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=MxnT712H0e8wlsDcF9Q+CFOj50LMdrd/qDMJGv3yddw=; b=MydoGfDqZrOvgcgBG5/De5/W5ttb+aUhqDQyJB18CTl5gNw/MlmFprmnphbJbvEu96 68lufGiz6a12ke0w4fS9WbtH4WUNst/I03CTxOFBrn4FUP0oXMC0xa9yh0f3IrNEgQ5f 5u06RwGgCXmG4QsFsaOBt2ZnpXMSeLpj1ByYc= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=mdLZFyjeTA6QAQMC9areXl9KilDAOBIuumMQcjQh4DEOWK9zpw41Pv+2PxJ+b8dgKr osGyEQYzV+njjGLeqg/cyecVUUvUwzJuljpiRtKCPQd8LUIGtPQCtOSR2/95rOqibJtU /Hw26Mg9SQdim36WeVPByUeVODTnTRCrh+yNE= Received: by 10.86.124.8 with SMTP id w8mr3126996fgc.8.1270027065266; Wed, 31 Mar 2010 02:17:45 -0700 (PDT) Received: from [10.20.30.2] ([62.219.129.160]) by mx.google.com with ESMTPS id 4sm9253354fgg.7.2010.03.31.02.17.43 (version=SSLv3 cipher=RC4-MD5); Wed, 31 Mar 2010 02:17:44 -0700 (PDT) Message-ID: <4BB31335.4060105@gmail.com> Date: Wed, 31 Mar 2010 12:17:41 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] ikev2bis issue #183: Replace "X.509" with "PKIX" throughout? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 09:17:25 -0000 Quoting from Wikipedia (http://en.wikipedia.org/wiki/X.509): The X.500 system has never been fully implemented, and the IETF's Public-Key Infrastructure (X.509), or PKIX, working group has adapted the standard to the more flexible organization of the Internet. In fact, the term X.509 certificate usually refers to the IETF's PKIX Certificate and CRL Profile of the X.509 v3 certificate standard, as specified in RFC 5280, commonly referred to as PKIX for Public Key Infrastructure (X.509). I suggest to retain the existing X.509 terminology which is more common, adding a clarification somewhere that we really refer to the PKIX profile. Thanks, Yaron On 31.3.2010 2:59, Paul Hoffman wrote: > We use "X.509" when we probably mean "PKIX". That is, we only care about the PKIX profile of X.509, not just the base X.509 spec. However, X.509 appears in some of the protocol element names. Can we change it throughout to PKIX, or are we stuck with the old name? > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Wed Mar 31 02:26:24 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EC13A69B5 for ; Wed, 31 Mar 2010 02:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTyaPXuUFjmt for ; Wed, 31 Mar 2010 02:26:23 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 7657F3A6870 for ; Wed, 31 Mar 2010 02:26:23 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so3642906fga.13 for ; Wed, 31 Mar 2010 02:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=wKdmuNHotEHEgkHjopCH3R7v2vv4sBaCy/SeOMvjqd8=; b=PgEFVO+MNRRocKA2ZpxoX8eRRIo1EFPb/67M0KgU1nRKS/WaTB9D2gqXaQbOEtbZgr rt3U3g6YEQgxXiUjCZnwg2/XNXVw9WxWCZ4Ry7Ida/EJoHrCcP83VyBMfXcfwLhfCyUU K6GYmhOMmGZock7E2KqJmPfkvU+fnaoTK7ofM= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=r3Zj7H4ErffXiCryZJlVlIIALPhVqERcjGBNb1XsKafFbcnKDdiTFfJQa1+bO/HuWL fFVnp/2AfXzDLyaKmlCLSlI5G+W/lSehIcnik5UPUZa/cZgBWRFJK576CwdU7KXxdTFR Rsmp0sJYp9x9yqCtT8kWas8u4Yqoy8nhX5qdg= Received: by 10.86.126.33 with SMTP id y33mr1306554fgc.51.1270027609877; Wed, 31 Mar 2010 02:26:49 -0700 (PDT) Received: from [10.20.30.2] ([62.219.129.160]) by mx.google.com with ESMTPS id e3sm8643112fga.24.2010.03.31.02.26.48 (version=SSLv3 cipher=RC4-MD5); Wed, 31 Mar 2010 02:26:49 -0700 (PDT) Message-ID: <4BB31556.4040105@gmail.com> Date: Wed, 31 Mar 2010 12:26:46 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] ikev2bis issue #185: What do to if you don't ignore INITIAL_CONTACT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 09:26:24 -0000 Presumably, such implementations would do the same as they normally do for INITIAL_CONTACT: The INITIAL_CONTACT notification asserts that this IKE SA is the only IKE SA currently active between the authenticated identities. It MAY be sent when an IKE SA is established after a crash, and the recipient MAY use this information to delete any other IKE SAs it has to the same authenticated identity without waiting for a timeout. The original RFC did not specify that it MUST be sent in a specific message, and therefore we'd better leave it somewhat vague instead of forcing the protocol to fail otherwise. In particular because the normal recipient behavior is a MAY. Thanks, Yaron On 31.3.2010 2:59, Paul Hoffman wrote: > s2.4, para 2, says "The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response, not as a separate exchange afterwards; receiving parties MAY ignore it in other messages." > > What should receiving parties do if they *do* receive it and *don't* ignore it? Since it 'MUST be sent in the first IKE_AUTH' receiving at any other time is a protocol error and should cause some response (like dropping the IKE_SA perhaps). > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From root@core3.amsl.com Wed Mar 31 06:00:02 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 492143A68F7; Wed, 31 Mar 2010 06:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100331130002.492143A68F7@core3.amsl.com> Date: Wed, 31 Mar 2010 06:00:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 13:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Author(s) : S. Shen, et al. Filename : draft-ietf-ipsecme-aes-ctr-ikev2-06.txt Pages : 10 Date : 2010-03-31 This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-aes-ctr-ikev2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-31055426.I-D@ietf.org> --NextPart-- From turners@ieca.com Wed Mar 31 11:25:39 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43CE63A6A7C for ; Wed, 31 Mar 2010 11:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ULcE0gSiSGq for ; Wed, 31 Mar 2010 11:25:37 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 012463A6928 for ; Wed, 31 Mar 2010 11:24:42 -0700 (PDT) Received: (qmail 96156 invoked from network); 31 Mar 2010 18:25:11 -0000 Received: from thunderfish.local (turners@96.231.120.117 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 31 Mar 2010 11:25:11 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: yJeDVi8VM1khdvY8Pjfe_TovuAdCnSJRkFYRD1sv9WOMK3NKqMUfEYxR43nE3kieRFz7tujz4cWMhvaTGA94p2BA4H0.HuomcSkmaUYyIpSUZVh2__XXs7r.FkCSIWFL_F_OF1f6ni2XIGBu.QAeneIayllMwegnASM7c8cJ1kU9d3MV4VVB2jUwagdZ4bhxJRiPE3w_E93oe1HiqxCGIDikv8VvFKtcMA1WBq3TjA6zi5YPVeFjIjC8y4cm46zkuxXlj_DD96Sk5GQcFMVl6m7X0xexCtW9gS6EknepOI5Bf4y5BKvHHrqtZp32m7Qh1oe9eVmtrBOC3cypiUdjC0iFpjpZlggGzzsLj8Kr0TuwR_j6j76Ux7Qhhpef2whO3bsRE.zTF8_N4KoNdzlnGUg8wJAibkn46WJS.Pkkvy_XquwUr9coJWANgfBERcgxZgG6VBCol9si0PwUnBQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BB39387.3040709@ieca.com> Date: Wed, 31 Mar 2010 14:25:11 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yaron Sheffer References: <4BB31335.4060105@gmail.com> In-Reply-To: <4BB31335.4060105@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] ikev2bis issue #183: Replace "X.509" with "PKIX" throughout? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 18:25:39 -0000 Sec 3.5 is where the references to [X.501] and [X.509] are. You could just replace them with [PKIX], delete the two informative references, and be done. spt Yaron Sheffer wrote: > Quoting from Wikipedia (http://en.wikipedia.org/wiki/X.509): > > The X.500 system has never been fully implemented, and the IETF's > Public-Key Infrastructure (X.509), or PKIX, working group has adapted > the standard to the more flexible organization of the Internet. In fact, > the term X.509 certificate usually refers to the IETF's PKIX Certificate > and CRL Profile of the X.509 v3 certificate standard, as specified in > RFC 5280, commonly referred to as PKIX for Public Key Infrastructure > (X.509). > > I suggest to retain the existing X.509 terminology which is more common, > adding a clarification somewhere that we really refer to the PKIX profile. > > Thanks, > Yaron > > On 31.3.2010 2:59, Paul Hoffman wrote: >> We use "X.509" when we probably mean "PKIX". That is, we only care >> about the PKIX profile of X.509, not just the base X.509 spec. >> However, X.509 appears in some of the protocol element names. Can we >> change it throughout to PKIX, or are we stuck with the old name? >> >> _______________________________________________ >> 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 turners@ieca.com Wed Mar 31 11:53:48 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0AC3A67B1 for ; Wed, 31 Mar 2010 11:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynOtoi9SrDnN for ; Wed, 31 Mar 2010 11:53:47 -0700 (PDT) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id 42B553A68E5 for ; Wed, 31 Mar 2010 11:53:46 -0700 (PDT) Received: (qmail 97488 invoked from network); 31 Mar 2010 18:54:17 -0000 Received: from thunderfish.local (turners@96.231.120.117 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 31 Mar 2010 11:54:17 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: A1Md5hkVM1kPHAHS0qH514pgEbUGKuT3U95HJyCd_Ifaci1G_NxkvcEZZ7DC9vkbZwvUNREHX8_MVVKYsazsKHJajdfAkxPAP10PqdWMF6j0eG4gp027n531KBMK_O2Ua3cA7BV.2rhZjvoVIv4oZuhfsphrI9IxKpkM092ztLFVymBQ4KXJV3FCE85ssv3UghYVJf8ndy6Y87BUMOaZlkiJEYqn71NKYZPSl6nHGUkOxbbRNsurS541FOH6aVTYAO9j9Y99ZjEoHaZOUeS3KhgdVSIBnQacZlENOvHAWS8_11pCH0HxUpdDUDGzv.sQ8b05vkSY6r8THN_oTgwykS.tBt44tFIJ_nFyc5iey1NQnMh.eOND_1O6eb94q_nzyN21C7sSEVUoT._G64XLCUmLJv_UrXOLm8Xfm3WpM97k1lQoo_2BI6h_C2HhF73.qQkXIAjmcXmg.bZ1sYA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BB39A58.9090702@ieca.com> Date: Wed, 31 Mar 2010 14:54:16 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: ipsec@ietf.org References: <20100331130002.492143A68F7@core3.amsl.com> In-Reply-To: <20100331130002.492143A68F7@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 18:53:48 -0000 According to idnits, there's a dangling informative reference to [RFC2404]. Please delete it and resubmit. Thanks, spt Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. > > > Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 > Author(s) : S. Shen, et al. > Filename : draft-ietf-ipsecme-aes-ctr-ikev2-06.txt > Pages : 10 > Date : 2010-03-31 > > This document describes the usage of Advanced Encryption Standard > Counter Mode (AES-CTR), with an explicit initialization vector, by > IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT > exchange. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From root@core3.amsl.com Wed Mar 31 20:00:02 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3E5F63A6811; Wed, 31 Mar 2010 20:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100401030002.3E5F63A6811@core3.amsl.com> Date: Wed, 31 Mar 2010 20:00:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 03:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Author(s) : S. Shen, et al. Filename : draft-ietf-ipsecme-aes-ctr-ikev2-07.txt Pages : 10 Date : 2010-03-31 This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-aes-ctr-ikev2-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-31194938.I-D@ietf.org> --NextPart--