From paul.hoffman@vpnc.org Sun May 2 19:13: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 C0B763A6B84 for ; Sun, 2 May 2010 19:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=-2.821, BAYES_80=2, HELO_MISMATCH_COM=0.553] 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 W-pvBEqoz+61 for ; Sun, 2 May 2010 19:13:03 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 8AEBB3A6B73 for ; Sun, 2 May 2010 19:13: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 hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o432CirU044159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 May 2010 19:12:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1272292059.2347.12.camel@yaronf-linux> References: <1271864821.6636.55.camel@yaronf-linux> <1272292059.2347.12.camel@yaronf-linux> Date: Sun, 2 May 2010 19:12:42 -0700 To: Yaron Sheffer , ipsec From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] IPsec HA problem statement 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, 03 May 2010 02:13:03 -0000 At 5:27 PM +0300 4/26/10, Yaron Sheffer wrote: >There has been very little follow-on discussion on this draft, just a >few mails related to one proposed solution. So if you've read the draft >and think it's complete and good to go into WGLC, let us all know. If >some things are still missing, tell us which. Different vendors have >different views, and Yoav's problem statement may not cover them all. ...and there was no response to Yaron's plea. Have we lost steam? Is the draft really ready to go? --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sun May 2 19:14: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 744663A6B7B for ; Sun, 2 May 2010 19:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 mIvQwsWt2+JK for ; Sun, 2 May 2010 19:14:01 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BBE743A6B74 for ; Sun, 2 May 2010 19: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 hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o432DjkV044194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 2 May 2010 19:13:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 2 May 2010 19:13:44 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication) 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, 03 May 2010 02:14:02 -0000 At 2:39 PM -0700 4/21/10, Paul Hoffman wrote: >Greetings again. We have kicked around draft-ietf-ipsecme-eap-mutual and its predecessor for a long time, and it seems like there have been few substantial comments lately. > >Thus, this starts the two-week WG Last Call on "An Extension for EAP-Only Authentication in IKEv2", . Please send any comments on the document to the mailing list. Support, criticism, and suggestions for additions or changes are all appropriate. At a minimum, I would like to see a handful of people say "I have read the draft". Zero comments so far. Without more input from the WG, we might want to just kill this draft, which would be quite sad. --Paul Hoffman, Director --VPN Consortium From JArora@acmepacket.com Sun May 2 20:29: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 DCDA33A6BBA for ; Sun, 2 May 2010 20:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=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 yhq2qjEOQM3F for ; Sun, 2 May 2010 20:29:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D4B013A6B91 for ; Sun, 2 May 2010 20:29:47 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 2 May 2010 23:29:32 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 2 May 2010 23:29:32 -0400 From: Jitender Arora To: Tero Kivinen Date: Sun, 2 May 2010 23:29:30 -0400 Thread-Topic: [IPsec] New draft posted Thread-Index: Acrl/usPMO3jVKKvQdC+CdfIL5IzqQEbxT39 Message-ID: References: <1272187315.22380.46.camel@yaronf-linux> , <19414.51287.786283.875147@fireball.kivinen.iki.fi> In-Reply-To: <19414.51287.786283.875147@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 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New 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, 03 May 2010 03:29:49 -0000 Hi Tero, Thanks for your feedback. Currently the IKEv2 does not allow the IKEv2 signaling and the IPSEC tr= affic to go to different IP addresses, so this is the problem this draft is= trying to solve. The application where it is required now is the load balancing of the I= PSEC tunnels. Suppose in a network there are 10 Security-Gateways and each = of these security gateways can handle 200000 IPSEC tunnels using the IKEv2 = signaling. Now for this network if we need a load balancer device which can= balance the tunnels across these security gateways, this load balancer dev= ice will be handling the IKEv2 signaling coming from the 10 *200000 clients= which is 2 Million clients. In addition to handling the IKEv2 signaling fr= om these clients, this will also have to handle the bidirectional IPSEC tra= ffic between the clients and security gateways. So in this case this load b= alancing device needs to be very scalable and also high performance box. Th= is might not be practical. So to solve this problem, this draft proposes that if we can allow the = IPSEC traffic on the different addresses than the IKEv2 signaling, the load= balancer can handle only the IKEv2 signaling and chose the right security = gateway, and this security gateway can tell the client to send the IPSEC tr= affic directly to the security gateway without going through the Load Balan= cer. This way the load balancer does not need to worry about the IPSEC traf= fic and this will not put a lot of strain on these boxes. You are right, the IKEv2 SA and the CHILD SA will still be on the same = machine, but will be using the different addresses. Hope this helps, Please let me know what you think. Thanks, Jitender ________________________________________ From: Tero Kivinen [kivinen@iki.fi] Sent: Tuesday, April 27, 2010 7:19 AM To: Jitender Arora Cc: Yaron Sheffer; ipsec@ietf.org Subject: Re: [IPsec] New draft posted Jitender Arora writes: > 1. I will point the section 5.1 in the introduction itself that way > the purpose and applications of the draft are clear. After I read the section 5.1 (I skipped most of the other draft as I needed to know first WHY this is needed before I care about HOW it is implemented), and I do not really see enough text there to cause me to read the HOW part. So I would need better and more text about WHY this extension is needed. Why it is important that the IKEv2 SA and Child SA uses different outer addresses? Who is supposed to terminate the IKEv2 SA and who is supposed to terminate the Child SAs. Is this assuming that IKEv2 SA and Child SA are still on the same machine or what? If so, why not just use the IP address of that host for both IKEv2 SA and Child SA? So I think the usage scenarios (WHY part) is much more important than the actual protocol (HOW part), and it should be clear from the beginning. Currently this draft mostly assumes there is problem, but it does not explain why you think the problem actually exists or what the problem is. -- kivinen@iki.fi From Pasi.Eronen@nokia.com Mon May 3 00:19: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 E2AA03A6C38 for ; Mon, 3 May 2010 00:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.927 X-Spam-Level: X-Spam-Status: No, score=-4.927 tagged_above=-999 required=5 tests=[AWL=-0.928, 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 NtBM3bueHdkr for ; Mon, 3 May 2010 00:19:10 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 569EC3A6932 for ; Mon, 3 May 2010 00:19:10 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o437IPAQ029109; Mon, 3 May 2010 02:18:54 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 May 2010 10:18:29 +0300 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); Mon, 3 May 2010 10:18:10 +0300 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, 3 May 2010 09:18:09 +0200 From: To: Date: Mon, 3 May 2010 09:18:07 +0200 Thread-Topic: [IPsec] New draft posted Thread-Index: Acrl/usPMO3jVKKvQdC+CdfIL5IzqQEbxT39AAhucoA= Message-ID: <808FD6E27AD4884E94820BC333B2DB775B82BAF899@NOK-EUMSG-01.mgdnok.nokia.com> References: <1272187315.22380.46.camel@yaronf-linux> , <19414.51287.786283.875147@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 X-OriginalArrivalTime: 03 May 2010 07:18:10.0126 (UTC) FILETIME=[C8F65EE0:01CAEA90] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] New 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, 03 May 2010 07:19:12 -0000 Jitender Arora wrote: > The application where it is required now is the load balancing of > the IPSEC tunnels. Suppose in a network there are 10 Security-Gateways > and each of these security gateways can handle 200000 IPSEC tunnels > using the IKEv2 signaling. Now for this network if we need a load > balancer device which can balance the tunnels across these security > gateways, this load balancer device will be handling the IKEv2 > signaling coming from the 10 *200000 clients which is 2 Million > clients. In addition to handling the IKEv2 signaling from these > clients, this will also have to handle the bidirectional IPSEC traffic > between the clients and security gateways. So in this case this load > balancing device needs to be very scalable and also high performance > box. This might not be practical. >=20 > So to solve this problem, this draft proposes that if we can allow > the IPSEC traffic on the different addresses than the IKEv2 signaling, > the load balancer can handle only the IKEv2 signaling and chose the > right security gateway, and this security gateway can tell the client > to send the IPSEC traffic directly to the security gateway without > going through the Load Balancer. This way the load balancer does not > need to worry about the IPSEC traffic and this will not put a lot of > strain on these boxes. >=20 > You are right, the IKEv2 SA and the CHILD SA will still be on the > same machine, but will be using the different addresses. If the IKEv2 SA and Child SAs are on the same box, why isn't RFC 5685 sufficient to solve this problem? RFC 5685 doesn't support using different IP addresses for IKEv2 and ESP/AH, but it would allow bypassing the load balancer for established IKE SAs, precisely they way you describe.=20 Best regards, Pasi From martin@strongswan.org Mon May 3 02:13: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 588F13A6C43 for ; Mon, 3 May 2010 02:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_ORG=0.611] 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 HYFYNI0KUAZV for ; Mon, 3 May 2010 02:13:52 -0700 (PDT) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by core3.amsl.com (Postfix) with ESMTP id 0ABA53A6C41 for ; Mon, 3 May 2010 02:13:51 -0700 (PDT) Received: from 224-92.105-92.cust.bluewin.ch ([92.105.92.224] helo=[192.168.1.36]) by strongswan.org with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O8rhC-0008Hk-LR; Mon, 03 May 2010 11:12:10 +0200 From: Martin Willi To: Paul Hoffman In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 03 May 2010 11:13:30 +0200 Message-ID: <1272878010.1762.77.camel@martin> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication) 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, 03 May 2010 09:13:53 -0000 Hi, > Thus, this starts the two-week WG Last Call on "An Extension for > EAP-Only Authentication in IKEv2", > . Please > send any comments on the document to the mailing list. Support, > criticism, and suggestions for additions or changes are all > appropriate. At a minimum, I would like to see a handful of people say > "I have read the draft". We have added experimental support for this draft to version 4.3.6 of our strongSwan open source IKEv2 daemon. I think the draft looks good from an implementors perspective, here some comments: - Section 4 lists two requirements for EAP methods: mutual authentication and key generation. As noted in section 6.3, an active attacker can intercept plain EAP packets. I think it would be a good idea to add a "dictionary-attack-resistant" property to the requirement list. There are methods that have the other two properties, but are not a good candidate for use with this draft. The widely deployed EAP-MSCHAPv2 is such an example. Using it with the draft will highly degrade the security of the IKEv2 protocol. - The example of using EAP-GSS with with Kerberos in section 2 to replace KINK is probably not the best one for the reason above. Or is this combination in the end any more secure than using IKEv2 PSK with weak passwords? - What's the reason for not adding EAP-TLS to the list of save methods? I think EAP-TLS is a perfect candidate. It might be questionable to use TLS within IKEv2 at all, but there actually are higher level protocols that exactly use this combination. EAP-SIM is another candidate probably worth to mention, having very similar properties as EAP-AKA. - Section 3: > If the responder supports this notification, it omits the public key > based AUTH payload and CERT payloads from message 4. This might be misleading, as the responder can ignore this notify even if it supports the extension. This would make sense if the selected EAP method does not have the required properties. "May omit"? Best regards Martin From ynir@checkpoint.com Mon May 3 03:00: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 7C70B28C0EB for ; Mon, 3 May 2010 03:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_50=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 LqVtvUphmnjS for ; Mon, 3 May 2010 03:00:25 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id EC2CE28C0DF for ; Mon, 3 May 2010 03:00:21 -0700 (PDT) X-CheckPoint: {4BDEAC13-0-1B201DC2-1FFFF} 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 o43A01pp009920; Mon, 3 May 2010 13:00:01 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 3 May 2010 13:00:31 +0300 From: Yoav Nir To: "'Paul Hoffman'" , IPsecme WG Date: Mon, 3 May 2010 13:00:30 +0300 Thread-Topic: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication) Thread-Index: AcrqZlj3IOiTDS58Q160OZ/ydP3vHwAPW/qA Message-ID: <006FEB08D9C6444AB014105C9AEB133FB37650C5DB@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] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication) 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, 03 May 2010 10:00:26 -0000 Can't compete with Martin's "running code", but I have a few comments. Befo= re that, the draft seems good, and easy to follow. I think developers who h= ave never heard of the IPsec list should have no problem reading and implem= enting this correctly. Having said that, here's two comments. The introduction says this: In some environments, requiring the deployment of PKI for just this purpose can be counterproductive. Deploying new infrastructure can be expensive, and it may weaken security by creating new vulnerabilities. Mutually authenticating EAP methods alone can provide a sufficient level of security in many circumstances, and indeed, IEEE 802.11i uses EAP without any PKI for authenticating the WLAN access points. The way this is phrased, it sounds like you need to deploy a full PKI for t= he gateway to show a certificate. Web servers do HTTPS without all this. Th= ey use either a relatively cheap commercial certificate or a self-signed ce= rtificate. The question is what value is there in the client verifying the = certificate. With a self-signed certificate (or a corporate certificate) it= 's really a one-time leap of faith ("do you approve the fingerprint...") li= ke with SSH servers. To do any better, you would need a full PKI with all c= omputers pre-installed with the root trust anchor (or using TAMP). And if y= ou have all that in place, you might as well issue certificates to users an= d skip EAP altogether. So I would rephrase it as: In order for the public key signature authentication of the gateway to b= e effective, a deployment of PKI is required, which has to include management of trust anchors on all supplicants. In many environments,=20 this is not realistic, and the security of the gateway public key is=20 the same as the security of a self-signed certificate. Mutually=20 authenticating EAP methods alone can... Nowhere in the document does it say, why the EAP method needs to be key-gen= erating. In fact, RFC 4306 says that it is recommended, but goes on to say = what to do if the method is not key-generating. This document should make i= t clear why omitting the server-side signature changes things such that key= generation has become crucial. The only thing I could find was section 6.1= , which says: It is important to note that the IKEv2 SA is not authenticated by just running an EAP conversation: the crucial step is the AUTH payload based on the EAP-generated key. Thus, EAP methods that do not provide mutual authentication or establish a shared secret key MUST NOT be used with the modifications presented in this document. Why is it crucial? =20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Monday, May 03, 2010 5:14 AM To: IPsecme WG Subject: Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual= (EAP-Only Authentication) At 2:39 PM -0700 4/21/10, Paul Hoffman wrote: >Greetings again. We have kicked around draft-ietf-ipsecme-eap-mutual and i= ts predecessor for a long time, and it seems like there have been few subst= antial comments lately. > >Thus, this starts the two-week WG Last Call on "An Extension for EAP-Only = Authentication in IKEv2", . Please send any comments on the document to the mailing list.= Support, criticism, and suggestions for additions or changes are all appro= priate. At a minimum, I would like to see a handful of people say "I have r= ead the draft". Zero comments so far. Without more input from the WG, we might want to just= kill this draft, which would be quite sad. --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 ynir@checkpoint.com Mon May 3 03:22: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 1EBD928C100 for ; Mon, 3 May 2010 03:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_50=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 LeDSYxv1YMjN for ; Mon, 3 May 2010 03:22:28 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 3EA5728C10E for ; Mon, 3 May 2010 03:22:22 -0700 (PDT) X-CheckPoint: {4BDEB13B-1-1B201DC2-1FFFF} 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 o43AM5pp012911; Mon, 3 May 2010 13:22:05 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 3 May 2010 13:22:35 +0300 From: Yoav Nir To: "'Paul Hoffman'" , Yaron Sheffer , ipsec Date: Mon, 3 May 2010 13:22:34 +0300 Thread-Topic: [IPsec] IPsec HA problem statement Thread-Index: AcrqZjfygAd3OtFPQ7OioxoyR7olAwAQUIrg Message-ID: <006FEB08D9C6444AB014105C9AEB133FB37650C5DC@il-ex01.ad.checkpoint.com> References: <1271864821.6636.55.camel@yaronf-linux> <1272292059.2347.12.camel@yaronf-linux> 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] IPsec HA problem statement 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, 03 May 2010 10:22:30 -0000 Well, this draft is kind of a smorgasbord of issues, so once the issue that= bothers you is in there, you're not that interested any more.=20 I would like to post another draft with section 3.7 that I posted on the li= st on 25-Apr, and unless anyone has another issue that's not addressed, I t= hink we should proceed. It's important for such a draft to get input from as many vendors and open = source implementers as possible. As far as vendors are concerned, we have h= eard from Check Point and Cisco, and also from Safenet and Acme Packet. Based on marketing materials and wikis, I can see that at least Fortinet, J= uniper, Sonicwall and strongSwan support clusters in their products (strong= Swan's wiki even links to our draft), but no developer from any of those pr= ojects and products has spoken up yet. It's possible that all the issues th= ey've encountered are the same as the ones that are already listed in the d= raft, but it would still be great if we had heard it from them.=20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Monday, May 03, 2010 5:13 AM To: Yaron Sheffer; ipsec Subject: Re: [IPsec] IPsec HA problem statement At 5:27 PM +0300 4/26/10, Yaron Sheffer wrote: >There has been very little follow-on discussion on this draft, just a >few mails related to one proposed solution. So if you've read the draft >and think it's complete and good to go into WGLC, let us all know. If >some things are still missing, tell us which. Different vendors have >different views, and Yoav's problem statement may not cover them all. ...and there was no response to Yaron's plea. Have we lost steam? Is the draft really ready to go? --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 ynir@checkpoint.com Mon May 3 03:23: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 77CEA28C111 for ; Mon, 3 May 2010 03:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_05=-1.11, 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 PA2GAU1-Dmo7 for ; Mon, 3 May 2010 03:23:29 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 898B328C0EB for ; Mon, 3 May 2010 03:23:28 -0700 (PDT) X-CheckPoint: {4BDEB17E-0-1B201DC2-1FFFF} 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 o43ANCpp013149; Mon, 3 May 2010 13:23:12 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 3 May 2010 13:23:42 +0300 From: Yoav Nir To: "'Paul Hoffman'" , Yaron Sheffer , ipsec Date: Mon, 3 May 2010 13:23:41 +0300 Thread-Topic: [IPsec] IPsec HA problem statement Thread-Index: AcrqZjfygAd3OtFPQ7OioxoyR7olAwAQUIrg Message-ID: <006FEB08D9C6444AB014105C9AEB133FB37650C5DD@il-ex01.ad.checkpoint.com> References: <1271864821.6636.55.camel@yaronf-linux> <1272292059.2347.12.camel@yaronf-linux> 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] IPsec HA problem statement 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, 03 May 2010 10:23:30 -0000 Well, this draft is kind of a smorgasbord of issues, so once the issue that= bothers you is in there, you're not that interested any more.=20 I would like to post another draft with section 3.7 that I posted on the li= st on 25-Apr, and unless anyone has another issue that's not addressed, I t= hink we should proceed. It's important for such a draft to get input from as many vendors and open = source implementers as possible. As far as vendors are concerned, we have h= eard from Check Point and Cisco, and also from Safenet and Acme Packet. Based on marketing materials and wikis, I can see that at least Fortinet, J= uniper, Sonicwall and strongSwan support clusters in their products (strong= Swan's wiki(*) even links to our draft), but no developer from any of those= projects and products has spoken up yet. It's possible that all the issues= they've encountered are the same as the ones that are already listed in th= e draft, but it would still be great if we had heard it from them.=20 Yoav --------- (*)http://wiki.strongswan.org/wiki/1/HighAvailability -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Monday, May 03, 2010 5:13 AM To: Yaron Sheffer; ipsec Subject: Re: [IPsec] IPsec HA problem statement At 5:27 PM +0300 4/26/10, Yaron Sheffer wrote: >There has been very little follow-on discussion on this draft, just a >few mails related to one proposed solution. So if you've read the draft >and think it's complete and good to go into WGLC, let us all know. If >some things are still missing, tell us which. Different vendors have >different views, and Yoav's problem statement may not cover them all. ...and there was no response to Yaron's plea. Have we lost steam? Is the draft really ready to go? --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 ynir@checkpoint.com Mon May 3 03:24: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 3A2DC3A6C62 for ; Mon, 3 May 2010 03:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=0.731, 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 VtIVZSvwbKuQ for ; Mon, 3 May 2010 03:24:54 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 1C6513A6B05 for ; Mon, 3 May 2010 03:24:32 -0700 (PDT) X-CheckPoint: {4BDEB1BE-0-1B201DC2-1FFFF} 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 o43AOIpp013347 for ; Mon, 3 May 2010 13:24:18 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 3 May 2010 13:24:48 +0300 From: Yoav Nir To: ipsec Date: Mon, 3 May 2010 13:24:47 +0300 Thread-Topic: [IPsec] IPsec HA problem statement Thread-Index: AcrqZjfygAd3OtFPQ7OioxoyR7olAwAQUIrgAADPbmA= Message-ID: <006FEB08D9C6444AB014105C9AEB133FB37650C5DE@il-ex01.ad.checkpoint.com> References: <1271864821.6636.55.camel@yaronf-linux> <1272292059.2347.12.camel@yaronf-linux> <006FEB08D9C6444AB014105C9AEB133FB37650C5DC@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C5DC@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 Subject: Re: [IPsec] IPsec HA problem statement 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, 03 May 2010 10:24:55 -0000 Sorry for the dual post. Some mail client problem. From kivinen@iki.fi Mon May 3 05:40: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 8E6AC3A6C66 for ; Mon, 3 May 2010 05:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.732 X-Spam-Level: X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_50=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 ah7kuC1-IDIx for ; Mon, 3 May 2010 05:40:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7490E3A6CA9 for ; Mon, 3 May 2010 05:39:59 -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 o43CdYFj006711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2010 15:39:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o43CdXXK026740; Mon, 3 May 2010 15:39:33 +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: <19422.50181.199229.35876@fireball.kivinen.iki.fi> Date: Mon, 3 May 2010 15:39:33 +0300 From: Tero Kivinen To: Jitender Arora In-Reply-To: References: <1272187315.22380.46.camel@yaronf-linux> <19414.51287.786283.875147@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 13 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New 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, 03 May 2010 12:40:08 -0000 Jitender Arora writes: > Currently the IKEv2 does not allow the IKEv2 signaling and the > IPSEC traffic to go to different IP addresses, so this is the > problem this draft is trying to solve. > > The application where it is required now is the load balancing > of the IPSEC tunnels. Suppose in a network there are 10 > Security-Gateways and each of these security gateways can handle > 200000 IPSEC tunnels using the IKEv2 signaling. Now for this > network if we need a load balancer device which can balance the > tunnels across these security gateways, this load balancer > device will be handling the IKEv2 signaling coming from the 10 > *200000 clients which is 2 Million clients. In addition to > handling the IKEv2 signaling from these clients, this will also > have to handle the bidirectional IPSEC traffic between the > clients and security gateways. So in this case this load > balancing device needs to be very scalable and also high > performance box. This might not be practical. The easiest way is to use already standardized IKEV2 redirect and redirect the incoming flows from the single ip to one of those load balancing gateways in such way that IKEv2 SA and IPsec SA are on the same IP-address. If the SA needs to be moved because traffic distribution changes, and SA flows needs to be moved from one machine (IP-address) to another, you can use already standardized MOBIKE to change the termination point where the IKEv2 and IPsec SA flows are terminated (i.e. the outer IP-address) If you want to use same outer IP-address for all of the traffic even that is easy to do provided the cluster members follow certain rules. For example the SPIs (both ESP and IKEv2 SPIs) can use some bits to indicate which of the gateways is supposed to handle them. This way all the outer IP-addresses can be same but the load balancer in front of the actual gaweways can very quickly use simple hardware to forward packets to correct gateway. I do not really understand why the load balancer should be taking care of the IKEv2 traffic? Isn't it easier that each security gateway takes care of the IKEv2 traffic of the IPsec SAs associated with them. In IKEv2 the IKEv2 SA and IPsec SAs are very closely tied together, and running them on separate machines is very complicated (We just had long discussion about this on the list, i.e. what kind of failure models can happen and what cannot happen). > So to solve this problem, this draft proposes that if we can > allow the IPSEC traffic on the different addresses than the > IKEv2 signaling, the load balancer can handle only the IKEv2 > signaling and chose the right security gateway, and this > security gateway can tell the client to send the IPSEC traffic > directly to the security gateway without going through the Load > Balancer. I think mkaing single machine taking care of 2 million IKEv2 connections is going to be challenging, and it is much easier to make ten machines taking care of 200,000 clients in addition to taking care of the IPsec SAs associated with those clients. This way the load balancer has very easy job to just redirect the IKEv2 clients to suitable security gateway and then that gateway can take care of all the traffic. > This way the load balancer does not need to worry > about the IPSEC traffic and this will not put a lot of strain on > these boxes. It is possible to create system where the load balancer can very cheaply forward packets to real gateway based on for example the IPsec SPI (this does require coordination with the machines creating those IPsec SAs and allocating those SPIs). Same can be used for IKE SPIs too. > You are right, the IKEv2 SA and the CHILD SA will still be on > the same machine, but will be using the different addresses. So it is much better to use IKEv2 redirect and MOBIKE to change both IKEv2 SA and IPsec SA outer addresses either during the initial setup or after that. -- kivinen@iki.fi From dennis.kuegler@bsi.bund.de Mon May 3 08:17: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 E867D3A6D11 for ; Mon, 3 May 2010 08:17:57 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 TXDuQfY43qHP for ; Mon, 3 May 2010 08:17:57 -0700 (PDT) Received: from m2-bn.bund.de (m2-bn.bund.de [77.87.228.74]) by core3.amsl.com (Postfix) with ESMTP id BB1AA3A6D0E for ; Mon, 3 May 2010 08:17:53 -0700 (PDT) Received: from m2.mfw.bn.ivbb.bund.de (localhost [127.0.0.1]) by m2-bn.bund.de (8.13.8/8.13.8) with ESMTP id o43FHbXZ024480 for ; Mon, 3 May 2010 17:17:37 +0200 (CEST) Received: (from localhost) by m2.mfw.bn.ivbb.bund.de (MSCAN) id 4/m2.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Mon May 3 17:17:37 2010 X-Virus-Scanned: by amavisd-new at bsi.bund.de From: Dennis =?utf-8?q?K=C3=BCgler?= Organization: BSI Bonn To: ipsec@ietf.org Date: Mon, 3 May 2010 17:17:25 +0200 User-Agent: KMail/1.9.10 (enterprise35 20100401.1112527) MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201005031717.25794.dennis.kuegler@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.1.224; VDF: 7.10.7.20; host: sgasmtp2.bsi.de); id=12458-elfSOu Subject: [IPsec] Password-based authentication - new 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, 03 May 2010 15:17:58 -0000 The new draft describing the integration of PACE (Password Authenticated Connection Establishment) in IKEv2 has been posted to the I-D repository: http://www.ietf.org/id/draft-kuegler-ipsecme-pace-ikev2-00.txt I'm looking forward to receive your comments. Best regards, Dennis From yaronf.ietf@gmail.com Mon May 3 12:36: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 B69333A6AD5 for ; Mon, 3 May 2010 12:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_20=-0.74] 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 gA7M65cuSBc1 for ; Mon, 3 May 2010 12:36:29 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4B8C53A6863 for ; Mon, 3 May 2010 12:36:29 -0700 (PDT) Received: by wwi18 with SMTP id 18so541126wwi.31 for ; Mon, 03 May 2010 12:36:12 -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=QE4ospxqBUcdZo86Whle5QNwZISo1uh6Rlh6EqXm++8=; b=VmbdXPq2IIxoWSH7pprHAHo8xH/PZ9r8zSwvi39yebxK5Kbpb09LNLd+h40nU5ZiFi Ijb01j9F7wRfhhzUMq/e9vuy2rcEb7MRRTytyQ6p4sTtTNIQK+oYFe92dKZgqnvLAclL enmJILMRFD/Y4c63FdUfoTtjwwJ2EsBN+jW8c= 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=WxiQYZhtKN9HhvwjB3TkAyMK3MalROoaoW0cgXPSJOdCzqFNa0RCkCZpavzuLfhUKb nfGcHkV8v5I7YDYrC3utrRCVQGg6ipPiHCi5xdhDAoEfrnc/wx9M+1kRiNyCAk0y8ND+ F4PxPblxkRqtAk4GM0tTyGu0kvd2YOSj5LV/A= Received: by 10.227.141.79 with SMTP id l15mr94436wbu.57.1272915370965; Mon, 03 May 2010 12:36:10 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-18-85.red.bezeqint.net [79.181.18.85]) by mx.google.com with ESMTPS id r29sm43895291wbv.21.2010.05.03.12.36.04 (version=SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 12:36:06 -0700 (PDT) Message-ID: <4BDF25A2.4010709@gmail.com> Date: Mon, 03 May 2010 22:36:02 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Willi References: <1272878010.1762.77.camel@martin> In-Reply-To: <1272878010.1762.77.camel@martin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication) 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, 03 May 2010 19:36:30 -0000 Hi Martin, thanks for your comments. Some responses below. Yaron On 05/03/2010 12:13 PM, Martin Willi wrote: > Hi, > >> Thus, this starts the two-week WG Last Call on "An Extension for >> EAP-Only Authentication in IKEv2", >> . Please >> send any comments on the document to the mailing list. Support, >> criticism, and suggestions for additions or changes are all >> appropriate. At a minimum, I would like to see a handful of people say >> "I have read the draft". > > We have added experimental support for this draft to version 4.3.6 of > our strongSwan open source IKEv2 daemon. > The proverbial proof of the pudding... > I think the draft looks good from an implementors perspective, here some > comments: > > - Section 4 lists two requirements for EAP methods: mutual > authentication and key generation. As noted in section 6.3, an active > attacker can intercept plain EAP packets. I think it would be a good > idea to add a "dictionary-attack-resistant" property to the requirement > list. There are methods that have the other two properties, but are not > a good candidate for use with this draft. The widely deployed > EAP-MSCHAPv2 is such an example. Using it with the draft will highly > degrade the security of the IKEv2 protocol. I agree. > > - The example of using EAP-GSS with with Kerberos in section 2 to > replace KINK is probably not the best one for the reason above. Or is > this combination in the end any more secure than using IKEv2 PSK with > weak passwords? Yes, we need a better example. > > - What's the reason for not adding EAP-TLS to the list of save methods? > I think EAP-TLS is a perfect candidate. It might be questionable to use > TLS within IKEv2 at all, but there actually are higher level protocols > that exactly use this combination. EAP-SIM is another candidate probably > worth to mention, having very similar properties as EAP-AKA. EAP-TLS is mentioned right before the table - and could be added. The table is not meant to be all-inclusive. I think using EAP-TLS here is crazy in practice, and I'd love to hear more about the protocols that use this combination - and why. > > - Section 3: >> If the responder supports this notification, it omits the public key >> based AUTH payload and CERT payloads from message 4. > This might be misleading, as the responder can ignore this notify even > if it supports the extension. This would make sense if the selected EAP > method does not have the required properties. "May omit"? I think "supports" usually means "supports and actually feels like doing it." > > Best regards > Martin > > From yaronf.ietf@gmail.com Mon May 3 13:33: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 EA09728C276 for ; Mon, 3 May 2010 13:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_50=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 urwqnC8AsoEg for ; Mon, 3 May 2010 13:33:04 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id F2F283A6A45 for ; Mon, 3 May 2010 13:33:03 -0700 (PDT) Received: by fxm4 with SMTP id 4so2801405fxm.31 for ; Mon, 03 May 2010 13:32:46 -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=Z9WQRsE58jW4gmENKfJ5yqwYwKbK2NsAobXGYOsl3hc=; b=U6520lMu8GUuPoqR25UsGRgdgnb13z77f1rdXl5fKspTYNm32cb5cqAQ8AHvj35pbi BOJbktQgH57IusCU7n6dPuMJ4uUBrZUyKYO6BsVLZldOFuBLNLyleQN1PvCWUP0eKqLc 8d4u0fPGcNhQwQOgEhjSTVaiWjbNXJOluAZeU= 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=C4frN7QTX5+Cm9147qsbMScT+DLN77RSpJSWrBYLJ9LbAntCpY2iTTRL0Lt7WDDzDw /OEDN0ahPywoW6cLZCoQZxUEXkzv5JHGc9EZA1rXz5mYSpg7mKVTVOAUgzTgSn5gh0KH joKgIZzRyFSWi8FR6QaYb8ypSHCbCrY5CF7pg= Received: by 10.86.124.4 with SMTP id w4mr410403fgc.54.1272918765895; Mon, 03 May 2010 13:32:45 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-18-85.red.bezeqint.net [79.181.18.85]) by mx.google.com with ESMTPS id 12sm9051878fgg.4.2010.05.03.13.32.41 (version=SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 13:32:44 -0700 (PDT) Message-ID: <4BDF32E6.1060606@gmail.com> Date: Mon, 03 May 2010 23:32:38 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Yoav Nir References: <006FEB08D9C6444AB014105C9AEB133FB37650C5DB@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C5DB@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , 'Paul Hoffman' Subject: Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication) 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, 03 May 2010 20:33:06 -0000 Hi Yoav, please see some comments below. Thanks, Yaron On 05/03/2010 01:00 PM, Yoav Nir wrote: > Can't compete with Martin's "running code", but I have a few comments. Before that, the draft seems good, and easy to follow. I think developers who have never heard of the IPsec list should have no problem reading and implementing this correctly. Having said that, here's two comments. > > The introduction says this: > In some environments, requiring the deployment of PKI for just this > purpose can be counterproductive. Deploying new infrastructure can > be expensive, and it may weaken security by creating new > vulnerabilities. Mutually authenticating EAP methods alone can > provide a sufficient level of security in many circumstances, and > indeed, IEEE 802.11i uses EAP without any PKI for authenticating the > WLAN access points. > > The way this is phrased, it sounds like you need to deploy a full PKI for the gateway to show a certificate. Web servers do HTTPS without all this. They use either a relatively cheap commercial certificate or a self-signed certificate. The question is what value is there in the client verifying the certificate. With a self-signed certificate (or a corporate certificate) it's really a one-time leap of faith ("do you approve the fingerprint...") like with SSH servers. To do any better, you would need a full PKI with all computers pre-installed with the root trust anchor (or using TAMP). And if you have all that in place, you might as well issue certificates to users and skip EAP altogether. So I would rephrase it as: > > In order for the public key signature authentication of the gateway to be > effective, a deployment of PKI is required, which has to include > management of trust anchors on all supplicants. In many environments, > this is not realistic, and the security of the gateway public key is > the same as the security of a self-signed certificate. Mutually > authenticating EAP methods alone can... > I'm OK with this new text, but even if enterprise deployment of limited PKI is easy in theory, we know that in practice, many people eventually disable validation of server certs in the context of EAP (top of this screen shot: http://www.wegotserved.com/wp-content/uploads/2008/03/settings1.jpg). > > > Nowhere in the document does it say, why the EAP method needs to be key-generating. In fact, RFC 4306 says that it is recommended, but goes on to say what to do if the method is not key-generating. This document should make it clear why omitting the server-side signature changes things such that key generation has become crucial. The only thing I could find was section 6.1, which says: > It is important to note that the IKEv2 SA is not authenticated by > just running an EAP conversation: the crucial step is the AUTH > payload based on the EAP-generated key. Thus, EAP methods that do > not provide mutual authentication or establish a shared secret key > MUST NOT be used with the modifications presented in this document. > Why is it crucial? > This is a very good question: the AUTH payloads very indirectly bind the IKE shared secret with the actual EAP payloads. So the generated key may not be so crucial after all. But AFAIK, all modern EAP methods are key generating, so the question is interesting but theoretical. Also, for people that care about channel binding between IKE and the EAP method, the shared EAP key is used to enable the IKE peer to prove that it is either the EAP terminator, or at least trusted by it. So in this scenario the generated key is essential. > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Monday, May 03, 2010 5:14 AM > To: IPsecme WG > Subject: Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication) > > At 2:39 PM -0700 4/21/10, Paul Hoffman wrote: >> Greetings again. We have kicked around draft-ietf-ipsecme-eap-mutual and its predecessor for a long time, and it seems like there have been few substantial comments lately. >> >> Thus, this starts the two-week WG Last Call on "An Extension for EAP-Only Authentication in IKEv2",. Please send any comments on the document to the mailing list. Support, criticism, and suggestions for additions or changes are all appropriate. At a minimum, I would like to see a handful of people say "I have read the draft". > > Zero comments so far. Without more input from the WG, we might want to just kill this draft, which would be quite sad. > > --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 andreas.steffen@strongswan.org Mon May 3 13:43: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 4563228C2C7 for ; Mon, 3 May 2010 13:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_ORG=0.611] 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 xrK5KvpXXXbj for ; Mon, 3 May 2010 13:43:15 -0700 (PDT) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by core3.amsl.com (Postfix) with ESMTP id 5154728C2B9 for ; Mon, 3 May 2010 13:43:14 -0700 (PDT) Received: from 84-74-90-103.dclient.hispeed.ch ([84.74.90.103] helo=[10.10.0.20]) by strongswan.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O92SL-0001Vc-B2; Mon, 03 May 2010 22:41:33 +0200 Message-ID: <4BDF354C.80603@strongswan.org> Date: Mon, 03 May 2010 22:42:52 +0200 From: Andreas Steffen Organization: strongSwan Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Yaron Sheffer References: <1272878010.1762.77.camel@martin> <4BDF25A2.4010709@gmail.com> In-Reply-To: <4BDF25A2.4010709@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "Choinyambuu Sansar \(schoinya@hsr.ch\)" Subject: Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication) 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, 03 May 2010 20:43:18 -0000 Hi Yaron, I actually see a need for TLS-type IKEv2 EAP protocols in the context of IPsec-based Network Endpoint Assessment (NEA, RFC 5209). The recent proposal for an EAP-PT transport protocol http://tools.ietf.org/html/draft-hanna-nea-pt-eap-00 says in section 1. Introduction: ... EAP-TNC is designed to operate as an inner EAP [10] method over an EAP tunnel method that meets the Requirements for a Tunnel Based EAP Method [17]. PT-EAP therefore can operate over a number of existing access protocols that support EAP for authentication. Some examples of such access protocols include 802.1X [7] for wired and wireless networks and IKEv2 [15] for establishing VPNs over IP networks. This document defines a standard EAP inner method called EAP-TNC. It also shows how EAP-TNC may be carried over two existing EAP tunnel EAP methods: EAP-FAST [14] and EAP-TTLS [16]. Thus we have a requirement to use e.g. EAP-FAST or EAP-TTLS via IKEv2. Best regards Andreas On 03.05.2010 21:36, Yaron Sheffer wrote: >> >> - What's the reason for not adding EAP-TLS to the list of save methods? >> I think EAP-TLS is a perfect candidate. It might be questionable to use >> TLS within IKEv2 at all, but there actually are higher level protocols >> that exactly use this combination. EAP-SIM is another candidate probably >> worth to mention, having very similar properties as EAP-AKA. > > EAP-TLS is mentioned right before the table - and could be added. The > table is not meant to be all-inclusive. I think using EAP-TLS here is > crazy in practice, and I'd love to hear more about the protocols that > use this combination - and why. ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== From JArora@acmepacket.com Tue May 4 19:05: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 48FF73A6993 for ; Tue, 4 May 2010 19:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_50=0.001, 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 ckBBVT7EIfEw for ; Tue, 4 May 2010 19:04:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3DFD23A6947 for ; Tue, 4 May 2010 19:04:58 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 4 May 2010 22:04:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 4 May 2010 22:04:40 -0400 From: Jitender Arora To: Tero Kivinen Date: Tue, 4 May 2010 22:04:39 -0400 Thread-Topic: [IPsec] New draft posted Thread-Index: AcrqvcM9m5BOqxkrTF6onzPqzFHDdABN1/ag Message-ID: References: <1272187315.22380.46.camel@yaronf-linux> <19414.51287.786283.875147@fireball.kivinen.iki.fi> <19422.50181.199229.35876@fireball.kivinen.iki.fi> In-Reply-To: <19422.50181.199229.35876@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: multipart/alternative; boundary="_000_A8F897BE25922348AB562D74E6C686E41F48B2970Email_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New 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: Wed, 05 May 2010 02:05:00 -0000 --_000_A8F897BE25922348AB562D74E6C686E41F48B2970Email_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tero, My comments are inline. Thanks, Jitender -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Monday, May 03, 2010 8:40 AM To: Jitender Arora Cc: Yaron Sheffer; ipsec@ietf.org Subject: RE: [IPsec] New draft posted Jitender Arora writes: > Currently the IKEv2 does not allow the IKEv2 signaling and the > IPSEC traffic to go to different IP addresses, so this is the > problem this draft is trying to solve. > > The application where it is required now is the load balancing > of the IPSEC tunnels. Suppose in a network there are 10 > Security-Gateways and each of these security gateways can handle > 200000 IPSEC tunnels using the IKEv2 signaling. Now for this > network if we need a load balancer device which can balance the > tunnels across these security gateways, this load balancer > device will be handling the IKEv2 signaling coming from the 10 > *200000 clients which is 2 Million clients. In addition to > handling the IKEv2 signaling from these clients, this will also > have to handle the bidirectional IPSEC traffic between the > clients and security gateways. So in this case this load > balancing device needs to be very scalable and also high > performance box. This might not be practical. The easiest way is to use already standardized IKEV2 redirect and redirect the incoming flows from the single ip to one of those load balancing gateways in such way that IKEv2 SA and IPsec SA are on the same IP-address. If the SA needs to be moved because traffic distribution changes, and SA flows needs to be moved from one machine (IP-address) to another, you can use already standardized MOBIKE to change the termination point where the IKEv2 and IPsec SA flows are terminated (i.e. the outer IP-address) Jitender--> Currently we are using this approach (basically using the redir= ect and the Mobike). This is causing the following issues: 1. If the redirect message is handled by the Load Balancer, the load balanc= er needs to be IKEv2 aware and also it needs to know the IP addresses of th= e Security Gateways for which it is responsible. This can cause the perform= ance issues as the Load Balancer should not be application aware and should= do the load balancing based on the layer 3/layer 4 information. 2. If the Load Balancer passes this IKEv2 messages directly to the security= gateways using the layer 3 information, the security gateway will then hav= e to send the redirect to the client back through the LoadBalancer and tell= ing the client to talk to different address now. This again causes an extra= message exchange to achieve the load balancing. If you want to use same outer IP-address for all of the traffic even that is easy to do provided the cluster members follow certain rules. For example the SPIs (both ESP and IKEv2 SPIs) can use some bits to indicate which of the gateways is supposed to handle them. This way all the outer IP-addresses can be same but the load balancer in front of the actual gaweways can very quickly use simple hardware to forward packets to correct gateway. Jitender--> This can simply be done based on the layer3/layer4 information,= which is what we are planning to do. I do not really understand why the load balancer should be taking care of the IKEv2 traffic? Isn't it easier that each security gateway takes care of the IKEv2 traffic of the IPsec SAs associated with them. Jitender--> I think, I did not make this clear, the Load Balancer will not = take care of the IKEv2 traffic, it will just pass through the IKEv2 traffic= to the security gateways without handling them. But all the IKEv2 traffic = will have to go through this load balancer so that the IKEv2 signaling can = take place between the same addresses. In IKEv2 the IKEv2 SA and IPsec SAs are very closely tied together, and running them on separate machines is very complicated (We just had long discussion about this on the list, i.e. what kind of failure models can happen and what cannot happen). Jitender--> If this has been captured somewhere, can you please point us to= that link. > So to solve this problem, this draft proposes that if we can > allow the IPSEC traffic on the different addresses than the > IKEv2 signaling, the load balancer can handle only the IKEv2 > signaling and chose the right security gateway, and this > security gateway can tell the client to send the IPSEC traffic > directly to the security gateway without going through the Load > Balancer. I think mkaing single machine taking care of 2 million IKEv2 connections is going to be challenging, and it is much easier to make ten machines taking care of 200,000 clients in addition to taking care of the IPsec SAs associated with those clients. This way the load balancer has very easy job to just redirect the IKEv2 clients to suitable security gateway and then that gateway can take care of all the traffic. > This way the load balancer does not need to worry > about the IPSEC traffic and this will not put a lot of strain on > these boxes. It is possible to create system where the load balancer can very cheaply forward packets to real gateway based on for example the IPsec SPI (this does require coordination with the machines creating those IPsec SAs and allocating those SPIs). Same can be used for IKE SPIs too. > You are right, the IKEv2 SA and the CHILD SA will still be on > the same machine, but will be using the different addresses. So it is much better to use IKEv2 redirect and MOBIKE to change both IKEv2 SA and IPsec SA outer addresses either during the initial setup or after that. Jitender--> Please let me know if this makes sense. -- kivinen@iki.fi --_000_A8F897BE25922348AB562D74E6C686E41F48B2970Email_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tero,

 

    My comments are inline.

 

Thanks,

Jitender

 

-----Original Message-----
From: Tero Kivinen [mailto:kivinen@iki.fi]
Sent: Monday, May 03, 2010 8:40 AM
To: Jitender Arora
Cc: Yaron Sheffer; ipsec@ietf.org
Subject: RE: [IPsec] New draft posted

 

Jitender Arora writes:

>     Currently the IKEv2 does not allow the IKEv2 signaling and the

>     IPSEC traffic to go to different IP addresses, so this is the

>     problem this draft is trying to solve.

>

>     The application where it is required now is the load balancing

>     of the IPSEC tunnels. Suppose in a network there are 10

>     Security-Gateways and each of these security gateways can handle=

>     200000 IPSEC tunnels using the IKEv2 signaling. Now for this

>     network if we need a load balancer device which can balance the<= /span>

>     tunnels across these security gateways, this load balancer

>     device will be handling the IKEv2 signaling coming from the 10

>     *200000 clients which is 2 Million clients. In addition to

>     handling the IKEv2 signaling from these clients, this will also<= /span>

>     have to handle the bidirectional IPSEC traffic between the

>     clients and security gateways. So in this case this load<= /font>

>     balancing device needs to be very scalable and also high<= /font>

>     performance box. This might not be practical.

 

The easiest way is to use already standardized IKEV2 redirect and

redirect the incoming flows from the single ip to one of those load

balancing gateways in such way that IKEv2 SA and IPsec SA are on the

same IP-address.

 

If the SA needs to be moved because traffic distribution changes, and

SA flows needs to be moved from one machine (IP-address) to another,

you can use already standardized MOBIKE to change the termination

point where the IKEv2 and IPsec SA flows are terminated (i.e. the

outer IP-address)

 

Jitender--> Currently we are using this approach (basicall= y using the redirect and the Mobike).

This is causing the following issues= :

 

1. If the redirect message is handle= d by the Load Balancer, the load balancer needs to be IKEv2 aware and also it ne= eds to know the IP addresses of the Security Gateways for which it is responsib= le. This can cause the performance issues as the Load Balancer should not be ap= plication aware and should do the load balancing based on the layer 3/layer 4 informa= tion.

 

2. If the Load Balancer passes this = IKEv2 messages directly to the security gateways using the layer 3 information, t= he security gateway will then have to send the redirect to the client back thr= ough the LoadBalancer and telling the client to talk to different address now. T= his again causes an extra message exchange to achieve the load balancing.<= /o:p>

 

If you want to use same outer IP-address for all of the traffic even

that is easy to do provided the cluster members follow certain rules.=

For example the SPIs (both ESP and IKEv2 SPIs) can use some bits to<= /span>

indicate which of the gateways is supposed to handle them. This way

all the outer IP-addresses can be same but the load balancer in front

of the actual gaweways can very quickly use simple hardware to forward

packets to correct gateway.

 

Jitenderà This can simply be done based on= the layer3/layer4 information, which is what we are planning to do.<= /p>

 

I do not really understand why the load balancer should be taking care

of the IKEv2 traffic? Isn't it easier that each security gateway takes

care of the IKEv2 traffic of the IPsec SAs associated with them.

 

Jitenderà I think, I did not make this cle= ar, the Load Balancer will not take care of the IKEv2 traffic, it will just pass through the IKEv2 traffic to the security gateways without handling them. B= ut all the IKEv2 traffic will have to go through this load balancer so that th= e IKEv2 signaling can take place between the same addresses.

 

In IKEv2 the IKEv2 SA and IPsec SAs are very closely tied together,=

and running them on separate machines is very complicated (We just had

long discussion about this on the list, i.e. what kind of failure

models can happen and what cannot happen).

 

Jitender= à If this has been captured somewh= ere, can you please point us to that link.

 

>     So to solve this problem, this draft proposes that if we can

>     allow the IPSEC traffic on the different addresses than the

>     IKEv2 signaling, the load balancer can handle only the IKEv2

>     signaling and chose the right security gateway, and this<= /font>

>     security gateway can tell the client to send the IPSEC traffic

>     directly to the security gateway without going through the Load<= /span>

>     Balancer.

 

I think mkaing single machine taking care of 2 million IKEv2

connections is going to be challenging, and it is much easier to make=

ten machines taking care of 200,000 clients in addition to taking care

of the IPsec SAs associated with those clients. This way the load

balancer has very easy job to just redirect the IKEv2 clients to

suitable security gateway and then that gateway can take care of all

the traffic.

 

>     This way the load balancer does not need to worry<= /p>

>     about the IPSEC traffic and this will not put a lot of strain on=

>     these boxes.

 

It is possible to create system where the load balancer can very

cheaply forward packets to real gateway based on for example the IPsec

SPI (this does require coordination with the machines creating those=

IPsec SAs and allocating those SPIs). Same can be used for IKE SPIs

too.

 

>     You are right, the IKEv2 SA and the CHILD SA will still be on

>     the same machine, but will be using the different addresses.

 

So it is much better to use IKEv2 redirect and MOBIKE to change both

IKEv2 SA and IPsec SA outer addresses either during the initial setup<= /span>

or after that.

 

Jitenderà Please let me know if this makes= sense.

--

kivinen@iki.fi

--_000_A8F897BE25922348AB562D74E6C686E41F48B2970Email_-- From yaronf.ietf@gmail.com Sat May 8 13:55: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 013C43A684A for ; Sat, 8 May 2010 13:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 l4eJWtKglu1x for ; Sat, 8 May 2010 13:55:20 -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 D2D393A67F6 for ; Sat, 8 May 2010 13:55:19 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so825632fgb.13 for ; Sat, 08 May 2010 13:55: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=mPCACW/I4yVw/W4Fk9PXPkdVfi0jDUzBcV6TOT5Ziz8=; b=nZhS9w20oz9hUjvKlR71GbovQwTqxeJpWvrE8/U2A6qlLjkF94BYNf4dMaVXQsMGIV UxwleItyp2VxBGvzQUKSxLU5Bmz7oGoEQzZCMPB9mgeWlcwrW7QKRyN7GkTs2udXF0AV NzI9gpyPC+v/m+YQ39ObQD1PSjgHW22tnQUAk= 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=Id9VYKzffi7cH/pgj4HY3a4nQD3OQpjLJJOUtQI/ltY1tWNmLThDRMzLhtND3xcWVj 0uex6l8JwGMyASozoooqmh3oS4RmgbxKcRa22ENf6M1BAmXVZ40CSf4nMuBVo++XF6EW vN8JmVr0wNeL7QzM/Fj3uc/+zw7+PQTYg2mSo= Received: by 10.86.124.8 with SMTP id w8mr6555453fgc.8.1273352104654; Sat, 08 May 2010 13:55:04 -0700 (PDT) Received: from [192.168.0.72] (orchid1.bb.netvision.net.il [212.143.159.174]) by mx.google.com with ESMTPS id d4sm7609689fga.25.2010.05.08.13.55.00 (version=SSLv3 cipher=RC4-MD5); Sat, 08 May 2010 13:55:03 -0700 (PDT) Message-ID: <4BE5CFA1.3030105@gmail.com> Date: Sat, 08 May 2010 23:54:57 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] IESG DISCUSS re: IKEv2-bis and RFC 4307 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, 08 May 2010 20:55:21 -0000 Hi everyone, There is a DISCUSS position from an IESG member on the ikev2bis document that says: >The Gen-ART Review by Elwyn Davies on 4 May 2010 raised a question >that deserves consideration. Elwyn said: >> >> s3.3.4: The draft states that the list of mandatory to implement >> suites has been removed due to evolution going too fast. However >> there are effectively some mandatory to implement suites; they are >> listed in other documents. There should be a way of finding them >> so that users and implmenters can find them easily. >> >Inclusion of a informative reference seems reasonable. There could be >warning that the algorithm document is likely to be updated without >a corresponding update to the protocol. The RFC index will tell the >community when the algorithm document is revised. The previous WG chose not to put any reference to RFC 4307 into RFC 4306, so this would be a change. Having said that, adding a reference is not much of a change. Proposed wording for 3.3.4 would be: CURRENT: The specification of suites that MUST and SHOULD be supported for interoperability has been removed from this document because they are likely to change more rapidly than this document evolves. PROPOSED: The specification of suites that MUST and SHOULD be supported for interoperability is not included this document because they are likely to change more rapidly than this document evolves. At the time of publication of this document, [RFC 4307] specifies these suites, but note that it might be updated in the future, and other RFCs might specify different sets of suites. RFC 4307 would be listed as a normative reference. Please note that we are going one better than Elwyn's comment, in adding 4307 as a normative, rather than informational, reference. Is there any objection in the WG to this change? Thanks, Yaron From ynir@checkpoint.com Sat May 8 23:13: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 CD3B93A6884 for ; Sat, 8 May 2010 23:13:29 -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.600, BAYES_50=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 jAio5Jdfv33P for ; Sat, 8 May 2010 23:13:28 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id D3EA23A6845 for ; Sat, 8 May 2010 23:13:22 -0700 (PDT) X-CheckPoint: {4BE65FA1-0-1B201DC2-1FFFF} 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 o496D9pp002374; Sun, 9 May 2010 09:13:09 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 9 May 2010 09:13:39 +0300 From: Yoav Nir To: "'Yaron Sheffer'" , IPsecme WG Date: Sun, 9 May 2010 09:13:38 +0300 Thread-Topic: [IPsec] IESG DISCUSS re: IKEv2-bis and RFC 4307 Thread-Index: Acru8NU67f0VT61tRbmnA3ofst4GBgATatPw Message-ID: <006FEB08D9C6444AB014105C9AEB133FB37650C5FF@il-ex01.ad.checkpoint.com> References: <4BE5CFA1.3030105@gmail.com> In-Reply-To: <4BE5CFA1.3030105@gmail.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] IESG DISCUSS re: IKEv2-bis and RFC 4307 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, 09 May 2010 06:13:30 -0000 I'm fine with the change, and with the reference being either normative or = informative. I prefer informative, though. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Saturday, May 08, 2010 11:55 PM To: IPsecme WG Subject: [IPsec] IESG DISCUSS re: IKEv2-bis and RFC 4307 Hi everyone, There is a DISCUSS position from an IESG member on the ikev2bis document=20 that says: >The Gen-ART Review by Elwyn Davies on 4 May 2010 raised a question >that deserves consideration. Elwyn said: >> >> s3.3.4: The draft states that the list of mandatory to implement >> suites has been removed due to evolution going too fast. However >> there are effectively some mandatory to implement suites; they are >> listed in other documents. There should be a way of finding them >> so that users and implmenters can find them easily. >> >Inclusion of a informative reference seems reasonable. There could be >warning that the algorithm document is likely to be updated without >a corresponding update to the protocol. The RFC index will tell the >community when the algorithm document is revised. The previous WG chose not to put any reference to RFC 4307 into RFC=20 4306, so this would be a change. Having said that, adding a reference is=20 not much of a change. Proposed wording for 3.3.4 would be: CURRENT: The specification of suites that MUST and SHOULD be supported for interoperability has been removed from this document because they are likely to change more rapidly than this document evolves. PROPOSED: The specification of suites that MUST and SHOULD be supported for interoperability is not included this document because they are likely to change more rapidly than this document evolves. At the time of publication of this document, [RFC 4307] specifies these suites, but note that it might be updated in the future, and other RFCs might specify different sets of suites. RFC 4307 would be listed as a normative reference. Please note that we are going one better than Elwyn's comment, in adding=20 4307 as a normative, rather than informational, reference. Is there any=20 objection in the WG to this change? Thanks, Yaron _______________________________________________ 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 Sun May 9 07:44: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 DFB9E3A69E6 for ; Sun, 9 May 2010 07:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-1.452, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 0Qq5QxClEaCt for ; Sun, 9 May 2010 07:44:30 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 484A73A69F1 for ; Sun, 9 May 2010 07:44:30 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o49EiH1x081225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 9 May 2010 07:44:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C5FF@il-ex01.ad.checkpoint.com> References: <4BE5CFA1.3030105@gmail.com> <006FEB08D9C6444AB014105C9AEB133FB37650C5FF@il-ex01.ad.checkpoint.com> Date: Sun, 9 May 2010 07:44:16 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] IESG DISCUSS re: IKEv2-bis and RFC 4307 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, 09 May 2010 14:44:31 -0000 At 9:13 AM +0300 5/9/10, Yoav Nir wrote: >I'm fine with the change, and with the reference being either normative or informative. I prefer informative, though. +1 to being fine with either and preferring informative. --Paul Hoffman, Director --VPN Consortium From yaronf.ietf@gmail.com Sun May 9 13:46: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 3971C3A69C5 for ; Sun, 9 May 2010 13:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_20=-0.74] 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 KoLjfLaumCuR for ; Sun, 9 May 2010 13:46:52 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E7CD93A6856 for ; Sun, 9 May 2010 13:46:51 -0700 (PDT) Received: by fxm4 with SMTP id 4so2192921fxm.31 for ; Sun, 09 May 2010 13:46: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=w6lt9/sUFtPrN2indZpgCdflj1V3wN2XC5dpR/gXTwo=; b=xNXMyQIgjA4/wgUN52JR2X0vphYC9VqpdQu2lpIJW5Zgi/1hjPCknLTPShbuEsmj7g 3Adjul+Gr75iqN7taVpPbAPXMa7ckRm55GXCEuA6MS7FYpOnmsBg+yFcjDSaJVqyWlJD ni7Br6jSwxa2CBUCwA3XNZmUxtmvXM4hmSR9Y= 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=KnL3fXDfYbWBB3Lw3Yr7rUcfZMHdc/MQPOsW6dBFJy2RwlxHf3ClyFXqQYsbSXee2I NwUFsxMXqwyvlJRxOELTd6E3WLKOHL4YUIiI/6eBipu77m5xmZhCf8WgbLpFy2w6V+X0 319gai8xOBPeECKSiatgylxSnjN/trKdVygjE= Received: by 10.87.47.23 with SMTP id z23mr8223235fgj.28.1273437997055; Sun, 09 May 2010 13:46:37 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-53-201.red.bezeqint.net [79.181.53.201]) by mx.google.com with ESMTPS id 21sm8348882fkx.40.2010.05.09.13.46.35 (version=SSLv3 cipher=RC4-MD5); Sun, 09 May 2010 13:46:36 -0700 (PDT) Message-ID: <4BE71F2A.9090902@gmail.com> Date: Sun, 09 May 2010 23:46:34 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Yoav Nir References: <4BE5CFA1.3030105@gmail.com> <006FEB08D9C6444AB014105C9AEB133FB37650C5FF@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C5FF@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] IESG DISCUSS re: IKEv2-bis and RFC 4307 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, 09 May 2010 20:46:53 -0000 Hi Yoav, RFC 4306 is the main specification for IKEv2, and RFC 4307 provides details that are necessary to implement IKEv2 in an interoperable manner. So why do you think that an Informative reference is more appropriate here? The relevant background, FWIW, is http://www.ietf.org/iesg/statement/normative-informative.html. Thanks, Yaron On 05/09/2010 09:13 AM, Yoav Nir wrote: > I'm fine with the change, and with the reference being either normative or informative. I prefer informative, though. > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer > Sent: Saturday, May 08, 2010 11:55 PM > To: IPsecme WG > Subject: [IPsec] IESG DISCUSS re: IKEv2-bis and RFC 4307 > > Hi everyone, > > There is a DISCUSS position from an IESG member on the ikev2bis document > that says: > >> The Gen-ART Review by Elwyn Davies on 4 May 2010 raised a question >> that deserves consideration. Elwyn said: >>> >>> s3.3.4: The draft states that the list of mandatory to implement >>> suites has been removed due to evolution going too fast. However >>> there are effectively some mandatory to implement suites; they are >>> listed in other documents. There should be a way of finding them >>> so that users and implmenters can find them easily. >>> >> Inclusion of a informative reference seems reasonable. There could be >> warning that the algorithm document is likely to be updated without >> a corresponding update to the protocol. The RFC index will tell the >> community when the algorithm document is revised. > > The previous WG chose not to put any reference to RFC 4307 into RFC > 4306, so this would be a change. Having said that, adding a reference is > not much of a change. Proposed wording for 3.3.4 would be: > > CURRENT: > The specification of suites that MUST and SHOULD be supported for > interoperability has been removed from this document because they are > likely to change more rapidly than this document evolves. > > PROPOSED: > The specification of suites that MUST and SHOULD be supported for > interoperability is not included this document because they are > likely to change more rapidly than this document evolves. At > the time of publication of this document, [RFC 4307] specifies > these suites, but note that it might be updated in the future, and > other RFCs might specify different sets of suites. > > RFC 4307 would be listed as a normative reference. > > Please note that we are going one better than Elwyn's comment, in adding > 4307 as a normative, rather than informational, reference. Is there any > objection in the WG to this change? > > Thanks, > Yaron > > _______________________________________________ > 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 Sun May 9 14:13: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 DDE823A69DC for ; Sun, 9 May 2010 14:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.838 X-Spam-Level: X-Spam-Status: No, score=-0.838 tagged_above=-999 required=5 tests=[AWL=-1.392, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 6Yc+PVykAZXf for ; Sun, 9 May 2010 14:13:38 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 93D323A68E9 for ; Sun, 9 May 2010 14:13: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 hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o49LDD9i004426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 May 2010 14:13:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4BE71F2A.9090902@gmail.com> References: <4BE5CFA1.3030105@gmail.com> <006FEB08D9C6444AB014105C9AEB133FB37650C5FF@il-ex01.ad.checkpoint.com> <4BE71F2A.9090902@gmail.com> Date: Sun, 9 May 2010 14:13:09 -0700 To: Yaron Sheffer , Yoav Nir From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] IESG DISCUSS re: IKEv2-bis and RFC 4307 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, 09 May 2010 21:13:39 -0000 At 11:46 PM +0300 5/9/10, Yaron Sheffer wrote: >RFC 4306 is the main specification for IKEv2, and RFC 4307 provides details that are necessary to implement IKEv2 in an interoperable manner. So why do you think that an Informative reference is more appropriate here? > >The relevant background, FWIW, is http://www.ietf.org/iesg/statement/normative-informative.html. The information in RFC 4307 is not required in order to implement the protocol in RFC 4306. It is required to interoperate in the most general sense only, that is, to interoperate with partners with whom you do not have prior arrangements. Some can read RFC 4306 without RFC 4307 and make an implementation that will interoperate just fine between organizations that communicate about their crypto preferences. Thus, the information in 4307 is informative but, if it makes you happy to make it a normative reference, there is no problem with that. Note that Russ Housley has a valid reason for asking for the reference to 4307 to be informative: other security protocols such as S/MIME have their 4307-equivalents as informative references. --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Tue May 11 22:45:31 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 1800728C103; Tue, 11 May 2010 22:45:10 -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: <20100512054519.1800728C103@core3.amsl.com> Date: Tue, 11 May 2010 22:45:10 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsec-ha-03.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, 12 May 2010 05:45:34 -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 : IPsec High Availability and Load Sharing Problem Statement Author(s) : Y. Nir Filename : draft-ietf-ipsecme-ipsec-ha-03.txt Pages : 11 Date : 2010-05-11 This document describes a requirement from IKE and IPsec to allow for more scalable and available deployments for VPNs. It defines A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-03.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-ipsec-ha-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-11224433.I-D@ietf.org> --NextPart-- From martin@strongswan.org Wed May 12 00:46: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 ADB0C28C18F for ; Wed, 12 May 2010 00:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_ORG=0.611] 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 hALtGRvVUHxX for ; Wed, 12 May 2010 00:45:59 -0700 (PDT) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by core3.amsl.com (Postfix) with ESMTP id 7ACB928C103 for ; Wed, 12 May 2010 00:45:59 -0700 (PDT) Received: from 224-92.105-92.cust.bluewin.ch ([92.105.92.224] helo=[192.168.1.36]) by strongswan.org with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OC6c5-0007GN-Nz; Wed, 12 May 2010 09:44:17 +0200 From: Martin Willi To: Yoav Nir In-Reply-To: <655B076B-CB0F-4CCA-BC1E-951821DFF66C@checkpoint.com> References: <655B076B-CB0F-4CCA-BC1E-951821DFF66C@checkpoint.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 12 May 2010 09:45:43 +0200 Message-ID: <1273650343.1792.86.camel@martin> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec HA problem statement 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, 12 May 2010 07:46:00 -0000 Hi Yoav, > I have noticed that StrongSwan is [not] implementing clustering. Starting with the recently released 4.4.0, we provide an experimental clustering feature. Using the terms from the draft, it is a "Tight Completely Transparent Load Sharing Cluster". Most work has been done before the HA discussion started on the list, more details are available at [1]. > Have you had a chance to read it? Yes. > If so, I would very much appreciate it, if you could send a short > review to the list. The terminology is very useful. I used the term "node" for a single box in the cluster, but "member" is even better. For "Outbound SA Counters", we use an approach to "count, but not encrypt" the packets on the passive members. And our "Inbound SA Counters" are updated by verifying a packet from time to time. This approach has some requirements to the cluster setup and some problems not trivial to handle. So I'm not sure if we should mention it in the draft. > Mainly, they want to know if the document is ready, or whether there > are some issues that are not yet covered there. I think the draft is good to go. It provides a good overview and states the problems that need to be addressed. Best regards Martin [1]http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability From kivinen@iki.fi Wed May 12 04:41:43 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 81E053A6AA6 for ; Wed, 12 May 2010 04:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_50=0.001, SARE_MILLIONSOF=0.315] 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 y8hqQbC2GOti for ; Wed, 12 May 2010 04:41:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4828E3A6892 for ; Wed, 12 May 2010 04:41:41 -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 o4CBfOY8016290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 14:41:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o4CBfNbY006180; Wed, 12 May 2010 14:41:23 +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: <19434.37859.216575.687495@fireball.kivinen.iki.fi> Date: Wed, 12 May 2010 14:41:23 +0300 From: Tero Kivinen To: Jitender Arora In-Reply-To: References: <1272187315.22380.46.camel@yaronf-linux> <19414.51287.786283.875147@fireball.kivinen.iki.fi> <19422.50181.199229.35876@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 39 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New 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: Wed, 12 May 2010 11:41:43 -0000 Jitender Arora writes: > Jitender--> Currently we are using this approach (basically using > the redirect and the Mobike). > > This is causing the following issues: > > 1. If the redirect message is handled by the Load Balancer, the > load balancer needs to be IKEv2 aware and also it needs to know the > IP addresses of the Security Gateways for which it is responsible. > This can cause the performance issues as the Load Balancer should > not be application aware and should do the load balancing based on > the layer 3/layer 4 information. Load balancer by definition needs to know the devices where it is sharing the load to, so I do not consider that a problem. Also if the redirection is done in the IKE_SA_INIT phase then the application support required is very minimal. Also there is no need that the load balancer itself needs to be acting as application gateway, the published IP address for the IKEv2 connections can also be some other IP-address, i.e. that host does not need to be on the path of the real traffic. If this one host is only parsing IKE_SA_INIT packets and sending redirect backs any old 386 box you can find from your junk pile will be able to handle the traffic up to millions of clients (million clients, each connecting for example once per hour means there is 277 connection attempts per second, and any old box can receive 277 udp packets and send 277 udp replies back (in completely stateless manner)). > 2. If the Load Balancer passes this IKEv2 messages directly to the > security gateways using the layer 3 information, the security > gateway will then have to send the redirect to the client back > through the LoadBalancer and telling the client to talk to different > address now. This again causes an extra message exchange to achieve > the load balancing. Those extra messages only happen during the setup phase, and I would expect the load balancer can pass through those less than 300 messages per second. If it cannot, then you have much bigger problems when the real traffic starts to come in... > Jitender--> I think, I did not make this clear, the Load Balancer > will not take care of the IKEv2 traffic, it will just pass through > the IKEv2 traffic to the security gateways without handling them. > But all the IKEv2 traffic will have to go through this load balancer > so that the IKEv2 signaling can take place between the same > addresses. So if the load balancer cannot handle few hundred packets per second to passthrough then I think you should really consider replacing the hardware. For normal IPsec use the IKEv2 packet are not send periodically at all. There is 2+2 packets in the beginning. There might be one DPD exchange over IKEv2 SA when the ESP traffic stops, but after that there shouldn't be anything until the ESP traffic restarts. So there should very little IKEv2 traffic, and in normal case it is limited to about 6 packets in total over the whole lifetime of the IKEv2 SA. > In IKEv2 the IKEv2 SA and IPsec SAs are very closely tied together, > and running them on separate machines is very complicated (We just > had long discussion about this on the list, i.e. what kind of > failure models can happen and what cannot happen). > > Jitender--> If this has been captured somewhere, can you please > point us to that link. http://www.ietf.org/mail-archive/web/ipsec/current/msg06192.html -- kivinen@iki.fi From wwwrun@core3.amsl.com Wed May 12 11:38:56 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 E1CA328C339; Wed, 12 May 2010 11:38:56 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100512183856.E1CA328C339@core3.amsl.com> Date: Wed, 12 May 2010 11:38:56 -0700 (PDT) Cc: ipsecme mailing list , ipsecme chair , Internet Architecture Board , RFC Editor Subject: [IPsec] Document Action: 'Using Advanced Encryption Standard (AES) Counter Mode with IKEv2' 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: Wed, 12 May 2010 18:38:57 -0000 The IESG has approved the following document: - 'Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 ' as an Informational RFC This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-07.txt Technical Summary This document describes how to use the AES-CTR mode with an explicit initialization value to protect IKEv2 messages after keys are established. Working Group Summary This is the product of the IPSECME WG. Nothing worth noting: it got a small but adequate amount of review. Document Quality There are already a bunch of implementations based on developers guessing how to do this; to the best of our knowledge, those implementations match what is described in this document. Personnel Paul Hoffman (paul.hoffman@vpnc.org) is the document Shepherd. Sean Turner (turners@ieca.com) is the Responsible Area Director. The IANA Expert(s) for the registries in this document is Tero Kivinen (kivinen@iki.fi). RFC Editor Note 1) Please remove the following from the 1st page: Updates: RFC4307 (if approved) 2) Please move the reference to [RFC3686] in Section 7.2 to be the 1st reference in 7.1 (i.e., make it a normative reference). 3) Add the following as a new last paragraph in Section 1: Implementers need to carefully consider use of AES-CTR over the mandatory to implement algorithms in [RFC4307] because the performance improvements of AES-CTR are minimal in the context of IKEv2. Furthermore, these performance improvements may be offset by the Counter Mode-specific risk of a minor, hard to detect, implementation issue resulting in total security failure. 4) Please note that this is intended for informational - not standards as indicated in the header of the draft. From root@core3.amsl.com Thu May 13 07:45: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 891B83A6B6E; Thu, 13 May 2010 07:45: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: <20100513144501.891B83A6B6E@core3.amsl.com> Date: Thu, 13 May 2010 07:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-eap-mutual-02.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, 13 May 2010 14:45: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 : An Extension for EAP-Only Authentication in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-eap-mutual-02.txt Pages : 15 Date : 2010-05-13 IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-eap-mutual-02.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-eap-mutual-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-13074333.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Thu May 13 08:30: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 779F93A6919 for ; Thu, 13 May 2010 08:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[AWL=-1.197, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 a89ObIxQ25y3 for ; Thu, 13 May 2010 08:30:02 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 48CF73A67B6 for ; Thu, 13 May 2010 08:30: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 hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4DFTpOO024098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 May 2010 08:29:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 13 May 2010 08:29:50 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] WG Last Call for draft-ietf-ipsecme-eap-mutual 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, 13 May 2010 15:30:07 -0000 Greetings again. This begins a two-week Working Group Last Call on draft-ietf-ipsecme-eap-mutual. You can see the current version at . We want everyone in the WG to read the document and comment on it, even if the comment is "I support this" or "I am neutral on this". If you oppose moving the draft forwards, or you have technical changes you want made, please be explicit in your message. Feel free to start new threads if you are objecting or suggesting changes. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Thu May 13 08:32: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 5CDD33A695E for ; Thu, 13 May 2010 08:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 4lNVw1M6fZmk for ; Thu, 13 May 2010 08:32:35 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 907A03A67B6 for ; Thu, 13 May 2010 08:32:29 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4DFWI1K024204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 May 2010 08:32:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 13 May 2010 08:32:17 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] NEVER MIND: WG Last Call for draft-ietf-ipsecme-eap-mutual 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, 13 May 2010 15:32:36 -0000 That was the wrong message. This marks the *end* of the WG Last Call, although you are still free to comment on the new draft. I will forward this to Sean Turner for IETF Last Call soon. Bits of my brain seem missing... --Paul Hoffman, Director --VPN Consortium From sandeepkampati@huawei.com Thu May 13 20:41: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 DCAAF3A6908 for ; Thu, 13 May 2010 20:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 oK2ex2vi45yn for ; Thu, 13 May 2010 20:41:27 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E023D3A6862 for ; Thu, 13 May 2010 20:41:26 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2E00LTF4WIBZ@szxga03-in.huawei.com> for ipsec@ietf.org; Fri, 14 May 2010 11:41:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2E007ZJ4WI3K@szxga03-in.huawei.com> for ipsec@ietf.org; Fri, 14 May 2010 11:41:06 +0800 (CST) Received: from BLRNSHTIPL5NC ([10.18.1.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2E00LHX4WI0W@szxml06-in.huawei.com> for ipsec@ietf.org; Fri, 14 May 2010 11:41:06 +0800 (CST) Date: Fri, 14 May 2010 09:11:05 +0530 From: "sandeep.kampati" To: ipsec@ietf.org Message-id: <000d01caf317$48b10ac0$2301120a@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: multipart/alternative; boundary="Boundary_(ID_EORd1IFemtysBYKNvMOaHw)" Thread-index: AcrzF0grC3VGWc0lSsiZc6xkEajkfw== Subject: [IPsec] for Mode-CFG & XAuth what is better plugin AAA server or LDAP 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, 14 May 2010 03:41:28 -0000 This is a multi-part message in MIME format. --Boundary_(ID_EORd1IFemtysBYKNvMOaHw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT what is the better plug-in (AAA or LDAP ) for Mode-CFG server & why ? what is the better plug-in for X-auth server & why ? --Boundary_(ID_EORd1IFemtysBYKNvMOaHw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

what is the better plug-in (AAA or LDAP ) for Mode-CFG server & why ?


what is the better plug-in  for X-auth server & why ?

 

 

--Boundary_(ID_EORd1IFemtysBYKNvMOaHw)-- From yaronf.ietf@gmail.com Fri May 14 22:41: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 6D00A3A67EF for ; Fri, 14 May 2010 22:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, J_CHICKENPOX_93=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 6a3jJq6+uCqn for ; Fri, 14 May 2010 22:41:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A34E33A67E5 for ; Fri, 14 May 2010 22:41:08 -0700 (PDT) Received: by wwb28 with SMTP id 28so1259875wwb.31 for ; Fri, 14 May 2010 22:40: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:subject:content-type; bh=yLd//sg21Q4XtQGicpigs+2BFezRFhnWICeS5a8lqho=; b=Vi7XEI31ulrYY/XeJoo4KCQ8uxwmoFXv3GLnQ89AwdIzlZTwSoJ948NqAKycNHjEid KXs+Z40at+NsAkeKxV+8tgpIHxyAx5idWdKunUdkb7k5d51313AiblNTsv5OnRXAEY71 bPuAR1oujqFtKQYmqC4LGMXsWASRmNhCtoo9s= 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=MnTQVXFUa/2gnYZOaGUndy51do9LFGE4iY68038S1i559/5tSwYWzQxpuTZKprPiLn eCaVKYZCzeCp4t0rMjEfPLOFM9jeuRFNqCUdnIajdm/VtirlSz7hr15GIcQvcfu5t/+i gRG9dk1fsGQWtGVy6C9/dyA5hFs3vbAqS6Q/o= Received: by 10.227.156.139 with SMTP id x11mr2079671wbw.104.1273902055630; Fri, 14 May 2010 22:40:55 -0700 (PDT) Received: from [10.0.0.2] ([109.64.46.151]) by mx.google.com with ESMTPS id u36sm21871445wbv.12.2010.05.14.22.40.53 (version=SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 22:40:54 -0700 (PDT) Message-ID: <4BEE33E4.8080908@gmail.com> Date: Sat, 15 May 2010 08:40:52 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG Content-Type: multipart/mixed; boundary="------------040109000802070708040506" Subject: [IPsec] Three new IPsec+RoHC RFCs just published 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, 15 May 2010 05:41:16 -0000 This is a multi-part message in MIME format. --------------040109000802070708040506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI: RFC 5856, 5857, 5858. Thanks, Yaron --------------040109000802070708040506 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Delivered-To: yaronf.ietf@gmail.com Received: by 10.216.234.25 with SMTP id r25cs207352weq; Fri, 14 May 2010 16:10:06 -0700 (PDT) Received: by 10.142.247.33 with SMTP id u33mr1234206wfh.44.1273878605394; Fri, 14 May 2010 16:10:05 -0700 (PDT) Return-Path: Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id 34si4014077pzk.101.2010.05.14.16.10.04; Fri, 14 May 2010 16:10:05 -0700 (PDT) Received-SPF: pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=ietf-announce-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB09C28C112; Fri, 14 May 2010 16:08:01 -0700 (PDT) X-Original-To: ietf-announce@core3.amsl.com Delivered-To: ietf-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE933A68F6; Fri, 14 May 2010 16:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 0GE1OAlDm4hL; Fri, 14 May 2010 16:07:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 659783A68E3; Fri, 14 May 2010 16:07:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B861AE0685; Fri, 14 May 2010 16:07:50 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5858 on IPsec Extensions to Support Robust Header Compression over IPsec From: rfc-editor@rfc-editor.org Message-Id: <20100514230750.B861AE0685@rfc-editor.org> Date: Fri, 14 May 2010 16:07:50 -0700 (PDT) Cc: rohc@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5858 Title: IPsec Extensions to Support Robust Header Compression over IPsec Author: E. Ertekin, C. Christou, C. Bormann Status: Standards Track Stream: IETF Date: May 2010 Mailbox: ertekin_emre@bah.com, christou_chris@bah.com, cabo@tzi.org Pages: 15 Characters: 31539 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rohc-ipsec-extensions-hcoipsec-08.txt URL: http://www.rfc-editor.org/rfc/rfc5858.txt Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC with IPsec, extensions to the Security Policy Database (SPD) and Security Association Database (SAD) are required. This document describes the IPsec extensions required to support ROHCoIPsec. [STANDARDS TRACK] This document is a product of the Robust Header Compression Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------040109000802070708040506 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Delivered-To: yaronf.ietf@gmail.com Received: by 10.216.234.25 with SMTP id r25cs207340weq; Fri, 14 May 2010 16:09:49 -0700 (PDT) Received: by 10.142.207.19 with SMTP id e19mr1249832wfg.186.1273878589086; Fri, 14 May 2010 16:09:49 -0700 (PDT) Return-Path: Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id 34si4014077pzk.101.2010.05.14.16.09.48; Fri, 14 May 2010 16:09:49 -0700 (PDT) Received-SPF: pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=ietf-announce-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990213A6BB3; Fri, 14 May 2010 16:07:30 -0700 (PDT) X-Original-To: ietf-announce@core3.amsl.com Delivered-To: ietf-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F423A68AB; Fri, 14 May 2010 16:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 boFdbAEYf6MG; Fri, 14 May 2010 16:07: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 B72703A68F6; Fri, 14 May 2010 16:07:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1555AE0674; Fri, 14 May 2010 16:07:19 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5857 on IKEv2 Extensions to Support Robust Header Compression over IPsec From: rfc-editor@rfc-editor.org Message-Id: <20100514230719.1555AE0674@rfc-editor.org> Date: Fri, 14 May 2010 16:07:19 -0700 (PDT) Cc: rohc@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5857 Title: IKEv2 Extensions to Support Robust Header Compression over IPsec Author: E. Ertekin, C. Christou, R. Jasani, T. Kivinen, C. Bormann Status: Standards Track Stream: IETF Date: May 2010 Mailbox: ertekin_emre@bah.com, christou_chris@bah.com, ro@breakcheck.com, kivinen@iki.fi, cabo@tzi.org Pages: 13 Characters: 27063 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rohc-ikev2-extensions-hcoipsec-12.txt URL: http://www.rfc-editor.org/rfc/rfc5857.txt In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints. Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs). [STANDARDS TRACK] This document is a product of the Robust Header Compression Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------040109000802070708040506 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Delivered-To: yaronf.ietf@gmail.com Received: by 10.216.234.25 with SMTP id r25cs207261weq; Fri, 14 May 2010 16:07:52 -0700 (PDT) Received: by 10.143.154.27 with SMTP id g27mr1090747wfo.333.1273878470850; Fri, 14 May 2010 16:07:50 -0700 (PDT) Return-Path: Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id 34si3933430pzk.67.2010.05.14.16.07.50; Fri, 14 May 2010 16:07:50 -0700 (PDT) Received-SPF: pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=ietf-announce-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609673A6B4C; Fri, 14 May 2010 16:07:19 -0700 (PDT) X-Original-To: ietf-announce@core3.amsl.com Delivered-To: ietf-announce@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACB63A68EA; Fri, 14 May 2010 16:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_50=0.001, 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 T1mFNraukrIB; Fri, 14 May 2010 16:07:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 00E483A68AB; Fri, 14 May 2010 16:07:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5048EE062C; Fri, 14 May 2010 16:07:07 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5856 on Integration of Robust Header Compression over IPsec Security Associations From: rfc-editor@rfc-editor.org Message-Id: <20100514230707.5048EE062C@rfc-editor.org> Date: Fri, 14 May 2010 16:07:07 -0700 (PDT) Cc: rohc@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5856 Title: Integration of Robust Header Compression over IPsec Security Associations Author: E. Ertekin, R. Jasani, C. Christou, C. Bormann Status: Informational Stream: IETF Date: May 2010 Mailbox: ertekin_emre@bah.com, ro@breakcheck.com, christou_chris@bah.com, cabo@tzi.org Pages: 15 Characters: 34548 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rohc-hcoipsec-13.txt URL: http://www.rfc-editor.org/rfc/rfc5856.txt IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Robust Header Compression Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------040109000802070708040506-- From yaronf.ietf@gmail.com Sun May 16 05:54: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 596BE3A6A36 for ; Sun, 16 May 2010 05:54:15 -0700 (PDT) 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] 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 YfpNdsv6VeeT for ; Sun, 16 May 2010 05:54:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 292963A6A33 for ; Sun, 16 May 2010 05:54:14 -0700 (PDT) Received: by wyb42 with SMTP id 42so1966209wyb.31 for ; Sun, 16 May 2010 05:54:01 -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=C64Mfe9kG5gOjhSXemKm/RtWhRRamfA/CWQqihhHU5A=; b=opXgj0NOhymBpt8TO1t723rd6U8G/GFHAwSNkYTCUo7JV8EfNILMVOG0LrnEqRbCLW 9jUt96S0DI6sExSgwYc7/Vtv2hrO2ptCwatsnOzSFz5/y3rAhBQWKaBPFbFwoX1qHSzj 041Yxn3L1qDeBRrLPRmXtwNUOoX4jztyx0BhI= 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=E89jav3WNxU2mSZOgojDZdczzYrOi2L9fAImXPG08cE/HDrI8kv5FL8BbGKlGhTf86 x19LmE9j8XWt+96lALfeM4FoNYdXrzVis4POg2B40eKX7VzDwuvHICCVjoC33bOt2HXd JoRHoLd0l3G0qIbNEmqqJ0y9GmvF4jgJoUeWE= Received: by 10.227.135.203 with SMTP id o11mr3047642wbt.229.1274014441179; Sun, 16 May 2010 05:54:01 -0700 (PDT) Received: from [10.0.0.2] ([109.64.46.151]) by mx.google.com with ESMTPS id p29sm19249057wbe.22.2010.05.16.05.53.59 (version=SSLv3 cipher=RC4-MD5); Sun, 16 May 2010 05:54:00 -0700 (PDT) Message-ID: <4BEFEAE6.2060700@gmail.com> Date: Sun, 16 May 2010 15:53:58 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 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, 16 May 2010 12:54:15 -0000 This is to begin a 2 week working group last call for draft-ietf-ipsecme-ipsec-ha-03 (http://tools.ietf.org/html/draft-ietf-ipsecme-ipsec-ha-03). The target status for this document is Informational. Please send your comments to the ipsec list by May 30, 2010, as follow-ups to this message. Brief comments of the form: "I have read this draft and it looks fine" are also welcome. Quick heads up: this is a requirements definition draft. Once we have determined consensus around it, we would like to move forward with solutions. Individual solution drafts are welcome as usual, but we would like to establish at some point a design team to hash out a common solution document. Let us know by private mail if you're interested. Thanks, Yaron From paul.hoffman@vpnc.org Mon May 17 07:44: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 992783A6BD5 for ; Mon, 17 May 2010 07:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 E82-OWnhH7nz for ; Mon, 17 May 2010 07:44:15 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 65AE328C0EB for ; Mon, 17 May 2010 07:43:04 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HEgtkV017298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 May 2010 07:42:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 17 May 2010 07:42:50 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Beginning the PAKE selection process 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, 17 May 2010 14:44:16 -0000 Greetings again. This WG is chartered to "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 needs to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. As we discussed earlier, each WG member needs to come up with their own criteria for making such a choice. Dan Harkins has proposed a set of guidelines that individuals might use when choosing; see . So far, three protocols have been proposed to the WG: - - - In addition, one more draft was presented to the WG: . However the Augmented PAKE draft does not specify how it would be integrated into IKEv2. Note that more proposals might be made as we discuss; such proposals will hopefully be accompanied by Internet Drafts that show both the crypto and how it would be integrated into IKEv2. To start off this conversation, I propose that people start threads on the individual drafts, saying which positive and negative criteria they think apply to each. I also propose that replying to this message, or starting a thread that is supposedly about all four proposals but only focuses on one, is not going to help much. Of course, the authors of the four drafts are welcome to say why they think their proposal meets an optimum set of criteria, and to clarify parts of their proposals as others comment. Obviously these are all initial drafts, and the WG will have ample opportunity to improve the selected proposal later in the process. For now, please focus on the relative advantages and disadvantages (based on your personal criteria) of each of the proposals. --Paul Hoffman, Director --VPN Consortium From tjcarlin@iol.unh.edu Mon May 17 08:10: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 ACDF13A68CD for ; Mon, 17 May 2010 08:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[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 pJYlLjwtwzbg for ; Mon, 17 May 2010 08:10:54 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by core3.amsl.com (Postfix) with SMTP id A67883A6A43 for ; Mon, 17 May 2010 08:10:51 -0700 (PDT) Received: from source ([132.177.123.84]) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKS/Fcc/a8C04T5IB4Ihis3H2d5cRyWk1h@postini.com; Mon, 17 May 2010 08:10:44 PDT Received: from patriot.iol.unh.edu (patriot.iol.unh.edu [132.177.118.220]) by postal.iol.unh.edu (Postfix) with ESMTP id EA6631D9136; Mon, 17 May 2010 11:10:41 -0400 (EDT) From: Timothy Carlin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 May 2010 11:10:41 -0400 To: IPsecme WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [IPsec] IPsec SGW PMTU 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, 17 May 2010 15:10:57 -0000 Hello, A question has come up regarding the interpretation of RFC 4301 and IPv6 = Path MTU Discovery for Security Gateway Devices. We would appreciate = any insight anyone can offer. Section 8.2.1 indicates that the SG should map the header information = from the payload in a received (inbound) ICMPv6 Packet Too Big message = to an SA. Then, when another outbound packet is received that should be = tunneled through that SA, it should drop the packet, and propagate the = PMTU information through a synthesized PTB message. This seems to be = the only option for IPv6. Section 6 states: "The discussion in this section applies to ICMPv6 as = well as to ICMPv4." Section 6.1.1 gives two possibilities for processing, the second case = refers to Section 8.2.1, while the first case states: "If the = implementation applies fragmentation on the ciphertext side of the = boundary, then the accepted PMTU information is passed to the forwarding = module (outside of the IPsec implementation), which uses it to manage = outbound packet fragmentation" The question is: Does this statement apply to both IPv4 and IPv6, or = does it only apply to IPv4/ICMPv4? Section 8.2.1 seems to imply that it = would not apply to IPv6, meaning PTMU information should always be = propagated in IPv6, however section 6 seems to state that it applies to = both, and the implementation may choose to fragment. Thanks for your time, Tim Carlin ---- Timothy Carlin InterOperability Laboratory University of New Hampshire +1-603-862-1224 tjcarlin@iol.unh.edu From wwwrun@core3.amsl.com Mon May 17 12:38:46 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 E8E1C3A6877; Mon, 17 May 2010 12:38:46 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100517193846.E8E1C3A6877@core3.amsl.com> Date: Mon, 17 May 2010 12:38:46 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] Last Call: draft-ietf-ipsecme-eap-mutual (An Extension for EAP-Only Authentication in 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: Mon, 17 May 2010 19:38:47 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'An Extension for EAP-Only Authentication in 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-05-31. 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-eap-mutual-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19678&rfc_flag=0 From root@core3.amsl.com Mon May 17 13:45: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 4A74B3A6A0A; Mon, 17 May 2010 13:45:02 -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: <20100517204502.4A74B3A6A0A@core3.amsl.com> Date: Mon, 17 May 2010 13:45:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-11.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, 17 May 2010 20:45: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-11.txt Pages : 130 Date : 2010-5-17 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-11.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-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-5-17133540.I-D@ietf.org> --NextPart-- From turners@ieca.com Mon May 17 14:07: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 677993A6B02 for ; Mon, 17 May 2010 14:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, 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 BLr9J8jsPY+c for ; Mon, 17 May 2010 14:07:16 -0700 (PDT) Received: from smtp115.biz.mail.re2.yahoo.com (smtp115.biz.mail.re2.yahoo.com [66.196.116.35]) by core3.amsl.com (Postfix) with SMTP id 0B94D28C104 for ; Mon, 17 May 2010 14:07:12 -0700 (PDT) Received: (qmail 34164 invoked from network); 17 May 2010 21:07:02 -0000 Received: from thunderfish.local (turners@71.191.0.118 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 17 May 2010 14:07:02 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: _0USU9MVM1nw_h7uBHWRX_5qQ7SDwyXehO09wmdhikfHq4jaEacnILA01MzOpfDcSyCFS9rj3P406kQiokUbQCSBEWniEmCRc8m9bic__DaUic3vZzcm684x0zJZ2CGyTp_yyD82mQv5_m6d.0SWha9wvTi4MkpmzMHXl4kB6dc_gR2VNppgZPmmpPNa5GoRyZnveFg5ohmm85wxqUkJiHEdCR21lhSKYtjmTW_sL.s_BURnmw3CEa0hl5M68r15SpMjEzpnlvu.gNCIVnYPtcwGH8Y51HEqe4vNXSXPmqZoOKUwv9.ggRinng3n_ZQOAp7H35R4JgsDhInGsfnDcixfb8OJzyhBBQZCU7majDfNx1m9.Hh2N1MGiz0ZuyRWEeoTTBavsGFLyYOlylDAyYSaf.8KkEzp4BxcNTlgcTpFUUgZtTBWkFyeVRzm8REk_l_78xQ.YHj4FA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BF1AFF5.9080301@ieca.com> Date: Mon, 17 May 2010 17:07:01 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: ipsec@ietf.org References: <20100517204502.4A74B3A6A0A@core3.amsl.com> In-Reply-To: <20100517204502.4A74B3A6A0A@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-ikev2bis-11.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, 17 May 2010 21:07:17 -0000 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 : Internet Key Exchange Protocol: IKEv2 > Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen > Filename : draft-ietf-ipsecme-ikev2bis-11.txt > Pages : 130 > Date : 2010-5-17 > > 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-11.txt Note that during this update we considered the following errata: http://www.rfc-editor.org/errata_search.php?eid=1671 http://www.rfc-editor.org/errata_search.php?eid=1672 http://www.rfc-editor.org/errata_search.php?eid=2190 http://www.rfc-editor.org/errata_search.php?eid=2191 http://www.rfc-editor.org/errata_search.php?eid=2192 http://www.rfc-editor.org/errata_search.php?eid=2193 http://www.rfc-editor.org/errata_search.php?eid=2194 http://www.rfc-editor.org/errata_search.php?eid=2195 http://www.rfc-editor.org/errata_search.php?eid=2196 1671, 1672, and 2196 were already reworded in ikev2bis. 2190 is not needed as it's covered in the next paragraph. No one has reported problems with 2191, 2192, 2193, or 2194. 2195 seems reasonable, but there's been no discussion. At this point, we believe there's no action required on these. Please let me know very soon whether you see a problem with this course of action. spt From paul.hoffman@vpnc.org Mon May 17 14: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 3EF393A6A65 for ; Mon, 17 May 2010 14:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-1.119, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 GbkiQ659eNxH for ; Mon, 17 May 2010 14:39:38 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 586423A67AE for ; Mon, 17 May 2010 14:39: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 hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HLdPLd045164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 14:39:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4BF1AFF5.9080301@ieca.com> References: <20100517204502.4A74B3A6A0A@core3.amsl.com> <4BF1AFF5.9080301@ieca.com> Date: Mon, 17 May 2010 14:39:24 -0700 To: Sean Turner , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Open IKEv2 errata 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, 17 May 2010 21:39:39 -0000 At 5:07 PM -0400 5/17/10, Sean Turner wrote: >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 : Internet Key Exchange Protocol: IKEv2 >> Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen >> Filename : draft-ietf-ipsecme-ikev2bis-11.txt >> Pages : 130 >> Date : 2010-5-17 >> >>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-11.txt > >Note that during this update we considered the following errata: >http://www.rfc-editor.org/errata_search.php?eid=1671 >http://www.rfc-editor.org/errata_search.php?eid=1672 >http://www.rfc-editor.org/errata_search.php?eid=2190 >http://www.rfc-editor.org/errata_search.php?eid=2191 >http://www.rfc-editor.org/errata_search.php?eid=2192 >http://www.rfc-editor.org/errata_search.php?eid=2193 >http://www.rfc-editor.org/errata_search.php?eid=2194 >http://www.rfc-editor.org/errata_search.php?eid=2195 >http://www.rfc-editor.org/errata_search.php?eid=2196 > >1671, 1672, and 2196 were already reworded in ikev2bis. > >2190 is not needed as it's covered in the next paragraph. > >No one has reported problems with 2191, 2192, 2193, or 2194. > >2195 seems reasonable, but there's been no discussion. > >At this point, we believe there's no action required on these. Please let me know very soon whether you see a problem with this course of action. In specific, it would be good if the pickier folks on this list to look at 2195 and see if this is really just a clarification or is a change that limits something we don't want to limit. Comments on any of the others is welcome too. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon May 17 14:45: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 6F5303A6A65 for ; Mon, 17 May 2010 14:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 BJ317BgnZI6q for ; Mon, 17 May 2010 14:45:10 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9967A3A680A for ; Mon, 17 May 2010 14:45:10 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4HLj1jK045414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 May 2010 14:45:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100517204502.4A74B3A6A0A@core3.amsl.com> References: <20100517204502.4A74B3A6A0A@core3.amsl.com> Date: Mon, 17 May 2010 14:44:26 -0700 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-11.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, 17 May 2010 21:45:11 -0000 At 1:45 PM -0700 5/17/10, 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 : Internet Key Exchange Protocol: IKEv2 > Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen > Filename : draft-ietf-ipsecme-ikev2bis-11.txt > Pages : 130 > Date : 2010-5-17 > >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-11.txt The change list for this draft is: D.18. Changes from draft-ietf-ipsecme-ikev2bis-10 to draft-ietf-ipsecme-ikev2bis-11 Changes made during IESG review. In 1.7, changed "The clarifications are mostly based on [Clarif]" to "Many of the clarifications are based on [Clarif]". Added to 1.7: The small number of technical changes listed here are not expected to affect RFC 4306 implementations that have already been deployed at the time of publication of this document. Added to 3.3.4: At the time of publication of this document, [RFC4307] specifies these suites, but note that it might be updated in the future, and other RFCs might specify different sets of suites. In 8.1, added normative references for [HTTP], [RFC4307], and [URLS]. Editorial: changed "elliptical curve" to "elliptic curve". These were mostly to deal with requests from IESG members, and we should know shortly if they made the last one happy. --Paul Hoffman, Director --VPN Consortium From yaronf.ietf@gmail.com Tue May 18 03:24: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 1359228C164 for ; Tue, 18 May 2010 03:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 FJNwTH+uRINj for ; Tue, 18 May 2010 03:24:51 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9FD243A6C4D for ; Tue, 18 May 2010 03:22:34 -0700 (PDT) Received: by wyi11 with SMTP id 11so11397wyi.31 for ; Tue, 18 May 2010 03:22:23 -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=/J7AIfEZjlADcU0+Bcl+0Fkki41hHbmA7XcmumL4rvM=; b=GypbwLU9GauP6slYSu2b4Lm7ggsmASTuMMvytVZAHL17YepqGy2kRgukh2GJFDmEfQ YEfmXJ0/4jLAZ/8R1WbyXqALol90SQLK65eZSXZE+XwTjLu1cWGGbwULJcEE/hyFUCXG 2LQAI8oMf9UkH+qTFtv2B11rCOA6V9gJ3PaKc= 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=kukWke8q8FfPla6LwyznavGj3a3KZ4Jo1dP3cl9O686ju7C+KB8Vwt6TYqlbqX/LGf s3zHvhRGhk1JxXOxrWPm5ZqFyt/U4+8ywsGV9zZbcHK6MwcE3gevTCQneWGbBo64NDwp pqRJU4aNs/puTUYsWwge0qtzX7h/prAv9xtU8= Received: by 10.227.155.71 with SMTP id r7mr6121830wbw.102.1274178143255; Tue, 18 May 2010 03:22:23 -0700 (PDT) Received: from [10.0.0.2] ([109.64.46.151]) by mx.google.com with ESMTPS id u36sm47593484wbv.6.2010.05.18.03.22.20 (version=SSLv3 cipher=RC4-MD5); Tue, 18 May 2010 03:22:22 -0700 (PDT) Message-ID: <4BF26A59.1000405@gmail.com> Date: Tue, 18 May 2010 13:22:17 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: <20100517204502.4A74B3A6A0A@core3.amsl.com> <4BF1AFF5.9080301@ieca.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Sean Turner Subject: Re: [IPsec] Open IKEv2 errata 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, 18 May 2010 10:24:52 -0000 2195 looks like a clarification to me. And not an essential one either, because the attribute structure further down the section make it very clear that there's one type per attribute. Thanks, Yaron On 05/18/2010 12:39 AM, Paul Hoffman wrote: > At 5:07 PM -0400 5/17/10, Sean Turner wrote: >> 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 : Internet Key Exchange Protocol: IKEv2 >>> Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen >>> Filename : draft-ietf-ipsecme-ikev2bis-11.txt >>> Pages : 130 >>> Date : 2010-5-17 >>> >>> 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-11.txt >> >> Note that during this update we considered the following errata: >> http://www.rfc-editor.org/errata_search.php?eid=1671 >> http://www.rfc-editor.org/errata_search.php?eid=1672 >> http://www.rfc-editor.org/errata_search.php?eid=2190 >> http://www.rfc-editor.org/errata_search.php?eid=2191 >> http://www.rfc-editor.org/errata_search.php?eid=2192 >> http://www.rfc-editor.org/errata_search.php?eid=2193 >> http://www.rfc-editor.org/errata_search.php?eid=2194 >> http://www.rfc-editor.org/errata_search.php?eid=2195 >> http://www.rfc-editor.org/errata_search.php?eid=2196 >> >> 1671, 1672, and 2196 were already reworded in ikev2bis. >> >> 2190 is not needed as it's covered in the next paragraph. >> >> No one has reported problems with 2191, 2192, 2193, or 2194. >> >> 2195 seems reasonable, but there's been no discussion. >> >> At this point, we believe there's no action required on these. Please let me know very soon whether you see a problem with this course of action. > > In specific, it would be good if the pickier folks on this list to look at 2195 and see if this is really just a clarification or is a change that limits something we don't want to limit. Comments on any of the others is welcome too. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Tue May 18 03:37: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 4A5703A6A36 for ; Tue, 18 May 2010 03:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_05=-1.11] 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 mXIaVNjlkaYP for ; Tue, 18 May 2010 03:37:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB6A3A6936 for ; Tue, 18 May 2010 03:37: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 o4IAb1Va000156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 13:37:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o4IAb0cK001669; Tue, 18 May 2010 13:37:00 +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: <19442.28108.255794.859480@fireball.kivinen.iki.fi> Date: Tue, 18 May 2010 13:37:00 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <20100517204502.4A74B3A6A0A@core3.amsl.com> <4BF1AFF5.9080301@ieca.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: ipsec@ietf.org, Sean Turner Subject: [IPsec] Open IKEv2 errata 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, 18 May 2010 10:37:26 -0000 Paul Hoffman writes: > In specific, it would be good if the pickier folks on this list to > look at 2195 and see if this is really just a clarification or is a > change that limits something we don't want to limit. Comments on any > of the others is welcome too. I think the change in 2195 is ok, but unneeded, as Configuration Attribute substructure has only on value (the field inside the configuration attribute is called value, not values, thus configuration attribute cannot have more than one value). So only way to send multiple attribute values is to send multiple configuration attribute structures inside one configuration payload. But if someone though this is not clear enough, the change is harmless, and can be done. -- kivinen@iki.fi From kivinen@iki.fi Tue May 18 05:59: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 39C453A6BA4 for ; Tue, 18 May 2010 05:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_05=-1.11] 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 QudV1x+XnsSM for ; Tue, 18 May 2010 05:59:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 431303A6C32 for ; Tue, 18 May 2010 05:58:58 -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 o4ICwkJM001449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 May 2010 15:58:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o4ICwjoZ019121; Tue, 18 May 2010 15:58:45 +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: <19442.36613.651993.353644@fireball.kivinen.iki.fi> Date: Tue, 18 May 2010 15:58:45 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 10 min Subject: [IPsec] Comments to draft-ietf-ipsecme-eap-mutual-02.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, 18 May 2010 12:59:24 -0000 I read this document and it seems to be mostly ok. I might disagree on some parts of the section 1 text talking why EAP is needed (I think the main reason was to support legacy systems. The public keys are flexible enough to meet requirements of many deployment scenarios unless your requirement includes "that must support old legacy infrastructure"), but I do not think there is need to change text there. The section 3 should add text telling what protocol ID is used for the notification, just like most of the other extensions do: "Protocol ID and the SPI Size fields MUST both be sent as 0.", i.e. change: The SPI size field is set to zero, and there is no additional data associated with this notification. to The protocol ID and SPI size fields are set to zero, and there is no additional data associated with this notification. -- kivinen@iki.fi From yaronf.ietf@gmail.com Tue May 18 09:57: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 96A793A6A87 for ; Tue, 18 May 2010 09:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7ZPvBjFBBwy for ; Tue, 18 May 2010 09:57:28 -0700 (PDT) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by core3.amsl.com (Postfix) with ESMTP id 28FA53A688E for ; Tue, 18 May 2010 09:56:58 -0700 (PDT) Received: by wyf19 with SMTP id 19so1262354wyf.27 for ; Tue, 18 May 2010 09:56: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:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=BTYwbU/JGjQ7dCa2wbkY24ae2MWjBSNIQGJ7OjcXvPM=; b=NvCNvGTlO6qCpSTr6KEivuWxpKb3YrCmVVvq4KaIQk/AZceebYxBI97IXOSmhAirMZ uXuqvROBNUbUEJieTegTTUq1hL5qyj0m0hHmq+ASMVkkMfw9C4GWSEgqknn9KkRrH5Um NJnYg9JC0s9RfdqO/+a8ho8utj691YXJs/3eQ= 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=u8PdxDVjqyEtkoKWqH9w/TQKeBSWhJMWhkqUhL8Y2iUUIVDiZ1DhdEwdeSOx3jupPE WxCSKekHNsrMzwGgmz7EKAJWAj8C3TN/RyR1AGzNFal8VOjpTjBAwWGZVzexJY+K7ers bxx51LWhGn24imnUyRxfDz7idR7EKZY7ouuzw= Received: by 10.227.157.198 with SMTP id c6mr6484862wbx.173.1274201807176; Tue, 18 May 2010 09:56:47 -0700 (PDT) Received: from [10.0.0.2] ([109.64.46.151]) by mx.google.com with ESMTPS id u36sm16670472wbv.18.2010.05.18.09.56.45 (version=SSLv3 cipher=RC4-MD5); Tue, 18 May 2010 09:56:46 -0700 (PDT) Message-ID: <4BF2C6CB.2060907@gmail.com> Date: Tue, 18 May 2010 19:56:43 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Tero Kivinen References: <19442.36613.651993.353644@fireball.kivinen.iki.fi> In-Reply-To: <19442.36613.651993.353644@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-eap-mutual-02.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, 18 May 2010 16:57:29 -0000 Hi Tero, thanks for your comments. I (obviously) disagree with your position on EAP, but I'll leave it at that. The WG decided we will specify this extension, and the market will decide in what exact scenarios it is, or isn't, useful. I will change the text in Sec. 3. Regards, Yaron On 05/18/2010 03:58 PM, Tero Kivinen wrote: > I read this document and it seems to be mostly ok. > > I might disagree on some parts of the section 1 text talking why EAP > is needed (I think the main reason was to support legacy systems. The > public keys are flexible enough to meet requirements of many > deployment scenarios unless your requirement includes "that must > support old legacy infrastructure"), but I do not think there is need > to change text there. > > The section 3 should add text telling what protocol ID is used for the > notification, just like most of the other extensions do: "Protocol ID > and the SPI Size fields MUST both be sent as 0.", i.e. change: > > The SPI size field is set > to zero, and there is no additional data associated with this > notification. > > to > > The protocol ID and SPI size fields are set > to zero, and there is no additional data associated with this > notification. From JArora@acmepacket.com Tue May 18 19:38: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 590FC3A6ADC for ; Tue, 18 May 2010 19:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 mhxFPqUVmKBk for ; Tue, 18 May 2010 19:38:24 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 94A6D3A6ABD for ; Tue, 18 May 2010 19:38:22 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 18 May 2010 22:38:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 18 May 2010 22:38:14 -0400 From: Jitender Arora To: Tero Kivinen Date: Tue, 18 May 2010 22:37:57 -0400 Thread-Topic: [IPsec] New draft posted Thread-Index: AcrxyA++qU4pId1QQsKWqgy8ZJCSQgFMTE/w Message-ID: References: <1272187315.22380.46.camel@yaronf-linux> <19414.51287.786283.875147@fireball.kivinen.iki.fi> <19422.50181.199229.35876@fireball.kivinen.iki.fi> <19434.37859.216575.687495@fireball.kivinen.iki.fi> In-Reply-To: <19434.37859.216575.687495@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: multipart/alternative; boundary="_000_A8F897BE25922348AB562D74E6C686E41F5835E6BDmail_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New 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: Wed, 19 May 2010 02:38:32 -0000 --_000_A8F897BE25922348AB562D74E6C686E41F5835E6BDmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments inline. -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Wednesday, May 12, 2010 7:41 AM To: Jitender Arora Cc: ipsec@ietf.org Subject: Re: [IPsec] New draft posted Jitender Arora writes: > Jitender--> Currently we are using this approach (basically using > the redirect and the Mobike). > > This is causing the following issues: > > 1. If the redirect message is handled by the Load Balancer, the > load balancer needs to be IKEv2 aware and also it needs to know the > IP addresses of the Security Gateways for which it is responsible. > This can cause the performance issues as the Load Balancer should > not be application aware and should do the load balancing based on > the layer 3/layer 4 information. Load balancer by definition needs to know the devices where it is sharing the load to, so I do not consider that a problem. Also if the redirection is done in the IKE_SA_INIT phase then the application support required is very minimal. Jitender--> Adding the IKEv2 stack on the Load balancer defeats the purpose= of having a generic load balancer, which can work for any type of sessions= . For example in our case we will be load balancing the SIP traffic, IPSEC = tunnels and will add more types of applications. So this box is not going t= o handle only the load balancing of the IPSEC tunnels. Most of the vendors = would like the load balancer to be generic and not application dependent. I would think that the by separating the IPSEC traffic and ikev2 signaling = can make the architectures much cleaner and will be useful in other applica= tions as well. Also there is no need that the load balancer itself needs to be acting as application gateway, the published IP address for the IKEv2 connections can also be some other IP-address, i.e. that host does not need to be on the path of the real traffic. If this one host is only parsing IKE_SA_INIT packets and sending redirect backs any old 386 box you can find from your junk pile will be able to handle the traffic up to millions of clients (million clients, each connecting for example once per hour means there is 277 connection attempts per second, and any old box can receive 277 udp packets and send 277 udp replies back (in completely stateless manner)). Jitender--> You are assuming that the Load Balancer will just be handling t= he IKE_SA_INITS, but in reality it will be communicating with all the secur= ity gateways also to get real time information about the number of sessions= on each security gateway, CPU usage and all other matrix which will help i= n deciding where the new tunnel will be redirected. So there will be much m= ore activity going on the laod balance than just handling 277 connection at= tempts per sec. I would think that we don't need to go into the design disc= ussions as to whether this is feasible or not. What we are proposing is the= cleaner way of handling the load balancing issues. > 2. If the Load Balancer passes this IKEv2 messages directly to the > security gateways using the layer 3 information, the security > gateway will then have to send the redirect to the client back > through the LoadBalancer and telling the client to talk to different > address now. This again causes an extra message exchange to achieve > the load balancing. Those extra messages only happen during the setup phase, and I would expect the load balancer can pass through those less than 300 messages per second. If it cannot, then you have much bigger problems when the real traffic starts to come in... > Jitender--> I think, I did not make this clear, the Load Balancer > will not take care of the IKEv2 traffic, it will just pass through > the IKEv2 traffic to the security gateways without handling them. > But all the IKEv2 traffic will have to go through this load balancer > so that the IKEv2 signaling can take place between the same > addresses. So if the load balancer cannot handle few hundred packets per second to passthrough then I think you should really consider replacing the hardware. Jitender---> I did not get this, as I said all the IKEv2 signaling will pas= s through the Load balancer. What we don't want is the IPSEC traffic from 2= million clients to pass through the Load balancer. For normal IPsec use the IKEv2 packet are not send periodically at all. There is 2+2 packets in the beginning. There might be one DPD exchange over IKEv2 SA when the ESP traffic stops, but after that there shouldn't be anything until the ESP traffic restarts. So there should very little IKEv2 traffic, and in normal case it is limited to about 6 packets in total over the whole lifetime of the IKEv2 SA. > In IKEv2 the IKEv2 SA and IPsec SAs are very closely tied together, > and running them on separate machines is very complicated (We just > had long discussion about this on the list, i.e. what kind of > failure models can happen and what cannot happen). > > Jitender--> If this has been captured somewhere, can you please > point us to that link. Jitender--> what I propose is that I will update the document to include th= e usage scenario in more details and we can discuss again. http://www.ietf.org/mail-archive/web/ipsec/current/msg06192.html -- kivinen@iki.fi --_000_A8F897BE25922348AB562D74E6C686E41F5835E6BDmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments inline.

 

-----Original Message-----
From: Tero Kivinen [mailto:kivinen@iki.fi]
Sent: Wednesday, May 12, 2010 7:41 AM
To: Jitender Arora
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New draft posted

 

Jitender Arora writes:

> Jitender--> Currently we are using this approach (basically using

> the redirect and the Mobike).

>

> This is causing the following issues:

>

> 1. If the redirect message is handled by the Load Balancer, the<= /span>

> load balancer needs to be IKEv2 aware and also it needs to know the

> IP addresses of the Security Gateways for which it is responsible.

> This can cause the performance issues as the Load Balancer should

> not be application aware and should do the load balancing based on

> the layer 3/layer 4 information.

 

Load balancer by definition needs to know the devices where it is

sharing the load to, so I do not consider that a problem. Also if the

redirection is done in the IKE_SA_INIT phase then the application

support required is very minimal.

 

Jitender--> Adding the IKEv2 st= ack on the Load balancer defeats the purpose of having a generic load balancer, wh= ich can work for any type of sessions. For example in our case we will be load balancing the SIP traffic, IPSEC tunnels and will add more types of applications. So this box is not going to handle only the load balancing of= the IPSEC tunnels. Most of the vendors would like the load balancer to be gener= ic and not application dependent.

 

I would think that the by separati= ng the IPSEC traffic and ikev2 signaling can make the architectures much cleaner a= nd will be useful in other applications as well.

 

Also there is no need that the load balancer itself needs to be acting

as application gateway, the published IP address for the IKEv2

connections can also be some other IP-address, i.e. that host does not

need to be on the path of the real traffic. If this one host is only<= /span>

parsing IKE_SA_INIT packets and sending redirect backs any old 386 box

you can find from your junk pile will be able to handle the traffic up

to millions of clients (million clients, each connecting for example

once per hour means there is 277 connection attempts per second, and<= /span>

any old box can receive 277 udp packets and send 277 udp replies back

(in completely stateless manner)).

 

Jitender--> You are assuming th= at the Load Balancer will just be handling the IKE_SA_INITS, but in reality it wil= l be communicating with all the security gateways also to get real time informat= ion about the number of sessions on each security gateway, CPU usage and all ot= her matrix which will help in deciding where the new tunnel will be redirected.= So there will be much more activity going on the laod balance than just handli= ng 277 connection attempts per sec. I would think that we don't need to go int= o the design discussions as to whether this is feasible or not. What we are proposing is the cleaner way of handling the load balancing issues.

 

> 2. If the Load Balancer passes this IKEv2 messages directly to the

> security gateways using the layer 3 information, the security

> gateway will then have to send the redirect to the client back

> through the LoadBalancer and telling the client to talk to different

> address now. This again causes an extra message exchange to achieve

> the load balancing.

 

Those extra messages only happen during the setup phase, and I would

expect the load balancer can pass through those less than 300 messages<= /span>

per second. If it cannot, then you have much bigger problems when the

real traffic starts to come in...

 

> Jitender--> I think, I did not make this clear, the Load Balancer

> will not take care of the IKEv2 traffic, it will just pass through

> the IKEv2 traffic to the security gateways without handling them.

> But all the IKEv2 traffic will have to go through this load balancer

> so that the IKEv2 signaling can take place between the same

> addresses.

 

So if the load balancer cannot handle few hundred packets per second

to passthrough then I think you should really consider replacing the

hardware.

 

Jitender-à I did not get this, as I s= aid all the IKEv2 signaling will pass through the Load balancer. What we don’= t want is the IPSEC traffic from 2 million clients to pass through the Load balancer.

 

For normal IPsec use the IKEv2 packet are not send periodically at

all. There is 2+2 packets in the beginning. There might be one DPD

exchange over IKEv2 SA when the ESP traffic stops, but after that<= /font>

there shouldn't be anything until the ESP traffic restarts.

 

So there should very little IKEv2 traffic, and in normal case it is=

limited to about 6 packets in total over the whole lifetime of the

IKEv2 SA.

 

> In IKEv2 the IKEv2 SA and IPsec SAs are very closely tied together,

> and running them on separate machines is very complicated (We just

> had long discussion about this on the list, i.e. what kind of

> failure models can happen and what cannot happen).=

>

> Jitender--> If this has been captured somewhere, can you please

> point us to that link.

 

Jitenderà what I propose is that I w= ill update the document to include the usage scenario in more details and we ca= n discuss again.

 

http://www.ietf.org/mail-archive/web/ipsec/current/msg06192.html<= o:p>

--

kivinen@iki.fi

--_000_A8F897BE25922348AB562D74E6C686E41F5835E6BDmail_-- From kivinen@iki.fi Wed May 19 06:05: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 EF7423A6994 for ; Wed, 19 May 2010 06:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_50=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 MZGVvKzyLLpf for ; Wed, 19 May 2010 06:05:41 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id ED3563A6971 for ; Wed, 19 May 2010 06:05:05 -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 o4JD4pQT009207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 16:04:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o4JD4pvt024955; Wed, 19 May 2010 16:04:51 +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: <19443.57842.994830.910355@fireball.kivinen.iki.fi> Date: Wed, 19 May 2010 16:04:50 +0300 From: Tero Kivinen To: Jitender Arora In-Reply-To: References: <1272187315.22380.46.camel@yaronf-linux> <19414.51287.786283.875147@fireball.kivinen.iki.fi> <19422.50181.199229.35876@fireball.kivinen.iki.fi> <19434.37859.216575.687495@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 14 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New 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: Wed, 19 May 2010 13:05:43 -0000 Jitender Arora writes: > Load balancer by definition needs to know the devices where it is > sharing the load to, so I do not consider that a problem. Also if the > redirection is done in the IKE_SA_INIT phase then the application > support required is very minimal. > > > Jitender--> Adding the IKEv2 stack on the Load balancer defeats the > purpose of having a generic load balancer, which can work for any > type of sessions. For example in our case we will be load balancing > the SIP traffic, IPSEC tunnels and will add more types of > applications. So this box is not going to handle only the load > balancing of the IPSEC tunnels. Most of the vendors would like the > load balancer to be generic and not application dependent. So you have generic load balancer, which doesn't want to know anything about the protocols, but then you are adding more and more types of application to be handled by the same load balancer. This is bit of a contradiction. Your generic load balancer support can easily be so that it forwards all IKEv2 and IPsec traffic destinationed directly to the security gateways to those gateways (or the router will already take care of that if you do not want to route packets through load balancer), and when new IKEv2 connection comes in with the published IP-address you either process that in the load balancer, or forward it to any of the security gateways (or one master security gateway) which will then do IKEv2 redirect to proper gateway. I still do not see any need for why the IKEv2 in the load balancer should support your extended IKEv2 protocol, when it can implement the normal redirect protocol and redirect the whole IPsec and IKEv2 SA combo to suitable gateway. In your proposal who is terminating the IKEv2 connections? Who is sending the N(TUNNEL_ADDRESS) payloads? Who is processing the IPsec traffic? > Jitender--> You are assuming that the Load Balancer will just be > handling the IKE_SA_INITS, but in reality it will be communicating > with all the security gateways also to get real time information > about the number of sessions on each security gateway, CPU usage and > all other matrix which will help in deciding where the new tunnel > will be redirected. Yes, but that protocol is outside the scope of this discussion, or at least that is what I assumed, as your draft does not cover any of that. The load balancer does NOT need to process any IPsec or IKEv2 packets after the initial IKE_SA_INIT to do that. It just needs to get some statistics and other information from gateways so it can make sure it forwards next incoming connection to suitable free sgw. It can also provide information to the SGWs when they should move some IPsec/IKEv2 SAs to some other SGW when one of them is getting too loaded. The SGW can do that using MOBIKE, provided they first use some other protocol and sync the IPsec and IKEv2 state between the old and new SGWs. > So there will be much more activity going on the > laod balance than just handling 277 connection attempts per sec. I > would think that we don't need to go into the design discussions as > to whether this is feasible or not. What we are proposing is the > cleaner way of handling the load balancing issues. I do not think it is cleaner way, as I think it makes things very messy if the IKEv2 and IPsec SAs are terminated in different locations. The IKEv2 do have all kind of implicit assumptions about the IKEv2 and IPsec address connection, and implementations have even more. We noticed this when we were making MOBIKE, and there things were easy as we knew that all the IP-addresses are still talking to the same node. In your case this would not be true, and that makes things even more complicated. > Jitender---> I did not get this, as I said all the IKEv2 signaling > will pass through the Load balancer. What we don't want is the IPSEC > traffic from 2 million clients to pass through the Load balancer. Why do the IKEv2 signaling need to pass through the load balancer? Why it cannot go directly to the suitable SGW after the initial IKE_SA_INIT redirect? -- kivinen@iki.fi From jmpark81@gmail.com Thu May 20 08:37: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 9F3533A6C4C for ; Thu, 20 May 2010 08:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 eLPV+CNy3m8n for ; Thu, 20 May 2010 08:37:19 -0700 (PDT) Received: from mail-yw0-f201.google.com (mail-yw0-f201.google.com [209.85.211.201]) by core3.amsl.com (Postfix) with ESMTP id 5F7943A6BEF for ; Thu, 20 May 2010 08:37:19 -0700 (PDT) Received: by ywh39 with SMTP id 39so2947071ywh.21 for ; Thu, 20 May 2010 08:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ffhSv4DoAJURUa/VQRltLtIWkjGgPxD6cxY04kpQSnY=; b=Cf0dPJOeR9pjMFn8FHxXvxTNIOitBHyeuFcNL+NCckqu++QVNXgmWDvBCiep91Q4E7 9FoENb9yeqzBcpNv4HLzd8ZiluyOjUhFPbmmeM+/Q2kOjK/phq/nfTR8KAaGpDRLQBm5 hPuRr39yBuZBUmubbVsS8hY0WLSnK3SzwA9gs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MvqryZ26MCQorLVaTUhl6H76b14hX1BkKo3ewEyaIl4RjQ8UyaO0yf8cL0ZRLwpVov Qz1CoVTosAiKXFcKAQZT1BKhBczSLQQBkSS110PQazsvskitCUx9sEkWhUlAtJVTcyC3 lNC6J6y2UGqRXzYwIF566nZm8LiM8NURlpKgI= MIME-Version: 1.0 Received: by 10.229.189.147 with SMTP id de19mr48494qcb.198.1274369828166; Thu, 20 May 2010 08:37:08 -0700 (PDT) Received: by 10.229.41.81 with HTTP; Thu, 20 May 2010 08:37:08 -0700 (PDT) Date: Fri, 21 May 2010 00:37:08 +0900 Message-ID: From: Jaemin Park To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016361e7f06ebb398048708586b Subject: [IPsec] Who is the Initiator of rekeying CHILD SA? 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, 20 May 2010 15:40:21 -0000 --0016361e7f06ebb398048708586b Content-Type: text/plain; charset=ISO-8859-1 This can be the ridiculous question, but there exist some confusion in the context of initiator of CHILD SA around me. Suppose that host A and host B exist. Host A initiated the exchanges (IKE_SA_INIT & IKE_AUTH) to establish the IKE SA and CHILD SA with host B. (In this case, Host A is the Initiator and Host B is responder.) Then, host B (the responder of previous IKE exchange) initiated the CHILD SA rekeying (CREATE_CHILD_SA) with host A. In this case, who is the Initiator of rekeying CHILD SA? host B? or host A? According to the RFC4306, I think host B is the initiator of CHILD SA. Therefore, the fields such as SPIi, Ni and TSi should be the value of host B. Am I right? --0016361e7f06ebb398048708586b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This can be the ridiculous question, but there exist some confusion in= the context of initiator of CHILD SA around me.
=A0
Suppose that host A and host B exist.
=A0
Host A initiated the exchanges (IKE_SA_INIT & IKE_AUTH)=A0to estab= lish the IKE SA and CHILD SA with host B. (In=A0this case, Host A is the=A0= Initiator and Host B is responder.)
Then,=A0host B (the responder of previous IKE exchange) initiated the = CHILD SA rekeying (CREATE_CHILD_SA) with host A.
=A0
In this case, who is the Initiator of rekeying CHILD SA? host B? or ho= st A?
According to the RFC4306, I think host B is the initiator of CHILD SA.=
Therefore, the fields such as SPIi, Ni and TSi should be the value of = host B. Am I right?
--0016361e7f06ebb398048708586b-- From wwwrun@core3.amsl.com Thu May 20 13:17:45 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 55E393A6A06; Thu, 20 May 2010 13:17:44 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100520201745.55E393A6A06@core3.amsl.com> Date: Thu, 20 May 2010 13:17:45 -0700 (PDT) Cc: ipsecme mailing list , ipsecme chair , Internet Architecture Board , RFC Editor Subject: [IPsec] Protocol Action: '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, 20 May 2010 20:17:45 -0000 The IESG has approved the following document: - 'Internet Key Exchange Protocol: IKEv2 ' as a Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-11.txt Technical Summary 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. Working Group Summary This document is the product of the IPSECME WG. There were no notable issues with the WG process. There were the usual heated discussions, one of which had to be resolved by a design team. But, the eventual result has a wide consensus. Document Quality There are multiple implementations of the IKEv2 protocol. Since this document essentially clarifies the protocol (with only a tiny amount of actual protocol changes), we expect all IPsec vendors to ensure that their implementation is in line with this document. Personnel Yaron Sheffer (yaronf@checkpoint.com) is the document shepherd. Sean Turner (turners@ieca.com) is the Responsible Area Director. The IANA Expert(s) for the registries in this document is Tero Kivinen (kivinen@iki.fi). From kagarigi@cisco.com Fri May 21 01:30: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 3E5EA3A7586 for ; Fri, 21 May 2010 01:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 3u2n+HeGNoMn for ; Fri, 21 May 2010 01:30:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 58A9E3A8015 for ; Thu, 20 May 2010 22:58:49 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAIq99UtAaHtegWdsb2JhbACBPpxiFQEBFiIio02ZQoUSBIM+ X-IronPort-AV: E=Sophos;i="4.53,276,1272844800"; d="scan'208,217";a="7705297" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ams-iport-2.cisco.com with ESMTP; 21 May 2010 05:20:02 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4L5wcqa025150; Fri, 21 May 2010 05:58:39 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 11:28:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF8AA.9FD20A23" Date: Fri, 21 May 2010 11:28:23 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Who is the Initiator of rekeying CHILD SA? Thread-Index: Acr4MsfgGIBBizf1SiiP+W6dImD//AAd7lPQ References: From: "Kalyani Garigipati (kagarigi)" To: "Jaemin Park" , X-OriginalArrivalTime: 21 May 2010 05:58:24.0452 (UTC) FILETIME=[9FE9F840:01CAF8AA] Subject: Re: [IPsec] Who is the Initiator of rekeying CHILD SA? 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, 21 May 2010 08:30:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF8AA.9FD20A23 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jaemin, =20 You are right, Since B is initiating the exchange the values of SPIi, Ni, and TSi will be the values of host B =20 Regards, kalyani =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Jaemin Park Sent: Thursday, May 20, 2010 9:07 PM To: ipsec@ietf.org Subject: [IPsec] Who is the Initiator of rekeying CHILD SA? =20 This can be the ridiculous question, but there exist some confusion in the context of initiator of CHILD SA around me. =20 Suppose that host A and host B exist. =20 Host A initiated the exchanges (IKE_SA_INIT & IKE_AUTH) to establish the IKE SA and CHILD SA with host B. (In this case, Host A is the Initiator and Host B is responder.) Then, host B (the responder of previous IKE exchange) initiated the CHILD SA rekeying (CREATE_CHILD_SA) with host A. =20 In this case, who is the Initiator of rekeying CHILD SA? host B? or host A? According to the RFC4306, I think host B is the initiator of CHILD SA.=20 Therefore, the fields such as SPIi, Ni and TSi should be the value of host B. Am I right? ------_=_NextPart_001_01CAF8AA.9FD20A23 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Jaemin,

 

You are right, Since B is = initiating the exchange the values of SPIi, Ni, and TSi will be the values of host = B

 

Regards,

kalyani

=

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Jaemin Park
Sent: Thursday, May 20, = 2010 9:07 PM
To: ipsec@ietf.org
Subject: [IPsec] Who is = the Initiator of rekeying CHILD SA?

 

This can be the ridiculous question, but there exist some = confusion in the context of initiator of CHILD SA around = me.

 

Suppose that host A and host B = exist.

 

Host A initiated the exchanges (IKE_SA_INIT & = IKE_AUTH) to establish the IKE SA and CHILD SA with host B. (In this case, Host = A is the Initiator and Host B is = responder.)

Then, host B (the responder of previous IKE exchange) = initiated the CHILD SA rekeying (CREATE_CHILD_SA) with host = A.

 

In this case, who is the Initiator of rekeying CHILD SA? host B? = or host A?

According to the RFC4306, I think host B is the initiator of = CHILD SA.

Therefore, the fields such as SPIi, Ni and TSi should be the = value of host B. Am I right?

------_=_NextPart_001_01CAF8AA.9FD20A23-- From yaronf.ietf@gmail.com Mon May 24 13:07: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 B9B3F3A6FD8 for ; Mon, 24 May 2010 13:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 kEO0q16Z4X9H for ; Mon, 24 May 2010 13:07:21 -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 3ACF53A6B0A for ; Mon, 24 May 2010 13:07:21 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so1014274fge.13 for ; Mon, 24 May 2010 13:07:09 -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=uF+srRM/IZkA+IIVkCmZc9zJlsFqSnoxuSI6e0IfqDY=; b=JYxEqqPpDD5vfptUO+qwF7CN+JzbvTjQ8dG4SpH5y554x81NOhk5YgIU7HIuKP4iZl ZExPHDna/Oe/97n4znOy1byHD6tIcAiFavhzK/3jSVytEl755CpniaVOXVf7EkN8otxW QRuSlijvPDmbsZ214WLvII26i83+vkrXUahIk= 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=PKbv7NVLnjAawnEdoZf9Rz29ANpcGWW9rfGM19985KXrR0NCxJW2kcEgJqSEqSPXze /bVRQf9jhLw2ep37YNjTDLXnK8v7KVjsdDv9Y8SPQ6Ai6IGtDYZ5hr3K5IxgV1FDBYrL w0xXUB3S09vhrq45lEAcfkioP7kQcvN5IHPdQ= Received: by 10.87.47.6 with SMTP id z6mr8985472fgj.13.1274731628126; Mon, 24 May 2010 13:07:08 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-45-8.red.bezeqint.net [79.178.45.8]) by mx.google.com with ESMTPS id k29sm6145388fkk.15.2010.05.24.13.07.04 (version=SSLv3 cipher=RC4-MD5); Mon, 24 May 2010 13:07:05 -0700 (PDT) Message-ID: <4BFADC66.3030902@gmail.com> Date: Mon, 24 May 2010 23:07:02 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Beginning the PAKE selection process 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, 24 May 2010 20:07:22 -0000 Hi everyone, In the past we have had heated discussions on password-based auth. Judging by the resounding silence over the last week, only the draft authors are interested. If this is true, then the working group as a whole is seemingly unable to work on this charter item. Personally, I would prefer a different outcome. But as a co-chair, I would not hesitate to eliminate this work item if there is no community support for it. Thanks, Yaron On 05/17/2010 05:42 PM, Paul Hoffman wrote: > Greetings again. This WG is chartered to "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 needs to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. > > As we discussed earlier, each WG member needs to come up with their own criteria for making such a choice. Dan Harkins has proposed a set of guidelines that individuals might use when choosing; see. > > So far, three protocols have been proposed to the WG: > > - > > - > > - > > In addition, one more draft was presented to the WG:. However the Augmented PAKE draft does not specify how it would be integrated into IKEv2. > > Note that more proposals might be made as we discuss; such proposals will hopefully be accompanied by Internet Drafts that show both the crypto and how it would be integrated into IKEv2. > > To start off this conversation, I propose that people start threads on the individual drafts, saying which positive and negative criteria they think apply to each. I also propose that replying to this message, or starting a thread that is supposedly about all four proposals but only focuses on one, is not going to help much. Of course, the authors of the four drafts are welcome to say why they think their proposal meets an optimum set of criteria, and to clarify parts of their proposals as others comment. > > Obviously these are all initial drafts, and the WG will have ample opportunity to improve the selected proposal later in the process. For now, please focus on the relative advantages and disadvantages (based on your personal criteria) of each of the proposals. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From dharkins@lounge.org Mon May 24 13:24: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 C77673A6841 for ; Mon, 24 May 2010 13:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=-1.049, BAYES_80=2, 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 inTEwYuEVfMx for ; Mon, 24 May 2010 13:24:34 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 8EE433A67AC for ; Mon, 24 May 2010 13:24:34 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B26A11022404C for ; Mon, 24 May 2010 13:24:26 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 24 May 2010 13:24:26 -0700 (PDT) Message-ID: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> Date: Mon, 24 May 2010 13:24:26 -0700 (PDT) From: "Dan Harkins" To: ipsec@ietf.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 Subject: [IPsec] PAKE selection: SPSK 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, 24 May 2010 20:24:35 -0000 Hi, To kick off the PAKE selection discussion I'd like to tout one of the candidate protocols. It is based on the dragonfly key exchange and is described in draft-harkins-ipsecme-spsk-auth. Variants of dragonfly have been proposed for IEEE 802.11 and as an EAP method. The aforementioned draft contains a complete description of how to add dragonfly to IKE(v2), including the additional payloads needed, their construction and processing, their format, and how they fit into IKE(v2). While complete it isn't rigid; things (like the way this exchange is indicated) can change without affecting security. I think the best way to start the discussion is to run through the enumerated selection criteria from draft-harkins-ipsecme-pake-criteria. SEC1: dragonfly is based on a zero knowledge proof. It is resistant to passive, active, and (off-line) dictionary attack. SEC2: the PFS characteristics of IKE and its resistance to the Denning-Sacco attack are unchanged by inclusion of this authentication method. Dragonfly generates a shared key that has the properties of PFS and it is resistant to the Denning-Sacco attack but the generated key is used only for authentication. SEC3: the dragonfly exchange happens after IKE(v2)'s Diffie-Hellman key exchange and the subsequent payloads, including the ID payloads, are protected by a derivative of the resulting key. ID protection is not affected. SEC4: the protocol does not effect the "crypto agility" of IKE(v2). It uses the same Diffie-Hellman group that IKE(v2) uses, uses the same prf+() construct, and can use the negotiated MAC in HMAC form. No additional primitives (special modes of encryption, for example) are needed. SEC5: dragonfly has received cryptographic review in its other instantiations (IEEE 802.11 and EAP) and is secure. A proof of security in the Random Oracle model is underway but has not been finished. SEC6: the way dragonfly has been added to IKE(v2) is for authentication of the exchange in which it resides only. Since dragonfly is key generating though, it is possible to use it to parlay the weak secret into a long-term credential. SEC7: a secret element, based on the password, in the selected group is used in the exchange. That element can be stored instead of the password to resist exposure of the password in the case of compromise. IPR1: dragonfly was first publicly disclosed in January of 2008. IPR2: dragonfly was invented by me but I did not patent it nor did my employer at the time of invention. It is believed to be patent-free. IPR3: no IPR disclosure to the IETF has been made because one is not needed. MISC1: dragonfly adds one roundtrip to IKEv2 and to IKEv1's Main Mode. It turns IKEv1's Aggressive Mode from a three message exchange to a four message exchange. MISC2: dragonfly requires three "scalar operations", point multiplication for ECC or modular exponentiation for MODP. Basically, a "Diffie- Hellman and a half". MISC3: the nature of the shared secret (password, passphrase, long random octet string) does not affect performance. MISC4: internationalization can be supported as evidenced by the EAP method employing the dragonfly exchange. MISC5: dragonfly can use any of the ECP and MODP groups defined in the IANA registry for IKE(v2). EC2N groups are disallowed because of patent concerns and a desire to make implementation of dragonfly be license free. There is no technical reason, though, why EC2N groups couldn't be used. MISC6: the protocol fits nicely into IKE(v2)'s request/response nature. One single request and response is added and additional information is piggy-backed on the final request and response in IKE(v2) already. MISC7: no additional negotiation is needed: no new groups, no new ciphers, no new cipher modes, no key wrapping. MISC8: dragonfly does not require trusted third parties nor does it require any clock synchronization. MISC9: dragonfly requires use of an HMAC instantiation of a hash algorithm. The current specification uses this as a "random function". Another instantiation of dragonfly uses an HMAC'd hash function in "extractor" and "expander" roles, effectively defining two roles for the single random function. This can easily be done for IKE(v2) too. MISC10: the protocol supports the use of elliptic curve cryptography. MISC11: dragonfly is easily implemented. A reference implementation of the IEEE 802.11 variant is a Source Forge project named "authsae". It requires APIs for ECC and MODP operations found in most modern crypto libraries (e.g. OpenSSL). Dragonfly is easy to implement, license/royalty/patent free, has modest overhead, and fits easily into IKE(v2). I believe the current manner in which it has been added to IKE(v2) is fine but it can be changed if implementation concerns require it. Dragonfly is secure and has received cryptographic review. It does not require any additional group definitions and, aside from an HMAC'd hash algorithm, does not require additional use of any other cryptographic primitives like ciphers. It does not require any specific cipher modes (e.g. CBC or ECB) nor does it prohibit any (e.g. a stream cipher or a block cipher being used as a stream cipher). It is completely "crypto agile". I believe it is the best candidate to meet the requirements laid out in the new charter. I solicit comments and questions on this proposal. regards, Dan. From dharkins@lounge.org Mon May 24 14:07: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 7B11C3A6F74 for ; Mon, 24 May 2010 14:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_50=0.001, 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 SescSZY4MtKr for ; Mon, 24 May 2010 14:07:21 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 200713A6F0E for ; Mon, 24 May 2010 14:07:21 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0A3491022404C; Mon, 24 May 2010 14:07:13 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 24 May 2010 14:07:13 -0700 (PDT) Message-ID: <1efd1968902681a735f0f3083b2c3066.squirrel@www.trepanning.net> In-Reply-To: <4BFADC66.3030902@gmail.com> References: <4BFADC66.3030902@gmail.com> Date: Mon, 24 May 2010 14:07:13 -0700 (PDT) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Beginning the PAKE selection process 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, 24 May 2010 21:07:22 -0000 Yaron, This is out-of-line. We had discussions on expanding the charter to include this as a work item and there was sufficient support in the WG to add it. At the time you argued against it and suggested that EAP-only was satisfactory. Now that EAP-only has finished WGLC you now want to revisit killing this work item? I object. For reasons that were not apparent (to me at least), the new charter said that the only draft specifying EAP-only was to be used as a starting point for the EAP-only work item but the only draft specifying how to solve the secure PSK work item was not. So the only reason this "overwhelming silence" didn't greet EAP-only was because this entire step was short circuited. There wasn't any discussion of EAP-only once it became work item-- perusing the list shows a whopping zero posts (!) on it between announcement of the -00 version and the start of WGLC (on the -02 version)-- yet no one called for its removal. I apologize for the tardiness of my post kicking off discussion on my candidate proposal but I was traveling for the past week-and-a-half and was otherwise indisposed. Hopefully this will start a discussion but if it doesn't then I would expect the same treatment of this work item as that given to EAP-only. You seem to alternate wearing your co-chairman's hat or not depending on what particular tactic you are employing but your strategy remains the same. I respectfully request that, when it comes to this work item, you decide whether to wear your WG co-chairman's hat or not and then stick to it. regards, Dan. On Mon, May 24, 2010 1:07 pm, Yaron Sheffer wrote: > Hi everyone, > > In the past we have had heated discussions on password-based auth. > Judging by the resounding silence over the last week, only the draft > authors are interested. If this is true, then the working group as a > whole is seemingly unable to work on this charter item. > > Personally, I would prefer a different outcome. But as a co-chair, I > would not hesitate to eliminate this work item if there is no community > support for it. > > Thanks, > Yaron > > On 05/17/2010 05:42 PM, Paul Hoffman wrote: >> Greetings again. This WG is chartered to "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 needs to pick >> one that both is believed to be secure and is believed to have >> acceptable intellectual property features. >> >> As we discussed earlier, each WG member needs to come up with their own >> criteria for making such a choice. Dan Harkins has proposed a set of >> guidelines that individuals might use when choosing; >> see. >> >> So far, three protocols have been proposed to the WG: >> >> - >> >> - >> >> - >> >> In addition, one more draft was presented to the >> WG:. However the >> Augmented PAKE draft does not specify how it would be integrated into >> IKEv2. >> >> Note that more proposals might be made as we discuss; such proposals >> will hopefully be accompanied by Internet Drafts that show both the >> crypto and how it would be integrated into IKEv2. >> >> To start off this conversation, I propose that people start threads on >> the individual drafts, saying which positive and negative criteria they >> think apply to each. I also propose that replying to this message, or >> starting a thread that is supposedly about all four proposals but only >> focuses on one, is not going to help much. Of course, the authors of the >> four drafts are welcome to say why they think their proposal meets an >> optimum set of criteria, and to clarify parts of their proposals as >> others comment. >> >> Obviously these are all initial drafts, and the WG will have ample >> opportunity to improve the selected proposal later in the process. For >> now, please focus on the relative advantages and disadvantages (based on >> your personal criteria) of each of the proposals. >> >> --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 May 24 14:50: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 803E53A6CD8 for ; Mon, 24 May 2010 14:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=-0.988, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 Rjf7a44+nDpA for ; Mon, 24 May 2010 14:50:36 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 80A473A6CD7 for ; Mon, 24 May 2010 14:50: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 hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4OLoPvY043367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2010 14:50:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1efd1968902681a735f0f3083b2c3066.squirrel@www.trepanning.net> References: <4BFADC66.3030902@gmail.com> <1efd1968902681a735f0f3083b2c3066.squirrel@www.trepanning.net> Date: Mon, 24 May 2010 14:50:23 -0700 To: "Dan Harkins" , "Yaron Sheffer" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Beginning the PAKE selection process 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, 24 May 2010 21:50:37 -0000 At 2:07 PM -0700 5/24/10, Dan Harkins wrote: > This is out-of-line. Would it have been less out-of-line if I, the other co-chair wrote it? Or if someone who is not a co-chair but understands how the IETF process is supposed to work wrote it? FWIW, I agree with what Yaron wrote. If there is little or no interest in advancing this work other than from the authors of the drafts, we should strongly consider taking it out of the WG charter. You disagree, and others might agree with you or with Yaron. > I apologize for the tardiness of my post kicking off discussion on my >candidate proposal but I was traveling for the past week-and-a-half and >was otherwise indisposed. Hopefully this will start a discussion but if >it doesn't then I would expect the same treatment of this work item as >that given to EAP-only. Your candidate proposal (and the other two candidate proposals) do not have the same standing as the single EAP-only draft. We are supposed to be choosing one proposal first, then working on that one. If there is not enough interest to even choose a proposal among three (so far) that seem to be reasonably well worked-out, why should we believe that there will be enough interest to adequately review the chosen proposal? It would be grand if the authors of even one of the various proposals could get enough independent interest in their proposals to show that we can do good work on the charter item. Dan has started a thread on his proposal; I assume Yaron will do so as well. What counts to me is whether others take up the threads with "that sounds right" or "that doesn't meet my criteria for this reason" and so on. --Paul Hoffman, Director --VPN Consortium From Nicolas.Williams@oracle.com Mon May 24 14:55: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 DC0633A68D4 for ; Mon, 24 May 2010 14:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.425 X-Spam-Level: X-Spam-Status: No, score=-5.425 tagged_above=-999 required=5 tests=[AWL=1.173, 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 sGlEekWdEz4n for ; Mon, 24 May 2010 14:55:15 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 080013A6836 for ; Mon, 24 May 2010 14:55:14 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4OLt38x009729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 May 2010 21:55:05 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4OKi8SW028919; Mon, 24 May 2010 21:55:03 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 263892521274738100; Mon, 24 May 2010 14:55:00 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 May 2010 14:55:00 -0700 Date: Mon, 24 May 2010 16:54:55 -0500 From: Nicolas Williams To: Paul Hoffman Message-ID: <20100524215455.GV9605@oracle.com> References: <4BFADC66.3030902@gmail.com> <1efd1968902681a735f0f3083b2c3066.squirrel@www.trepanning.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090206.4BFAF5BA.002B:SCFMA922111,ss=1,fgs=0 Cc: IPsecme WG , Dan Harkins Subject: Re: [IPsec] Beginning the PAKE selection process 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, 24 May 2010 21:55:15 -0000 On Mon, May 24, 2010 at 02:50:23PM -0700, Paul Hoffman wrote: > At 2:07 PM -0700 5/24/10, Dan Harkins wrote: > > This is out-of-line. > > Would it have been less out-of-line if I, the other co-chair wrote it? > Or if someone who is not a co-chair but understands how the IETF > process is supposed to work wrote it? > > FWIW, I agree with what Yaron wrote. If there is little or no interest > in advancing this work other than from the authors of the drafts, we > should strongly consider taking it out of the WG charter. You > disagree, and others might agree with you or with Yaron. Personally I'd much rather that the WG add non-PKIX authentication mechanism options to IKEv2 via existing frameworks: either EAP or the GSS-API. Nico -- From dharkins@lounge.org Mon May 24 16:27: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 9DA2D3A689F for ; Mon, 24 May 2010 16:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.604 X-Spam-Level: X-Spam-Status: No, score=-3.604 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_50=0.001, 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 SAM42eMIEQA2 for ; Mon, 24 May 2010 16:27:14 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 6A8E13A6883 for ; Mon, 24 May 2010 16:27:14 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 944551022404C; Mon, 24 May 2010 16:27:01 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 24 May 2010 16:27:01 -0700 (PDT) Message-ID: In-Reply-To: References: <4BFADC66.3030902@gmail.com> <1efd1968902681a735f0f3083b2c3066.squirrel@www.trepanning.net> Date: Mon, 24 May 2010 16:27:01 -0700 (PDT) From: "Dan Harkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , Dan Harkins Subject: Re: [IPsec] Beginning the PAKE selection process 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, 24 May 2010 23:27:15 -0000 Hi Paul, On Mon, May 24, 2010 2:50 pm, Paul Hoffman wrote: > At 2:07 PM -0700 5/24/10, Dan Harkins wrote: >> This is out-of-line. > > Would it have been less out-of-line if I, the other co-chair wrote it? Yes. Yaron has a conflict and because of it you said you were handling this discussion. If you're not happy with the silence then I'd expect you to ask the WG to provide some constructive input. I didn't expect the guy with the conflict to propose, "as a co-chair", elimination of the work item. >> I apologize for the tardiness of my post kicking off discussion on my >>candidate proposal but I was traveling for the past week-and-a-half and >>was otherwise indisposed. Hopefully this will start a discussion but if >>it doesn't then I would expect the same treatment of this work item as >>that given to EAP-only. > > Your candidate proposal (and the other two candidate proposals) do not > have the same standing as the single EAP-only draft. At the time of rechartering they weren't so different though. We had a discussion on adding two work items and each one had a single individual submission proposing a way to solve it. One immediately became a WG document and got the fast track into IETF LC with absolutely no discussion on the list. The other was put into a process that waited for alternatives to be written and now requires WG discussion or else it will be eliminated. So yea, _now_ the situation is different. But that's because the two work items were treated so differently from the start. So now I guess it's the case that we can't treat those two things the same because we're not treating them the same. Which sort of begs a question. > It would be grand if the authors of even one of the various proposals > could get enough independent interest in their proposals to show that we > can do good work on the charter item. I agree! Dan. From dharkins@lounge.org Mon May 24 16:42: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 829263A6EDE for ; Mon, 24 May 2010 16:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.91 X-Spam-Level: X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[AWL=1.355, 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 uSBqmNEv1B9Q for ; Mon, 24 May 2010 16:42:07 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id AAA703A6D2B for ; Mon, 24 May 2010 16:42:07 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BBDEF1022404C; Mon, 24 May 2010 16:41:59 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 24 May 2010 16:41:59 -0700 (PDT) Message-ID: In-Reply-To: <20100524215455.GV9605@oracle.com> References: <4BFADC66.3030902@gmail.com> <1efd1968902681a735f0f3083b2c3066.squirrel@www.trepanning.net> <20100524215455.GV9605@oracle.com> Date: Mon, 24 May 2010 16:41:59 -0700 (PDT) From: "Dan Harkins" To: "Nicolas Williams" 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 , Paul Hoffman , Dan Harkins Subject: Re: [IPsec] Beginning the PAKE selection process 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, 24 May 2010 23:42:08 -0000 Hi Nico, We discussed this in the WG. The non-PKIX authentication mechanism using EAP entails pointless encapsulation, twice as many messages, unnecessary code bloat from implementation of both client and server EAP state machines (where it had been the case, in RFC 4306, that an implementation only needed to do one), and the introduction of problems that didn't use to exist (like the "lying NAS" problem). The WG added this work item for a very good reason. So how do you think the work item should be solved given that the WG already decided to solve it? What do you think of my draft? Dan. On Mon, May 24, 2010 2:54 pm, Nicolas Williams wrote: > On Mon, May 24, 2010 at 02:50:23PM -0700, Paul Hoffman wrote: >> At 2:07 PM -0700 5/24/10, Dan Harkins wrote: >> > This is out-of-line. >> >> Would it have been less out-of-line if I, the other co-chair wrote it? >> Or if someone who is not a co-chair but understands how the IETF >> process is supposed to work wrote it? >> >> FWIW, I agree with what Yaron wrote. If there is little or no interest >> in advancing this work other than from the authors of the drafts, we >> should strongly consider taking it out of the WG charter. You >> disagree, and others might agree with you or with Yaron. > > Personally I'd much rather that the WG add non-PKIX authentication > mechanism options to IKEv2 via existing frameworks: either EAP or the > GSS-API. > > Nico > -- > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From Nicolas.Williams@oracle.com Mon May 24 17:55: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 01B333A6908 for ; Mon, 24 May 2010 17:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.138 X-Spam-Level: X-Spam-Status: No, score=-4.138 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_50=0.001, 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 Ae0yLtUCV8Q7 for ; Mon, 24 May 2010 17:55:12 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id F2A133A685F for ; Mon, 24 May 2010 17:55:11 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4P0t1tP002575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 May 2010 00:55:03 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4OMmnKP013018; Tue, 25 May 2010 00:55:00 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 264238301274748798; Mon, 24 May 2010 17:53:18 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 May 2010 17:53:18 -0700 Date: Mon, 24 May 2010 19:53:14 -0500 From: Nicolas Williams To: Dan Harkins Message-ID: <20100525005313.GY9605@oracle.com> References: <4BFADC66.3030902@gmail.com> <1efd1968902681a735f0f3083b2c3066.squirrel@www.trepanning.net> <20100524215455.GV9605@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4BFB1FE7.013C:SCFMA922111,ss=1,fgs=0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Beginning the PAKE selection process 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, 25 May 2010 00:55:13 -0000 On Mon, May 24, 2010 at 04:41:59PM -0700, Dan Harkins wrote: > We discussed this in the WG. The non-PKIX authentication mechanism > using EAP entails pointless encapsulation, twice as many messages, > unnecessary code bloat from implementation of both client and server > EAP state machines (where it had been the case, in RFC 4306, that an > implementation only needed to do one), and the introduction of problems > that didn't use to exist (like the "lying NAS" problem). The WG added > this work item for a very good reason. Allow me to quote myself: > On Mon, May 24, 2010 2:54 pm, Nicolas Williams wrote: > > Personally I'd much rather that the WG add non-PKIX authentication > > mechanism options to IKEv2 via existing frameworks: either EAP or the > > GSS-API. I didn't say it has to be EAP; I named an alternative. The GSS-API is far, far simpler. For an example see SCRAM (draft-ietf-sasl-scram) (specifically see the section on SCRAM as a GSS-API mechanism). (Plus a GSS->EAP mechanism bridge is certainly feasible as well.) For your mechanism it'd be even simpler because you'd not be trying to describe in two different ways at the same time. SCRAM was designed as both, a GSS-API mechanism, and as a SASL mechanism that is functionally equivalent to SCRAM-the-GSS-API- mech-used-as-a-SASL-"GS2"-mech ("GS2" is a framework for adapting GSS-API mechanisms as SASL mechanisms). Of course, I'd also point out that SCRAM is the way it is precisely because we had two camps: one that thought the GSS-API overly complex and one that thought it pointless to define SCRAM as a SASL mechanism but not as a GSS-API mechanism. We found a very happy medium by constructing a GSS->SASL mechanism bridge that was simple, added no round-trips and which allowed us to describe SCRAM in two equivalent ways. You might find the same is possible here, both with regard to EAP and with regard to the GSS-API. You might also find our logic in the SASL WG appealing here as well: surely you want your mechanism to be useable in more than just this one context (IKEv2)!, and surely you don't want to have to define new bindings for it to every application protocol! By defining your mechanism as a GSS-API mechanism, for example, you'd get support for the same mechanism in SSHv2, NFSv4, etcetera, almost for free. > So how do you think the work item should be solved given that the WG > already decided to solve it? What do you think of my draft? I've not read it yet. I don't think it'd make much difference to the matter at hand. Nico -- From yaronf.ietf@gmail.com Tue May 25 02:20: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 4CFAA3A6A2E for ; Tue, 25 May 2010 02:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 MrGFV4mhhfhk for ; Tue, 25 May 2010 02:19:55 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 4F8323A6935 for ; Tue, 25 May 2010 02:19:55 -0700 (PDT) Received: by fxm6 with SMTP id 6so104324fxm.31 for ; Tue, 25 May 2010 02:19: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:subject:content-type :content-transfer-encoding; bh=Myw0lOCQ3NfRsAIXVjQzgcrmxOxrVusncZYb3lNxeR8=; b=f3YY90vhx4dvZ+RZ5eCFSNbcblBrRy4Gy5ayHagkDw0d3kjiLbV8CXkAiixzP7zIwJ zu6vk15sagHuWNhDMUjgpEcBjPdCnsnw2pYf6smxzXal7J15OTmOPywGsY3f2h8XwN9V +vSKEj0ZPILM9tF+PiiKHO1VCu/vaH5w9zHMA= 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=qIKjakLOKUeL3yBytArIeXf2UzRGE1ev/ndwEsDiIptYRXDX7KvGLDT+lGvUeRraKb olTnNnNhRcL8dcNBhgR4s6DXSy4Mqj7eFKT+2W7I7pbR606gIAsoXgQzKqnncZlUHtq7 bQwAIdUK511i44CPwUUjppiZfEYXdozQ3KXYA= Received: by 10.223.21.215 with SMTP id k23mr5848663fab.54.1274779180002; Tue, 25 May 2010 02:19:40 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-45-8.red.bezeqint.net [79.178.45.8]) by mx.google.com with ESMTPS id j23sm23914855faa.2.2010.05.25.02.19.38 (version=SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 02:19:39 -0700 (PDT) Message-ID: <4BFB9629.1010000@gmail.com> Date: Tue, 25 May 2010 12:19:37 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] PAKE Selection: HUSH 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, 25 May 2010 09:20:01 -0000 Per Paul's request, here is an evaluation of the HUSH proposal (http://tools.ietf.org/html/draft-sheffer-ipsecme-hush-00) according to Dan's criteria draft. Comments and questions are more than welcome. In summary, HUSH is an adaptation of Bellovin's and Merritt's Encrypted Key Exchange (EKE) protocol into IKEv2. As such, it benefits from the two major advantages associated with EKE: - EKE was published in 1992 and since then has had very extensive, published, review by eminent cryptographers. Although some protocol variants described in the original paper were broken, the variant we are using has been repeatedly analyzed and is believed secure to this day. - EKE was promptly patented by AT&T. However the patent is due to expire by Oct. 2, 2011, which is probably around the time we can get the RFC published. In other words, the IPR situation is crystal clear and rather advantageous. To save you the trouble (:-), I consider the protocol's two main disadvantages to be: - The protocol has never been proven secure, while more recent protocols were designed with formal security proof in mind. - Due to its cryptographic structure, new MODP DH groups have to be defined; EC groups are not supported, at least not currently. And now to the criteria: SEC1: The protocol is based on a zero-knowledge proof. It is resistant to passive attack, active attack, and off-line dictionary attack. SEC2: The protocol supports perfect forward secrecy and protection against the Denning-Sacco attack. SEC3: The protocol does not require the loss of identity protection afforded by IKEv2 today. However if the WG so prefers, HUSH can be modified to eliminate one round trip at the cost of identity protection. SEC4: The protocol does not constrain the "crypto agility" of IKEv2. It must not require fixed and unchangeable cryptographic primitives or Diffie-Hellman groups. HUSH does define its own selection of DH groups, which provides crypto agility for this portion as well (see MISC5 below). SEC5: The base protocol (i.e. EKE) has received very extensive review. e.g. Patel's paper of 1997 and others. It has not been proven secure. SEC6: This feature (deriving a long term shared credential, so that the password does not need to be reused) is not specified in HUSH but would be a simple change. SEC7: A one-way hash of the password can be stored, instead of the cleartext password. IPR1: The EKE protocol was published by Bellovin and Merritt in 1992. IPR2: US patent 5,241,599 for EKE was filed Oct. 2, 1991, and issued Aug. 31, 1993. It is due to expire Oct. 2, 2011. IPR3: I am in the process of filing an IPR statement related to the HUSH draft. I have no idea what licensing policy, if any, Lucent might have regarding this protocol. MISC1: HUSH adds one round trip to the base IKEv2 exchange. This is comparable with or better than the IKEv2-with-EAP alternative. MISC2: Compared with the base IKEv2 exchange, each of the HUSH peers performs two additional exponentiations, and a small number of symmetric crypto operations. MISC3: Performance is independent of the password's length. MISC4: Internationalization of character-based passwords is supported. MISC5: The HUSH protocol defines its own DH groups, which use the same primes as IKE's group, but with different generators. As a result, an equivalent-strength group can be negotiated for each IKE MODP group. Sec. 6.1 of the draft explains the cryptographic motivation and provides an initial list of groups. The use of EC groups with EKE is at the moment unsupported, but may be possible in the future, following a paper by Black and Rogaway. MISC6: HUSH perfectly fits into the request/response nature of IKE. MISC7: The actual use of the protocol needs to be negotiated, and so does the HUSH-specific DH group. MISC8: No need for a trusted third party, nor for clock synchronization. MISC9: The protocol is crypto-agile. To the extent that long-term credential storage requires the use of one-time hash functions, this agility may be harder to implement. But the protocol's strength does *not* depend on the strength of this hash function, simply because guessing the password itself is easier than breaking a hash function, even if it's badly broken. MISC10: As noted above, at the moment only MODP groups are supported. MISC11: The related EAP-EKE (http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-06) was implemented by two students as a term project. I do not expect any particular difficulties in implementing HUSH. Thanks, Yaron From yaronf.ietf@gmail.com Tue May 25 09:54: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 13CE93A6C78 for ; Tue, 25 May 2010 09:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 4PncX9PTuo3M for ; Tue, 25 May 2010 09:54:45 -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 2D3B43A6DA9 for ; Tue, 25 May 2010 09:54:42 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1881179fgb.13 for ; Tue, 25 May 2010 09:54:23 -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:references:in-reply-to :content-type:content-transfer-encoding; bh=BmaizvU/aApVaR//Vf1Ej2tV1GyQUvYf/grArSj4sxQ=; b=BpUOsnscBwhdPHl+3WWEpWgO1yeBMFPiHus/tai3z6S5pU9Fr9py9ErAZm7ocC+zNx d+sF/6ue8MdMWdCyToyil52Z281ycszmVZ/61Fu5AU3vkBoeecNu3v0vDCQoPFy6mWSt CFXKwck6+G6udu2nUrpsjBjFjEMFKGOdzFIRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Sge1nbzEPsl8RGbL3WYXqobpkj4IWwN5vXrzFOatdRXwi7tNd7pKPsEIeWRsnCUSju CByDnf9qRnVRFmKrvIbu6doqEaXqDmHDWFGC3Yx8nFB17o0cK7GIwEPqpy5hp06Zqa+X EWdY23g2jQRRm0tmYA9Uz5UQr9ym7mk9OH79Y= Received: by 10.86.124.35 with SMTP id w35mr10903378fgc.49.1274806463220; Tue, 25 May 2010 09:54:23 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-45-8.red.bezeqint.net [79.178.45.8]) by mx.google.com with ESMTPS id 13sm7708868fks.30.2010.05.25.09.54.21 (version=SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 09:54:21 -0700 (PDT) Message-ID: <4BFC00BB.5030207@gmail.com> Date: Tue, 25 May 2010 19:54:19 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG References: <4BFB9629.1010000@gmail.com> In-Reply-To: <4BFB9629.1010000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] PAKE Selection: HUSH 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, 25 May 2010 16:54:46 -0000 Following up on my previous mail, the IPR statement for HUSH is now available as https://datatracker.ietf.org/ipr/1324/. Thanks, Yaron On 05/25/2010 12:19 PM, Yaron Sheffer wrote: > Per Paul's request, here is an evaluation of the HUSH proposal > (http://tools.ietf.org/html/draft-sheffer-ipsecme-hush-00) according to > Dan's criteria draft. Comments and questions are more than welcome. > > In summary, HUSH is an adaptation of Bellovin's and Merritt's Encrypted > Key Exchange (EKE) protocol into IKEv2. As such, it benefits from the > two major advantages associated with EKE: > > - EKE was published in 1992 and since then has had very extensive, > published, review by eminent cryptographers. Although some protocol > variants described in the original paper were broken, the variant we are > using has been repeatedly analyzed and is believed secure to this day. > > - EKE was promptly patented by AT&T. However the patent is due to expire > by Oct. 2, 2011, which is probably around the time we can get the RFC > published. In other words, the IPR situation is crystal clear and rather > advantageous. > > To save you the trouble (:-), I consider the protocol's two main > disadvantages to be: > > - The protocol has never been proven secure, while more recent protocols > were designed with formal security proof in mind. > > - Due to its cryptographic structure, new MODP DH groups have to be > defined; EC groups are not supported, at least not currently. > > And now to the criteria: > > SEC1: The protocol is based on a zero-knowledge proof. It is resistant > to passive attack, active attack, and off-line dictionary attack. > > SEC2: The protocol supports perfect forward secrecy and protection > against the Denning-Sacco attack. > > SEC3: The protocol does not require the loss of identity protection > afforded by IKEv2 today. However if the WG so prefers, HUSH can be > modified to eliminate one round trip at the cost of identity protection. > > SEC4: The protocol does not constrain the "crypto agility" of IKEv2. It > must not require fixed and unchangeable cryptographic primitives or > Diffie-Hellman groups. HUSH does define its own selection of DH groups, > which provides crypto agility for this portion as well (see MISC5 below). > > SEC5: The base protocol (i.e. EKE) has received very extensive review. > e.g. Patel's paper of 1997 and others. It has not been proven secure. > > SEC6: This feature (deriving a long term shared credential, so that the > password does not need to be reused) is not specified in HUSH but would > be a simple change. > > SEC7: A one-way hash of the password can be stored, instead of the > cleartext password. > > IPR1: The EKE protocol was published by Bellovin and Merritt in 1992. > > IPR2: US patent 5,241,599 for EKE was filed Oct. 2, 1991, and issued > Aug. 31, 1993. It is due to expire Oct. 2, 2011. > > IPR3: I am in the process of filing an IPR statement related to the HUSH > draft. I have no idea what licensing policy, if any, Lucent might have > regarding this protocol. > > MISC1: HUSH adds one round trip to the base IKEv2 exchange. This is > comparable with or better than the IKEv2-with-EAP alternative. > > MISC2: Compared with the base IKEv2 exchange, each of the HUSH peers > performs two additional exponentiations, and a small number of symmetric > crypto operations. > > MISC3: Performance is independent of the password's length. > > MISC4: Internationalization of character-based passwords is supported. > > MISC5: The HUSH protocol defines its own DH groups, which use the same > primes as IKE's group, but with different generators. As a result, an > equivalent-strength group can be negotiated for each IKE MODP group. > Sec. 6.1 of the draft explains the cryptographic motivation and provides > an initial list of groups. The use of EC groups with EKE is at the > moment unsupported, but may be possible in the future, following a paper > by Black and Rogaway. > > MISC6: HUSH perfectly fits into the request/response nature of IKE. > > MISC7: The actual use of the protocol needs to be negotiated, and so > does the HUSH-specific DH group. > > MISC8: No need for a trusted third party, nor for clock synchronization. > > MISC9: The protocol is crypto-agile. To the extent that long-term > credential storage requires the use of one-time hash functions, this > agility may be harder to implement. But the protocol's strength does > *not* depend on the strength of this hash function, simply because > guessing the password itself is easier than breaking a hash function, > even if it's badly broken. > > MISC10: As noted above, at the moment only MODP groups are supported. > > MISC11: The related EAP-EKE > (http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-06) was > implemented by two students as a term project. I do not expect any > particular difficulties in implementing HUSH. > > Thanks, > Yaron From yaronf.ietf@gmail.com Tue May 25 11:14: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 0F1E63A6987 for ; Tue, 25 May 2010 11:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 wBLcEuRM9jci for ; Tue, 25 May 2010 11:14:52 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 95A023A6998 for ; Tue, 25 May 2010 11:14:48 -0700 (PDT) Received: by fxm6 with SMTP id 6so590257fxm.31 for ; Tue, 25 May 2010 11:14: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:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=LelLnAgdiqndH7jZ+8B1MNgsuvOLnXz782qGfC02yVI=; b=fV59dvjQFSjmdChrtRlXQwkgZldGN605b8TC4N4Nqja8jLORSqD6HEcfcaOb4Wq0qG CWFYiOx2ObKC2r2dPIDXqqs9ICScPaHjZxT9FB1d6JOaFepRwetTvQHUr27FOxkEBFgP sYHD08GgX/uixjbYy3tGYzzg9HERoDBop9S2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=jAQiWqrtbRN4LKQ8qh88Ke7ofnVetlBtRej5BrjqXFu15h4Gp1qAaibos7qdAe4BEK aOUdnohmwNuuL9FX+f1OpMM4DoiauM987W2razqIBdn33Ylz+51ypG5m0pyzkSJJbdHe nk3w2z08AVLlS4/ebs//DgRqKoIwvalhSi9VY= Received: by 10.223.144.77 with SMTP id y13mr6848995fau.86.1274811273471; Tue, 25 May 2010 11:14:33 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-45-8.red.bezeqint.net [79.178.45.8]) by mx.google.com with ESMTPS id r25sm25902418fai.11.2010.05.25.11.14.31 (version=SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 11:14:32 -0700 (PDT) Message-ID: <4BFC1384.2030905@gmail.com> Date: Tue, 25 May 2010 21:14:28 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG References: <4BEFEAE6.2060700@gmail.com> In-Reply-To: <4BEFEAE6.2060700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 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, 25 May 2010 18:14:55 -0000 With 5 more days to go, this is a quick reminder to review the problem statement draft so we can move it along, and get to the juicy protocol stuff. This time around, we will take silence as agreement. Thanks, Yaron On 05/16/2010 03:53 PM, Yaron Sheffer wrote: > This is to begin a 2 week working group last call for > draft-ietf-ipsecme-ipsec-ha-03 > (http://tools.ietf.org/html/draft-ietf-ipsecme-ipsec-ha-03). The target > status for this document is Informational. > > Please send your comments to the ipsec list by May 30, 2010, as > follow-ups to this message. > > Brief comments of the form: "I have read this draft and it looks fine" > are also welcome. > > Quick heads up: this is a requirements definition draft. Once we have > determined consensus around it, we would like to move forward with > solutions. Individual solution drafts are welcome as usual, but we would > like to establish at some point a design team to hash out a common > solution document. Let us know by private mail if you're interested. > > Thanks, > Yaron From Nicolas.Williams@oracle.com Tue May 25 15:37: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 B27463A75FB for ; Tue, 25 May 2010 15:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 8pvz4V6568VI for ; Tue, 25 May 2010 15:37:05 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5D4FF3A7736 for ; Tue, 25 May 2010 14:26:55 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PLQUQ5002510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 May 2010 21:26:33 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PKmMMZ022938; Tue, 25 May 2010 21:26:28 GMT Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 297552211274822683; Tue, 25 May 2010 14:24:43 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 May 2010 14:24:43 -0700 Date: Tue, 25 May 2010 16:24:38 -0500 From: Nicolas Williams To: Paul Hoffman Message-ID: <20100525212438.GL9605@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090208.4BFC408A.0118:SCFMA922111,ss=1,fgs=0 Cc: IPsecme WG Subject: Re: [IPsec] Beginning the PAKE selection process 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, 25 May 2010 22:37:06 -0000 A thought about PAKEs and ZKPPs... In the SASL space we pursued a DIGEST-MD5-like mechanism. Yup, SCRAM is vulnerable to off-line dictionary attacks by passive attackers. Except that SCRAM is intended to be used with channel binding to TLS, with confidentiality protection from the same TLS channel, and with TLS authenticating the server (with PSK, PKIX server certs, doesn't matter how). The only difference between the SCRAM-with-channel-binding-to-TLS approach and a ZKPP is this: with a ZKPP there's no need to separatly authenticate the server, which means there's no need to deploy a PKI or Kerberos, nor pre-share certs or keys. That's pretty nice. With the SCRAM-with-cb approach you don't really have to deploy a server authentication infrastructure nor pre-share server authentication material if you're willing to take a chance on initial attempts: you can just optimistically learn server authentication material on success. On failure you can warn the user to call a helpdesk to reset their password. Yeah, that's not as good as what you get with a ZKPP, but still pretty good. In practice most customer who'd use a ZKPP would be happy enough to deploy a server authentication infrastructure in the form of a PKI or pre-shared certs. And, they're very likely to want two-factor user authentication in the form of a user cert (possibly on a smartcard) and a password. In the latter case ZKPPs add little value: at best a round-trip optimization relative to the SCRAM-with-cb approach. The SCRAM-with-cb approach in IKEv2 would look as follows: first do an ephemeral-ephemeral DH key exchange, then authenticate the server with a CERT, then do a GSS-API context establishment with channel binding to the DH key exchange. Just a thought! Nico -- From Nicolas.Williams@oracle.com Tue May 25 17:41: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 199B13A68F3 for ; Tue, 25 May 2010 17:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Us6Dj0JZ8ipL for ; Tue, 25 May 2010 17:41:50 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0D8C33A6A9B for ; Tue, 25 May 2010 16:22:38 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PNMQfd004467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 May 2010 23:22:28 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PM8od2013665; Tue, 25 May 2010 23:22:26 GMT Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 267947971274829665; Tue, 25 May 2010 16:21:05 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 May 2010 16:21:04 -0700 Date: Tue, 25 May 2010 18:21:00 -0500 From: Nicolas Williams To: Paul Hoffman Message-ID: <20100525232100.GP9605@oracle.com> References: <20100525212438.GL9605@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100525212438.GL9605@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090205.4BFC5BB4.020A:SCFMA922111,ss=1,fgs=0 Cc: IPsecme WG Subject: Re: [IPsec] Beginning the PAKE selection process 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, 26 May 2010 00:41:52 -0000 On Tue, May 25, 2010 at 04:24:38PM -0500, Nicolas Williams wrote: > A thought about PAKEs and ZKPPs... I should also mention that the benefits of the SCRAM-with-cb approach: a) simplicity (doesn't get much simpler!), b) this is completely unencumbered to the best of my knowledge[*]. The one downside is, as I described, the need to separately authenticate the server to avoid sending material that is suitable for off-line dictionary attacks to active attackers. In practice this is easy to deal with. [*] SCRAM is based on DIGEST-MD5, which, to the best of my knowledge is unencumbered and has had a fruitful deployment store. Channel binding goes back to the early 90s (92, I believe) and, to the best of my knowledge, is also unencumbered. Nico -- From dennis.kuegler@bsi.bund.de Wed May 26 04:37: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 671683A6861 for ; Wed, 26 May 2010 04:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 AMGmPDUNVa0Y for ; Wed, 26 May 2010 04:37:44 -0700 (PDT) Received: from m4-bn.bund.de (m4-bn.bund.de [77.87.228.76]) by core3.amsl.com (Postfix) with ESMTP id 1D1963A68E9 for ; Wed, 26 May 2010 04:37:43 -0700 (PDT) Received: from m4.mfw.bn.ivbb.bund.de (localhost [127.0.0.1]) by m4-bn.bund.de (8.13.8/8.13.8) with ESMTP id o4QBbWt6007556 for ; Wed, 26 May 2010 13:37:32 +0200 (CEST) Received: (from localhost) by m4.mfw.bn.ivbb.bund.de (MSCAN) id 4/m4.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Wed May 26 13:37:31 2010 X-Virus-Scanned: by amavisd-new at bsi.bund.de From: Dennis =?utf-8?q?K=C3=BCgler?= Organization: BSI Bonn To: IPsecme WG Date: Wed, 26 May 2010 13:37:14 +0200 User-Agent: KMail/1.9.10 (enterprise35 20100401.1112527) MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201005261337.14090.dennis.kuegler@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.1.242; VDF: 7.10.7.177; host: sgasmtp2.bsi.de); id=21301-5eQRv7 Subject: [IPsec] PAKE selection: PACE 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, 26 May 2010 11:37:45 -0000 The evaluation of the PACE proposal according to the criteria draft is already contained in the draft itself (http://www.ietf.org/id/draft-kuegler-ipsecme-pace-ikev2-00.txt) for completeness and for convenience you'll find a copy below. PACE was designed to avoid existing patents (and is not patented) and to allow for implementations without any cryptographic restrictions other than that the primitives have to be secure on their own. A proof of the security of the protocol is available. PACE is currently used and standardized in the context of contactless smartcards, especially for electronic passports and ID-cards. The OpenPACE project also provides a patch to implement PACE on top of OpenSSL. Best regards, Dennis SEC1: PACE is a zero knowledge protocol. SEC2: The protocol supports perfect forward secrecy and is resistant to replay attacks. SEC3: The identity protection provided by IKEv2 remains unchanged. SEC4: Any cryptographically secure Diffie-Hellman group can be used. SEC5: The protocol is proven secure in the Bellare-Pointcheval- Rogaway model. SEC6: Strong session keys are generated. SEC7: A transform of the password can be used instead of the password itself. IPR1: The first draft of [TR03110] was published on May 21, 2007. IPR2: BSI has developed PACE aiming to be free of patents. BSI has not applied for a patent on PACE. IPR3: The protocol itself is believed to be free of IPR. MISC1: One additional exchange is required. MISC2: The protocol requires the following operations per entity: o one key derivation from the password, o one symmetric encryption or decryption, o one multi-exponentiation for the mapping, o one exponentiation for the key pair generation, o one exponentiation for the shared secret calculation, and o two symmetric authentications (generation & verification). MISC3: The performance is independent of the type/size of password. MISC4: Internationalization of character-based passwords is supported. MISC5: The protocol uses the same group as negotiated for IKEv2. MISC6: The protocol fits into the request/response nature of IKE. MISC7: The password-based symmetric encryption must be additionally negotiated. MISC8: Neither trusted third parties nor clock synchronization are required. MISC9: Only general cryptographic primitives are required. MISC10: Any secure variant of Diffie Hellman (e.g. standard or Elliptic Curve) can be used. MISC11: The protocol can be implemented easily based on existing cryptographic primitives. From dennis.kuegler@bsi.bund.de Wed May 26 05:19: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 80DC33A68F5 for ; Wed, 26 May 2010 05:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 Bjo5YBJ8gZER for ; Wed, 26 May 2010 05:19:26 -0700 (PDT) Received: from m2-bn.bund.de (m2-bn.bund.de [77.87.228.74]) by core3.amsl.com (Postfix) with ESMTP id 240863A68E9 for ; Wed, 26 May 2010 05:19:25 -0700 (PDT) Received: from m2.mfw.bn.ivbb.bund.de (localhost [127.0.0.1]) by m2-bn.bund.de (8.13.8/8.13.8) with ESMTP id o4QCJEWa013329 for ; Wed, 26 May 2010 14:19:14 +0200 (CEST) Received: (from localhost) by m2.mfw.bn.ivbb.bund.de (MSCAN) id 4/m2.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Wed May 26 14:19:14 2010 X-Virus-Scanned: by amavisd-new at bsi.bund.de From: Dennis =?iso-8859-1?q?K=FCgler?= Organization: BSI Bonn To: ipsec@ietf.org Date: Wed, 26 May 2010 14:18:56 +0200 User-Agent: KMail/1.9.10 (enterprise35 20100401.1112527) References: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> In-Reply-To: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201005261418.56567.dennis.kuegler@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.1.242; VDF: 7.10.7.177; host: sgasmtp2.bsi.de); id=21808-265Vwx Subject: Re: [IPsec] PAKE selection: SPSK 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, 26 May 2010 12:19:29 -0000 I finally had some time to have a look at your proposal and the evaluation. Please find some initial comments below. - The design of SPSK is very close to SPEKE. It is based on the computation of a (secret) group generator from a shared password. SPEKE is patented and it looks like the patent is also applicable to SPSK. If not please indicate why not. - "Dragonfly is secure and has received cryptographic review". Please provide a reference to the cryptographically reviewed document. - The construction used for computing the group generator is susceptible to side channel (timing) attacks and may leak the shared password. I'd therefore recommend to replace the randomized search algorithm by a deterministc algorithm. Best regards, Dennis > Hi, > > To kick off the PAKE selection discussion I'd like to tout one of > the candidate protocols. It is based on the dragonfly key exchange > and is described in draft-harkins-ipsecme-spsk-auth. Variants of > dragonfly have been proposed for IEEE 802.11 and as an EAP method. > > The aforementioned draft contains a complete description of how > to add dragonfly to IKE(v2), including the additional payloads > needed, their construction and processing, their format, and how they > fit into IKE(v2). While complete it isn't rigid; things (like the way > this exchange is indicated) can change without affecting security. > > I think the best way to start the discussion is to run through the > enumerated selection criteria from draft-harkins-ipsecme-pake-criteria. > > SEC1: dragonfly is based on a zero knowledge proof. It is resistant > to passive, active, and (off-line) dictionary attack. > SEC2: the PFS characteristics of IKE and its resistance to the > Denning-Sacco attack are unchanged by inclusion of this authentication > method. Dragonfly generates a shared key that has the properties of > PFS and it is resistant to the Denning-Sacco attack but the generated > key is used only for authentication. > SEC3: the dragonfly exchange happens after IKE(v2)'s Diffie-Hellman > key exchange and the subsequent payloads, including the ID payloads, > are protected by a derivative of the resulting key. ID protection is > not affected. > SEC4: the protocol does not effect the "crypto agility" of IKE(v2). It > uses the same Diffie-Hellman group that IKE(v2) uses, uses the same > prf+() construct, and can use the negotiated MAC in HMAC form. No > additional primitives (special modes of encryption, for example) are > needed. > SEC5: dragonfly has received cryptographic review in its other > instantiations (IEEE 802.11 and EAP) and is secure. A proof of > security in the Random Oracle model is underway but has not been > finished. > SEC6: the way dragonfly has been added to IKE(v2) is for authentication > of the exchange in which it resides only. Since dragonfly is key > generating though, it is possible to use it to parlay the weak secret > into a long-term credential. > SEC7: a secret element, based on the password, in the selected group > is used in the exchange. That element can be stored instead of the > password to resist exposure of the password in the case of compromise. > > IPR1: dragonfly was first publicly disclosed in January of 2008. > IPR2: dragonfly was invented by me but I did not patent it nor did > my employer at the time of invention. It is believed to be patent-free. > IPR3: no IPR disclosure to the IETF has been made because one is not > needed. > > MISC1: dragonfly adds one roundtrip to IKEv2 and to IKEv1's Main Mode. > It turns IKEv1's Aggressive Mode from a three message exchange to > a four message exchange. > MISC2: dragonfly requires three "scalar operations", point multiplication > for ECC or modular exponentiation for MODP. Basically, a "Diffie- > Hellman and a half". > MISC3: the nature of the shared secret (password, passphrase, long > random octet string) does not affect performance. > MISC4: internationalization can be supported as evidenced by the EAP > method employing the dragonfly exchange. > MISC5: dragonfly can use any of the ECP and MODP groups defined in the > IANA registry for IKE(v2). EC2N groups are disallowed because of > patent concerns and a desire to make implementation of dragonfly be > license free. There is no technical reason, though, why EC2N groups > couldn't be used. > MISC6: the protocol fits nicely into IKE(v2)'s request/response nature. > One single request and response is added and additional information > is piggy-backed on the final request and response in IKE(v2) already. > MISC7: no additional negotiation is needed: no new groups, no new > ciphers, no new cipher modes, no key wrapping. > MISC8: dragonfly does not require trusted third parties nor does it > require any clock synchronization. > MISC9: dragonfly requires use of an HMAC instantiation of a hash > algorithm. The current specification uses this as a "random function". > Another instantiation of dragonfly uses an HMAC'd hash function in > "extractor" and "expander" roles, effectively defining two roles for > the single random function. This can easily be done for IKE(v2) too. > MISC10: the protocol supports the use of elliptic curve cryptography. > MISC11: dragonfly is easily implemented. A reference implementation of > the IEEE 802.11 variant is a Source Forge project named "authsae". > It requires APIs for ECC and MODP operations found in most modern > crypto libraries (e.g. OpenSSL). > > Dragonfly is easy to implement, license/royalty/patent free, has > modest overhead, and fits easily into IKE(v2). I believe the current > manner in which it has been added to IKE(v2) is fine but it can be > changed if implementation concerns require it. Dragonfly is secure and > has received cryptographic review. It does not require any additional > group definitions and, aside from an HMAC'd hash algorithm, does not > require additional use of any other cryptographic primitives like > ciphers. It does not require any specific cipher modes (e.g. CBC or ECB) > nor does it prohibit any (e.g. a stream cipher or a block cipher being > used as a stream cipher). It is completely "crypto agile". I believe it is > the best candidate to meet the requirements laid out in the new charter. > > I solicit comments and questions on this proposal. > > regards, > > Dan. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From jeanmichel.combes@gmail.com Wed May 26 06:22: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 C35363A6943 for ; Wed, 26 May 2010 06:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 0S9Af9SH2Qhg for ; Wed, 26 May 2010 06:22:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 971B83A6960 for ; Wed, 26 May 2010 06:22:27 -0700 (PDT) Received: by wye20 with SMTP id 20so2275498wye.31 for ; Wed, 26 May 2010 06:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dXyLPvNfMqXyzpjiX3qM9rdP4BXSUi6ulg9/MSoCn9U=; b=MXarJJB0bo+Vz7QVSAZXcD/PXY5PbgWMeHWt4jKy7eu+r2QZiiNCADfqSi+qhqTChI svUWIqFVyLyZS2JiryRAtdKfXh8UjfXZPbMv5Qt9VEr4CZ2h8kGUjkGZShPW8LSgWJ6Z 1CDx4ZP7FJnffvs9bzakpAbjqgW+QvRdLBoqo= 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:content-transfer-encoding; b=grc8CinBV7yerFuW66gSAPZBZAVdjTUPH3OewXXc9guQGIfE3fZJutGtcSN1u1z1pR DK8fTzgwpJsnfBrNR05wIKvlESbEmCrK2ChS68SLzoGsDP5RrvU0MjaP/6P+OzpMEfKE nDLpclhATdTNHJvh4C2wprtw+fMGGJsQvjsl4= MIME-Version: 1.0 Received: by 10.216.171.139 with SMTP id r11mr5522524wel.31.1274880127638; Wed, 26 May 2010 06:22:07 -0700 (PDT) Received: by 10.216.161.72 with HTTP; Wed, 26 May 2010 06:22:07 -0700 (PDT) In-Reply-To: <4BFC1384.2030905@gmail.com> References: <4BEFEAE6.2060700@gmail.com> <4BFC1384.2030905@gmail.com> Date: Wed, 26 May 2010 15:22:07 +0200 Message-ID: From: Jean-Michel Combes To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsecme WG Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 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, 26 May 2010 13:22:32 -0000 Hi, please, find my review of this document: 1. Introduction IKEv2, as described in [RFC4306] and [RFC4718], and IPsec, as described in [RFC4301] and others, allows deployment of VPNs between different sites as well as from VPN clients to protected networks. Instead of mentioning [RFC4306) and [RFC4718], maybe replace with [draft-ietf-ipsecme-ikev2bis]? [snip] 2. Terminology [snip] "Failover" is the event where a one member takes over some load from some other member. In a hot standby cluster, this hapens when a standby memeber becomes active due to a failure of the former active s/memeber/member [snip] 3. The Problem Statement I didn't see anything about potential collisions (e.g. SPI for a specific SA on a member of the cluster is already used on another member) during a failover: is such an issue out of scope? Thanks in advance for your reply. Best regards. JMC. 2010/5/25 Yaron Sheffer : > With 5 more days to go, this is a quick reminder to review the problem > statement draft so we can move it along, and get to the juicy protocol > stuff. > > This time around, we will take silence as agreement. > > Thanks, > =A0 =A0 =A0 =A0Yaron > > On 05/16/2010 03:53 PM, Yaron Sheffer wrote: >> >> This is to begin a 2 week working group last call for >> draft-ietf-ipsecme-ipsec-ha-03 >> (http://tools.ietf.org/html/draft-ietf-ipsecme-ipsec-ha-03). The target >> status for this document is Informational. >> >> Please send your comments to the ipsec list by May 30, 2010, as >> follow-ups to this message. >> >> Brief comments of the form: "I have read this draft and it looks fine" >> are also welcome. >> >> Quick heads up: this is a requirements definition draft. Once we have >> determined consensus around it, we would like to move forward with >> solutions. Individual solution drafts are welcome as usual, but we would >> like to establish at some point a design team to hash out a common >> solution document. Let us know by private mail if you're interested. >> >> Thanks, >> Yaron > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Wed May 26 09:34: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 C9AA13A68BB for ; Wed, 26 May 2010 09:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, 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 UlhKD6RoO6AE for ; Wed, 26 May 2010 09:34:46 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id B15D73A687C for ; Wed, 26 May 2010 09:34:46 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9B53F1022404C; Wed, 26 May 2010 09:34:37 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 26 May 2010 09:34:37 -0700 (PDT) Message-ID: In-Reply-To: <201005261418.56567.dennis.kuegler@bsi.bund.de> References: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> <201005261418.56567.dennis.kuegler@bsi.bund.de> Date: Wed, 26 May 2010 09:34:37 -0700 (PDT) From: "Dan Harkins" To: Dennis =?iso-8859-1?Q?K=FCgler?= 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] PAKE selection: SPSK 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, 26 May 2010 16:34:47 -0000 Hi Dennis, On Wed, May 26, 2010 5:18 am, Dennis Kügler wrote: > I finally had some time to have a look at your proposal and the > evaluation. > Please find some initial comments below. > > - The design of SPSK is very close to SPEKE. It is based on the > computation of > a (secret) group generator from a shared password. SPEKE is patented and > it > looks like the patent is also applicable to SPSK. If not please indicate > why > not. You don't mention any specific claim from the SPEKE patent so let me address the first independent claim (there are many claims dependent on that one). The patent I'm referring to is US 6,792,533 dated Sept 14, 2004. The claim says: "A cryptographic method for providing authentication, comprising: providing a password-based value to a first party and a second party; selecting a parameter based on said password-based value, said parameter defining one of a plurality of unauthenticated key distribution techniques; generating by said first party, in cooperation with said second party, a cryptographic key based on said one of the plurality of unauthenticated key distribution techniques, wherein said second party cooperates in generating said cryptographic key by using said one of the plurality of unauthenticated key distribution techniques defined by said first value; and providing authentication of said first party to said second party based on said cryptographic key." Now first of all, that is very broadly worded. Every password-based protocol provides a password to the first party and second party. But there's more to this claim so SPEKE doesn't cover every single protocol that distributes and uses passwords. The next part talks about selecting a parameter based on the password value and dragonfly certainly does that but the important part of this portion of the claim, and the following part of the claim, is the "plurality of unauthenticated key distribution techniques". What is that? There are different kinds of public key distribution systems where there is a "private key" and a "public key" which is based on the "private key". Earlier in the descriptive portion of the patent (which is not part of a claim but can be used to interpret a claim) it says "SPEKE can also use other unauthenticated public-key distribution systems, such as the Modified Diffie-Hellman" and goes on to show an example of that. I don't believe that the Modified D-H alone comprises a "plurality of unauthenticated key distribution techniques." I would also imagine that a static-ephemeral D-H or a static-static D-H that used a password-derived parameter to perform that particular type of unauthenticated key distribution technique would probably be covered. What is common on all these unauthenticated key distribution techniques is how a public key based on the private key is distributed to the other party. The private key is communicated in an obfuscated form based on the discrete logarithm problem-- e.g. pub = g^priv mod p. That is not done in dragonfly. In dragonfly the private key is obfuscated by adding it to a random number modulus the order of the group. The random number is unmasked in a fashion that gives the private key to the second party in a form that does not let it know the private key. Such a technique is new and novel and not part of any known "plurality of unauthenticated key distribution techniques". So it is my contention that for this claim to apply then both a password-based parameter must be used AND that password-based parameter must be used with a known technique of unauthenticated key distribution. It is not and this claim does not apply to dragonfly. If it was not claim 1 that you were referring to above then please say exactly what claim in the SPEKE patent you are talking about. > - "Dragonfly is secure and has received cryptographic review". Please > provide > a reference to the cryptographically reviewed document. Both the IEEE 802.11 TGs Draft and the EAP-pwd variant have been reviewed. > - The construction used for computing the group generator is susceptible > to > side channel (timing) attacks and may leak the shared password. I'd > therefore > recommend to replace the randomized search algorithm by a deterministc > algorithm. I had a discussion about that. The IEEE 802.11 TGs Draft had a password element created based on the password before the exchange started (it was computed a configuration time when a particular group was selected). Then, when the exchange started the identities of the two parties were run through the random function and used in the "scalar-op" to derive a pair-wise unique element with which to do dragonfly. This would foil the side channel attack. But I was convinced that this was not so important and eliminated the extra step to provide ease of analysis. If you think this is important the SPSK draft could certainly introduce this technique to get around a side channel attack. I'm not so sure how important that is though (basically I was convinced it's not so important). If you know I can find a solution to the curve the first time you can eliminate some passwords from the pool of potential passwords but you don't know which ones unless you have run them all through the algorithm beforehand. And even if you have run all possible password through the algorithm it certainly doesn't leak the shared password, it just allows the attacker to eliminate some passwords from the pool of potential passwords. And to do so this attack has to be mounted and that is not a trivial attack. regards, Dan. From dharkins@lounge.org Wed May 26 10:29: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 9ED5D3A67A6 for ; Wed, 26 May 2010 10:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, 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 xeTJtbZBYLCz for ; Wed, 26 May 2010 10:29:54 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id B1AC23A6979 for ; Wed, 26 May 2010 10:29:54 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 88F7B1022404C; Wed, 26 May 2010 10:29:45 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 26 May 2010 10:29:46 -0700 (PDT) Message-ID: <8a7891f3e8674b766ae45a2c51ed1578.squirrel@www.trepanning.net> In-Reply-To: <201005261337.14090.dennis.kuegler@bsi.bund.de> References: <201005261337.14090.dennis.kuegler@bsi.bund.de> Date: Wed, 26 May 2010 10:29:46 -0700 (PDT) From: "Dan Harkins" To: Dennis =?iso-8859-1?Q?K=C3=BCgler?= User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG Subject: Re: [IPsec] PAKE selection: PACE 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, 26 May 2010 17:29:55 -0000 Hi Dennis, I have read the PACE submission. I believe claim 1 of the SPEKE patent, US 6,792,533, covers this protocol. If you do think otherwise, please explain why. Also, in PACE you compute CIPH=E(Pwd, s) where E() is the encryption function of some block cipher and Pwd is the shared password. You don't mention the block cipher but some block ciphers have weak keys and most take a fixed-length key. For a general specification like this I suggest strengthening it by removing any kind of dependencies and also to bind the parties to the exchange. I suggest using an "extraction" function with the shared password and the identities of the two peers to distill the entropy from the password, bind the identities, and derive a key with which to do the encryption: k = Extractor(Pwd | max(ID-A, ID-B) | min(ID-A, ID-B)) CIPH = E(k, s) where max(x,y) and min(x,y) output an ordering their inputs in some deterministic fashion, ID-A and ID-B are the identities of the two parties to the exchange, and "|" is concatenation. regards, Dan. On Wed, May 26, 2010 4:37 am, Dennis Kügler wrote: > The evaluation of the PACE proposal according to the criteria draft is > already > contained in the draft itself > (http://www.ietf.org/id/draft-kuegler-ipsecme-pace-ikev2-00.txt) for > completeness and for convenience you'll find a copy below. > > PACE was designed to avoid existing patents (and is not patented) and to > allow > for implementations without any cryptographic restrictions other than that > the primitives have to be secure on their own. A proof of the security of > the > protocol is available. > > PACE is currently used and standardized in the context of contactless > smartcards, especially for electronic passports and ID-cards. The OpenPACE > project also provides a patch to implement PACE on top of OpenSSL. > > Best regards, > > Dennis > > > SEC1: PACE is a zero knowledge protocol. > SEC2: The protocol supports perfect forward secrecy and is > resistant to replay attacks. > SEC3: The identity protection provided by IKEv2 remains unchanged. > SEC4: Any cryptographically secure Diffie-Hellman group can be > used. > SEC5: The protocol is proven secure in the Bellare-Pointcheval- > Rogaway model. > SEC6: Strong session keys are generated. > SEC7: A transform of the password can be used instead of the > password itself. > > IPR1: The first draft of [TR03110] was published on May 21, 2007. > IPR2: BSI has developed PACE aiming to be free of patents. BSI has > not applied for a patent on PACE. > IPR3: The protocol itself is believed to be free of IPR. > > MISC1: One additional exchange is required. > MISC2: The protocol requires the following operations per entity: > o one key derivation from the password, > o one symmetric encryption or decryption, > o one multi-exponentiation for the mapping, > o one exponentiation for the key pair generation, > o one exponentiation for the shared secret calculation, and > o two symmetric authentications (generation & verification). > MISC3: The performance is independent of the type/size of password. > MISC4: Internationalization of character-based passwords is > supported. > MISC5: The protocol uses the same group as negotiated for IKEv2. > MISC6: The protocol fits into the request/response nature of IKE. > MISC7: The password-based symmetric encryption must be additionally > negotiated. > MISC8: Neither trusted third parties nor clock synchronization are > required. > MISC9: Only general cryptographic primitives are required. > MISC10: Any secure variant of Diffie Hellman (e.g. standard or > Elliptic Curve) can be used. > MISC11: The protocol can be implemented easily based on existing > cryptographic primitives. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Thu May 27 00:03: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 810A83A68D6 for ; Thu, 27 May 2010 00:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=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 cC79VnJdTewu for ; Thu, 27 May 2010 00:03:22 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id D93D33A6843 for ; Thu, 27 May 2010 00:03:21 -0700 (PDT) X-CheckPoint: {4BFE258E-0-1B201DC2-1FFFF} 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 o4R73App022722; Thu, 27 May 2010 10:03:10 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 27 May 2010 10:03:36 +0300 From: Yoav Nir To: "'Jean-Michel Combes'" , Yaron Sheffer Date: Thu, 27 May 2010 10:03:35 +0300 Thread-Topic: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 Thread-Index: Acr81pTzYVMtNqmLT8WNAvhMJ6gHEwAAW8Eg Message-ID: <006FEB08D9C6444AB014105C9AEB133FB48F1B5B14@il-ex01.ad.checkpoint.com> References: <4BEFEAE6.2060700@gmail.com> <4BFC1384.2030905@gmail.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="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 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, 27 May 2010 07:03:23 -0000 1. I didn't want to make ha-03 dependent on bis, but since bis is now appro= ved, we may as well do it. 2. OK 3. It should be out of scope, because this is internal to the cluster. We a= re not going to require a peer to accept having two SAs with the same SPIs = with the same peer, so it's up to the members to prevent this using their o= wn out-of-scope method. It is possible to mention this and then say that it= 's out of scope, if people think this is necessary.=20 Yoav -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of J= ean-Michel Combes Sent: Wednesday, May 26, 2010 4:22 PM To: Yaron Sheffer Cc: IPsecme WG Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 Hi, please, find my review of this document: 1. Introduction IKEv2, as described in [RFC4306] and [RFC4718], and IPsec, as described in [RFC4301] and others, allows deployment of VPNs between different sites as well as from VPN clients to protected networks. Instead of mentioning [RFC4306) and [RFC4718], maybe replace with [draft-ietf-ipsecme-ikev2bis]? [snip] 2. Terminology [snip] "Failover" is the event where a one member takes over some load from some other member. In a hot standby cluster, this hapens when a standby memeber becomes active due to a failure of the former active s/memeber/member [snip] 3. The Problem Statement I didn't see anything about potential collisions (e.g. SPI for a specific SA on a member of the cluster is already used on another member) during a failover: is such an issue out of scope? Thanks in advance for your reply. Best regards. JMC. 2010/5/25 Yaron Sheffer : > With 5 more days to go, this is a quick reminder to review the problem > statement draft so we can move it along, and get to the juicy protocol > stuff. > > This time around, we will take silence as agreement. > > Thanks, > =A0 =A0 =A0 =A0Yaron > > On 05/16/2010 03:53 PM, Yaron Sheffer wrote: >> >> This is to begin a 2 week working group last call for >> draft-ietf-ipsecme-ipsec-ha-03 >> (http://tools.ietf.org/html/draft-ietf-ipsecme-ipsec-ha-03). The target >> status for this document is Informational. >> >> Please send your comments to the ipsec list by May 30, 2010, as >> follow-ups to this message. >> >> Brief comments of the form: "I have read this draft and it looks fine" >> are also welcome. >> >> Quick heads up: this is a requirements definition draft. Once we have >> determined consensus around it, we would like to move forward with >> solutions. Individual solution drafts are welcome as usual, but we would >> like to establish at some point a design team to hash out a common >> solution document. Let us know by private mail if you're interested. >> >> Thanks, >> Yaron > > _______________________________________________ > 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 ynir@checkpoint.com Thu May 27 01:36: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 94C713A68A2 for ; Thu, 27 May 2010 01:36:12 -0700 (PDT) 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=1.300, 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 1TAmevLlxjQ8 for ; Thu, 27 May 2010 01:36:11 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id E7AE43A67FF for ; Thu, 27 May 2010 01:36:10 -0700 (PDT) X-CheckPoint: {4BFE3B4E-0-1B201DC2-1FFFF} 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 o4R8Zxpp006268; Thu, 27 May 2010 11:35:59 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 27 May 2010 11:36:25 +0300 From: Yoav Nir To: "'Jean-Michel Combes'" , Yaron Sheffer Date: Thu, 27 May 2010 11:36:24 +0300 Thread-Topic: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 Thread-Index: Acr81pTzYVMtNqmLT8WNAvhMJ6gHEwAoLwOQ Message-ID: <006FEB08D9C6444AB014105C9AEB133FB48F1B5B19@il-ex01.ad.checkpoint.com> References: <4BEFEAE6.2060700@gmail.com> <4BFC1384.2030905@gmail.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: IPsecme WG Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 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, 27 May 2010 08:36:12 -0000 How about the following text? 3.8 Allocation of SPIs SPIs for child and IKE SAs MUST be unique with the same peer. However, i= n a cluster, both members may create SAs and assign SPIs to them, so a=20 collision is possible. We believe that peers should not be required to accept duplicate SPIs for different SAs, and that this needs to be=20 prevented by the cluster members by some out-of-scope method. Yoav -----Original Message----- 3. The Problem Statement I didn't see anything about potential collisions (e.g. SPI for a specific SA on a member of the cluster is already used on another member) during a failover: is such an issue out of scope? From jeanmichel.combes@gmail.com Thu May 27 03:32: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 804983A689D for ; Thu, 27 May 2010 03:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 2XrnOjnKW5Gi for ; Thu, 27 May 2010 03:32:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D6D6F3A6870 for ; Thu, 27 May 2010 03:32:11 -0700 (PDT) Received: by wye20 with SMTP id 20so455919wye.31 for ; Thu, 27 May 2010 03:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V7oUNnxPC9Xj5/oYB+0oglVdLf2EGPVdxihSykvwtGQ=; b=YyWnqAuWZ2j51H8YjZ3Jo8R3TN7270EbzAIoL6E0bEhOc5mD8jrsjFDdvxgDVPoC/t snQ8RLCpfVXqgSpRlAhJeeXy/bEETLQgjgmWIuODtPvoZeRR4RLpOTYEOh3fuSzxynju I7jZNP5lHZcIV+7ZpeUV3smGKgGeMiqE4dlyY= 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:content-transfer-encoding; b=xE+JjQN1mMnf/bG5SuWhTR8c+bYcKl83DqcSsTS5kNzwDxL69frSMvEzovo7et4qVb KvJGqcCMp/XT1cCSmMUmoRHHGPArpTr2VlRjUaIMjmlDkYZWLufH/wb4wBZ2sBldWEO4 V76bxMwNk+WHHbvXNJh4iXaRimC6oSMuNW4og= MIME-Version: 1.0 Received: by 10.227.145.84 with SMTP id c20mr9806759wbv.223.1274956317739; Thu, 27 May 2010 03:31:57 -0700 (PDT) Received: by 10.216.161.72 with HTTP; Thu, 27 May 2010 03:31:57 -0700 (PDT) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB48F1B5B14@il-ex01.ad.checkpoint.com> References: <4BEFEAE6.2060700@gmail.com> <4BFC1384.2030905@gmail.com> <006FEB08D9C6444AB014105C9AEB133FB48F1B5B14@il-ex01.ad.checkpoint.com> Date: Thu, 27 May 2010 12:31:57 +0200 Message-ID: From: Jean-Michel Combes To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsecme WG Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 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, 27 May 2010 10:32:13 -0000 Hi Yoav, 2010/5/27 Yoav Nir : > 1. I didn't want to make ha-03 dependent on bis, but since bis is now app= roved, we may as well do it. OK. > > 2. OK > > 3. It should be out of scope, because this is internal to the cluster. We= are not going to require a peer to accept having two SAs with the same SPI= s with the same peer, so it's up to the members to prevent this using their= own out-of-scope method. It is possible to mention this and then say that = it's out of scope, if people think this is necessary. OK. Thx. Best regards. JMC. > > Yoav > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Jean-Michel Combes > Sent: Wednesday, May 26, 2010 4:22 PM > To: Yaron Sheffer > Cc: IPsecme WG > Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 > > Hi, > > please, find my review of this document: > > 1. =A0Introduction > > =A0 IKEv2, as described in [RFC4306] and [RFC4718], and IPsec, as > =A0 described in [RFC4301] and others, allows deployment of VPNs between > =A0 different sites as well as from VPN clients to protected networks. > > > Instead of mentioning [RFC4306) and [RFC4718], maybe replace with > [draft-ietf-ipsecme-ikev2bis]? > > > [snip] > > 2. =A0Terminology > > [snip] > > =A0 "Failover" is the event where a one member takes over some load from > =A0 some other member. =A0In a hot standby cluster, this hapens when a > =A0 standby memeber becomes active due to a failure of the former active > > > s/memeber/member > > > [snip] > > 3. =A0The Problem Statement > > > I didn't see anything about potential collisions (e.g. SPI for a > specific SA on a member of the cluster is already used on another > member) during a failover: is such an issue out of scope? > > > Thanks in advance for your reply. > > Best regards. > > JMC. > > > 2010/5/25 Yaron Sheffer : >> With 5 more days to go, this is a quick reminder to review the problem >> statement draft so we can move it along, and get to the juicy protocol >> stuff. >> >> This time around, we will take silence as agreement. >> >> Thanks, >> =A0 =A0 =A0 =A0Yaron >> >> On 05/16/2010 03:53 PM, Yaron Sheffer wrote: >>> >>> This is to begin a 2 week working group last call for >>> draft-ietf-ipsecme-ipsec-ha-03 >>> (http://tools.ietf.org/html/draft-ietf-ipsecme-ipsec-ha-03). The target >>> status for this document is Informational. >>> >>> Please send your comments to the ipsec list by May 30, 2010, as >>> follow-ups to this message. >>> >>> Brief comments of the form: "I have read this draft and it looks fine" >>> are also welcome. >>> >>> Quick heads up: this is a requirements definition draft. Once we have >>> determined consensus around it, we would like to move forward with >>> solutions. Individual solution drafts are welcome as usual, but we woul= d >>> like to establish at some point a design team to hash out a common >>> solution document. Let us know by private mail if you're interested. >>> >>> Thanks, >>> Yaron >> >> _______________________________________________ >> 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 jeanmichel.combes@gmail.com Thu May 27 03:33: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 A7E9D3A6870 for ; Thu, 27 May 2010 03:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 t7mKRrBdo7z5 for ; Thu, 27 May 2010 03:33:16 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 9E80C3A6839 for ; Thu, 27 May 2010 03:33:15 -0700 (PDT) Received: by wwb13 with SMTP id 13so50670wwb.31 for ; Thu, 27 May 2010 03:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MElG+FGnWTqgBf0BGzRd/TB8nhg08RxeMvvibtIO9iE=; b=JMsP1VpI01IY3zdEq/uouA0yhQJa/Csd1ya1gMs6P9USKXJQYTBRqvddVWdN6wS2hX bPLC+QzhqqU/SRAq8ADeXRbMCBhOsxLCVdU5jzeOqumFttLtQGbvN3lPeDOBnSKEPVUj DN5gDfIk9oC2EqACCUCBkYiOdT8Qf0iUdAeFQ= 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:content-transfer-encoding; b=ezKhK49n4LQ0AuH+2qjqReQoMfkwZkH8xpUNNlbOm7AAAGoap9ffyXUS+Fs4fI/Df8 fFeY2frwu/PJWQ0UqwVsb3gqJzC4NPLtWR51aYjYXhPBZCzBSV/mlscwdBu1+vTsAU3T a/k0927ohOJ+xmfh5nZXrsnKI8dOTYc10LumM= MIME-Version: 1.0 Received: by 10.216.165.75 with SMTP id d53mr493530wel.76.1274956379741; Thu, 27 May 2010 03:32:59 -0700 (PDT) Received: by 10.216.161.72 with HTTP; Thu, 27 May 2010 03:32:59 -0700 (PDT) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB48F1B5B19@il-ex01.ad.checkpoint.com> References: <4BEFEAE6.2060700@gmail.com> <4BFC1384.2030905@gmail.com> <006FEB08D9C6444AB014105C9AEB133FB48F1B5B19@il-ex01.ad.checkpoint.com> Date: Thu, 27 May 2010 12:32:59 +0200 Message-ID: From: Jean-Michel Combes To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsecme WG Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 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, 27 May 2010 10:33:16 -0000 Hi again, 2010/5/27 Yoav Nir : > How about the following text? > > 3.8 =A0Allocation of SPIs > =A0 SPIs for child and IKE SAs MUST be unique with the same peer. However= , in > =A0 a cluster, both members may create SAs and assign SPIs to them, so a > =A0 collision is possible. We believe that peers should not be required t= o > =A0 accept duplicate SPIs for different SAs, and that this needs to be > =A0 prevented by the cluster members by some out-of-scope method. It's fine for me. Best regards. JMC. > > Yoav > > -----Original Message----- > > > 3. =A0The Problem Statement > > > I didn't see anything about potential collisions (e.g. SPI for a > specific SA on a member of the cluster is already used on another > member) during a failover: is such an issue out of scope? > > > > From kent@bbn.com Thu May 27 07:30: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 51BD83A6B01 for ; Thu, 27 May 2010 07:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 h8CgsyIecM6Z for ; Thu, 27 May 2010 07:30:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6595A3A6B00 for ; Thu, 27 May 2010 07:30:51 -0700 (PDT) Received: from dhcp89-089-244.bbn.com ([128.89.89.244]:49199 helo=[128.89.89.144]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OHe6a-000IQE-Hj; Thu, 27 May 2010 10:30:40 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB48F1B5B19@il-ex01.ad.checkpoint.com> References: <4BEFEAE6.2060700@gmail.com> <4BFC1384.2030905@gmail.com> <006FEB08D9C6444AB014105C9AEB133FB48F1B5B19@il-ex01.ad.checkpoint.com> Date: Thu, 27 May 2010 10:18:23 -0400 To: Yoav Nir From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IPsecme WG Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 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, 27 May 2010 14:30:52 -0000 At 11:36 AM +0300 5/27/10, Yoav Nir wrote: >How about the following text? > >3.8 Allocation of SPIs > SPIs for child and IKE SAs MUST be unique with the same peer. However, in > a cluster, both members may create SAs and assign SPIs to them, so a > collision is possible. We believe that peers should not be required to > accept duplicate SPIs for different SAs, and that this needs to be > prevented by the cluster members by some out-of-scope method. > >Yoav The text above seems rather indirect. How about: 3.8 Allocation of SPIs The SPI associated with each child SA, and with each IKE SA, MUST be unique relative to the peer of the SA. Thus, in the context of a cluster, each cluster member MUST generate SPIs in a fashion that avoids collisions (with other cluster members) for these SPI values. The means by which cluster members achieve this requirement is a local matter, outside the scope of this document. Steve From ynir@checkpoint.com Thu May 27 07:33: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 113D53A6B00 for ; Thu, 27 May 2010 07:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 STr4fAmduGuZ for ; Thu, 27 May 2010 07:33:50 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id BFEB03A6B02 for ; Thu, 27 May 2010 07:33:48 -0700 (PDT) X-CheckPoint: {4BFE8F1D-0-1B201DC2-1FFFF} 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 o4REXYpp005239; Thu, 27 May 2010 17:33:34 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 27 May 2010 17:34:01 +0300 From: Yoav Nir To: "'Stephen Kent'" Date: Thu, 27 May 2010 17:34:00 +0300 Thread-Topic: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 Thread-Index: Acr9qUVIHhuVqzdBSJmbnNarqi8dKQAAFWXw Message-ID: <006FEB08D9C6444AB014105C9AEB133FB48F1B5B25@il-ex01.ad.checkpoint.com> References: <4BEFEAE6.2060700@gmail.com> <4BFC1384.2030905@gmail.com> <006FEB08D9C6444AB014105C9AEB133FB48F1B5B19@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: IPsecme WG Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 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, 27 May 2010 14:33:52 -0000 Works for me. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Thursday, May 27, 2010 5:18 PM To: Yoav Nir Cc: IPsecme WG Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 At 11:36 AM +0300 5/27/10, Yoav Nir wrote: >How about the following text? > >3.8 Allocation of SPIs > SPIs for child and IKE SAs MUST be unique with the same peer. However,= in > a cluster, both members may create SAs and assign SPIs to them, so a > collision is possible. We believe that peers should not be required to > accept duplicate SPIs for different SAs, and that this needs to be > prevented by the cluster members by some out-of-scope method. > >Yoav The text above seems rather indirect. How about: 3.8 Allocation of SPIs The SPI associated with each child SA, and with each IKE SA, MUST be unique relative to the peer of the SA. Thus, in the context of a cluster, each cluster member MUST generate SPIs in a fashion that avoids collisions (with other cluster members) for these SPI values. The means by which cluster members achieve this requirement is a local matter, outside the scope of this document. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From dan.mcdonald@oracle.com Thu May 27 10:16: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 908613A68D7 for ; Thu, 27 May 2010 10:16:23 -0700 (PDT) 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 yttMYAcniODV for ; Thu, 27 May 2010 10:16:22 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A83C93A6B3C for ; Thu, 27 May 2010 10:16:21 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RHGAQl028473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 May 2010 17:16:11 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RHG8aP029839 for ; Thu, 27 May 2010 17:16:08 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 274436871274980549; Thu, 27 May 2010 10:15:49 -0700 Received: from kebe.East.Sun.COM (/129.148.174.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 May 2010 10:15:48 -0700 Date: Thu, 27 May 2010 13:15:45 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20100527171545.GD4547@kebe.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Oracle - Solaris Security (hon. Networking) User-Agent: Mutt/1.5.20 (2009-06-14) X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090203.4BFEA8DC.001C:SCFMA4539811,ss=1,fgs=0 Subject: [IPsec] Invalid transform type in an SA payload - which error? 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, 27 May 2010 17:16:23 -0000 While going over some error cases, we wondered if some miscreant sends us a transform of type PRF in a CHILD_SA or AUTH exchange where the SA payload is clearly intended for a Child SA (e.g. ESP or AH)? Would INVALID_SYNTAX or NO_PROPOSAL_CHOSEN work better here? Thanks, Dan From smoonen@us.ibm.com Thu May 27 10: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 9659A3A6962; Thu, 27 May 2010 10:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_32=1.778, 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 bYaVWdOE9qka; Thu, 27 May 2010 10:30:26 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 62DEA3A67A2; Thu, 27 May 2010 10:30:26 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o4RHQ0FA022005; Thu, 27 May 2010 11:26:00 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o4RHTqPL043664; Thu, 27 May 2010 11:29:56 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o4RHTmfP000504; Thu, 27 May 2010 11:29:48 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o4RHTl5A000483; Thu, 27 May 2010 11:29:47 -0600 In-Reply-To: <20100527171545.GD4547@kebe.East.Sun.COM> References: <20100527171545.GD4547@kebe.East.Sun.COM> X-KeepSent: D4A92521:2CD20D05-85257730:005F4D75; type=4; name=$KeepSent To: Dan McDonald X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: Scott C Moonen Date: Thu, 27 May 2010 13:29:47 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 05/27/2010 11:29:46 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFDA3DFCCCBE58f9e8a93df938690918c0ABBFDA3DFCCCBE5" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] Invalid transform type in an SA payload - which error? 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, 27 May 2010 17:30:29 -0000 --0__=0ABBFDA3DFCCCBE58f9e8a93df938690918c0ABBFDA3DFCCCBE5 Content-type: multipart/alternative; Boundary="1__=0ABBFDA3DFCCCBE58f9e8a93df938690918c0ABBFDA3DFCCCBE5" --1__=0ABBFDA3DFCCCBE58f9e8a93df938690918c0ABBFDA3DFCCCBE5 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Dan, I think you need to consider the proposal a mismatch against your policy and move to the next proposal. If you find an agreeable one, go= od. If not, NO_PROPOSAL_CHOSEN. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen |------------> | From: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |Dan McDonald = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |------------> | To: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |ipsec@ietf.org = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |------------> | Date: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |05/27/2010 01:17 PM = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |------------> | Subject: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |[IPsec] Invalid transform type in an SA payload - which error? = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| While going over some error cases, we wondered if some miscreant sends = us a transform of type PRF in a CHILD_SA or AUTH exchange where the SA paylo= ad is clearly intended for a Child SA (e.g. ESP or AH)? Would INVALID_SYNTAX or NO_PROPOSAL_CHOSEN work better here? Thanks, Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFDA3DFCCCBE58f9e8a93df938690918c0ABBFDA3DFCCCBE5 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Dan, I think you need to consider the proposal a mismatch against yo= ur policy and move to the next proposal. If you find an agreeable one,= good. If not, NO_PROPOSAL_CHOSEN.


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

3D"InactiveDan McDonald ---05/2= 7/2010 01:17:08 PM---While going over some error cases, we wondered if = some miscreant sends us a

=
3D=
From:		= 3D""
Dan McDonald <dan.mcdonald@oracle.com>
3D=
To:
ipsec@ietf.org
3D=
Date:		= 3D""
05/27/2010 01:17 PM
3D=
Subject:		3D""
[IPsec] Invalid transform type in an SA payload - whic= h error?




While going over some error cases, we wondered if some miscreant se= nds us a
transform of type PRF in a CHILD_SA or AUTH exchange where the SA paylo= ad is
clearly intended for a Child SA (e.g. ESP or AH)?

Would INVALID_SYNTAX or NO_PROPOSAL_CHOSEN work better here?

Thanks,
Dan
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec


= --1__=0ABBFDA3DFCCCBE58f9e8a93df938690918c0ABBFDA3DFCCCBE5-- --0__=0ABBFDA3DFCCCBE58f9e8a93df938690918c0ABBFDA3DFCCCBE5 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFDA3DFCCCBE58f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFDA3DFCCCBE58f9e8a93df938690918c0ABBFDA3DFCCCBE5 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBFDA3DFCCCBE58f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFDA3DFCCCBE58f9e8a93df938690918c0ABBFDA3DFCCCBE5-- From wwwrun@rfc-editor.org Thu May 27 11:27: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 AD7433A6AFB; Thu, 27 May 2010 11:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=1.161, BAYES_00=-2.599, 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 hFhu3Lf385x4; Thu, 27 May 2010 11:27:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id CEE9D3A694E; Thu, 27 May 2010 11:27:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DBC5AE0697; Thu, 27 May 2010 11:26:57 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100527182657.DBC5AE0697@rfc-editor.org> Date: Thu, 27 May 2010 11:26:57 -0700 (PDT) Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 5879 on Heuristics for Detecting ESP-NULL Packets 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, 27 May 2010 18:27:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5879 Title: Heuristics for Detecting ESP-NULL Packets Author: T. Kivinen, D. McDonald Status: Informational Stream: IETF Date: May 2010 Mailbox: kivinen@iki.fi, danmcd@opensolaris.org Pages: 32 Characters: 72917 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-esp-null-heuristics-07.txt URL: http://www.rfc-editor.org/rfc/rfc5879.txt 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 or not a given packet flow is encrypted, i.e., whether or not it can be inspected. Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From paul.hoffman@vpnc.org Thu May 27 11:42: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 9371F3A696B for ; Thu, 27 May 2010 11:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 wHEVWqx5p5EB for ; Thu, 27 May 2010 11:42:45 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CD6F33A684A for ; Thu, 27 May 2010 11:42:45 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4RIgZrT007091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 May 2010 11:42:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 27 May 2010 11:41:34 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] WG document status, late May 2010 edition 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, 27 May 2010 18:42:46 -0000 Greetings again. Yaron and I keep up a page on the WG Wiki with the document status; see . As you can see, we now have five RFCs published, and two more in the RFC Editor's queue (which generally means publication within two months). Of our remaining work items for which there are active drafts: - The Roadmap authors still owe the AD comments; that got delayed by lost mail. - The EAP-only authentication document is in IETF Last Call - The high-availability problem statement document is nearing the end of WG Last Call There are three WG work items from our charter that are not listed are: - The WG is (not actively enough) discussing which PAKE proposal we want the WG to move forwards with - Lost state discovery will be discussed in a little while, after we get settled on PAKE - This discussion of high-availability protocols will be discussed in a little while, after the document has been in IETF Last Call. The energy level in the WG has flagged a bit lately, but as you can see from our status, we have done good work in the past. Please find more energy for the work that we have agreed to take on! --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Fri May 28 06:30:06 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 35B3C3A6861; Fri, 28 May 2010 06:30:02 -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: <20100528133004.35B3C3A6861@core3.amsl.com> Date: Fri, 28 May 2010 06:30:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-roadmap-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: Fri, 28 May 2010 13:30:06 -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 : IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Author(s) : S. Frankel, S. Krishnan Filename : draft-ietf-ipsecme-roadmap-06.txt Pages : 66 Date : 2010-05-28 Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-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-roadmap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-28062650.I-D@ietf.org> --NextPart-- From yaronf.ietf@gmail.com Fri May 28 14:30: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 0550B3A6834 for ; Fri, 28 May 2010 14:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.682, 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 IFG2oMENGFXj for ; Fri, 28 May 2010 14:30:22 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BDE333A67B1 for ; Fri, 28 May 2010 14:30:21 -0700 (PDT) Received: by fxm6 with SMTP id 6so1292832fxm.31 for ; Fri, 28 May 2010 14:30:08 -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:references:in-reply-to :content-type:content-transfer-encoding; bh=GbgfAa2fCdQjjgEH69S4dIU0wRRNwfqTo1dRLz1jfRQ=; b=mghQaG70qEy+56dMKhIGMaTdWv8zZ4ai9H64FM5UiB59Errj+tuhkZjUT9Msnax3NJ Arz69BdEOyKp8kwHr4dkJch0uE4T7PSA5/+SRBzZdBWUJM6J5ol5sEugpcZaHD3HfAcR SQ2ylBpa+1zoTOnwZphKzfTqtyZzZKyu0EUrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Qv9K0xNPIdIKXI7+hJFZq2eBNl8qFGJWDMy2czDHDSidGfEJ02LjVwPxbGQgOd0ZBF Kgrv3tNrcoMhyD5gjHGSRmMNMBT/AS2Qh9Ig+YzLC3Mlw1yAddheweiRnn9DpMSlGUUt KK9PlAR7NPL4H6QE9XQy8l0DTQKVyMhR3MiIg= Received: by 10.223.20.218 with SMTP id g26mr1024177fab.18.1275082208320; Fri, 28 May 2010 14:30:08 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-180-38-209.red.bezeqint.net [79.180.38.209]) by mx.google.com with ESMTPS id z12sm13998109fah.9.2010.05.28.14.30.06 (version=SSLv3 cipher=RC4-MD5); Fri, 28 May 2010 14:30:07 -0700 (PDT) Message-ID: <4C0035DC.5060503@gmail.com> Date: Sat, 29 May 2010 00:30:04 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: ipsec@ietf.org References: <20100528133004.35B3C3A6861@core3.amsl.com> In-Reply-To: <20100528133004.35B3C3A6861@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-roadmap-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: Fri, 28 May 2010 21:30:23 -0000 Hi Suresh and Sheila, thanks for the new revision. As always I appreciate your dedication. My big issue with this rev is: didn't we say that we will retain *only* algorithm requirement levels, in which case Appendix A needs to go? And a smaller, related issue: Some specific items in Appendix A make little sense to me. For example, draft-ietf-ipsecme-ipsec-ha is a problem statement, not a solution. So I don't understand how it can have ANY requirement level at all. Thanks, Yaron On 05/28/2010 04:30 PM, 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 : IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap > Author(s) : S. Frankel, S. Krishnan > Filename : draft-ietf-ipsecme-roadmap-06.txt > Pages : 66 > Date : 2010-05-28 > > Over the past few years, the number of RFCs that define and use IPsec > and IKE has greatly proliferated. This is complicated by the fact > that these RFCs originate from numerous IETF working groups: the > original IPsec WG, its various spin-offs, and other WGs that use > IPsec and/or IKE to protect their protocols' traffic. > > This document is a snapshot of IPsec- and IKE-related RFCs. It > includes a brief description of each RFC, along with background > information explaining the motivation and context of IPsec's > outgrowths and extensions. It obsoletes the previous IPsec Document > Roadmap [RFC2411]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-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 yaronf.ietf@gmail.com Sun May 30 00:07: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 4B2973A67B5 for ; Sun, 30 May 2010 00:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_50=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 bA2mZfP2s8yu for ; Sun, 30 May 2010 00:07:34 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 2DF0B3A6835 for ; Sun, 30 May 2010 00:07:34 -0700 (PDT) Received: by fxm6 with SMTP id 6so1915908fxm.31 for ; Sun, 30 May 2010 00:07:19 -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=Y1kyUnjKa1tVRCzT2QevxYfuF59P5uw/fKC3i5il6mc=; b=J0+BjB1SiUpR4yCJK3aQtX/19OTl5JeVaNqMplVGrVkfJJBCy0dflLKPlyJCaU1Bv8 9pwvOIM7aGq+SEwB8++WQsm1lyvpJb8frOaATyIXzZ1lW4ujDDGl96k4a0jhtjzr57Ar Yu8JbtGCnrd877Ket9lYhub0DNGuVi04BpQts= 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=rDiB7idllfHQwuWqS55iLKfPt4RvxfVdCQnlk/KuAhDyEqyYJgatuAPaGRk7X+knuH SuspID3T2ynQd1PyeMvWY/6hfd89g0B/LjZGdwk5Yrjp6W0f4A3kTOziFfx1FAA+ThUY MH4XjwSrITYBAW/W1dl6O4LEi0GNReOHRPSnk= Received: by 10.223.65.18 with SMTP id g18mr3337836fai.32.1275203239548; Sun, 30 May 2010 00:07:19 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-180-38-209.red.bezeqint.net [79.180.38.209]) by mx.google.com with ESMTPS id z12sm27750319fah.21.2010.05.30.00.07.18 (version=SSLv3 cipher=RC4-MD5); Sun, 30 May 2010 00:07:18 -0700 (PDT) Message-ID: <4C020EA5.5070104@gmail.com> Date: Sun, 30 May 2010 10:07:17 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] draft-ietf-ipsecme-ipsec-ha-03 comment: scope 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, 30 May 2010 07:07:35 -0000 Hi, the charter, when defining the HA work item, specifies a precise scope: "The scope is restricted to mechanism(s) that are visible to the peer, and thus usually require interoperability between vendors. Mixed-vendor clusters, and protocols between the cluster members, are explicitly out of scope of this work item." But this scope is not explicitly delineated in the draft, at least not in one place. So I suggest the following text (I have incorporated the first few paragraphs of sec. 3): 3. Problem Statement This section starts by scoping the problem, and goes on to list each of the issues encountered while setting up a cluster of IPsec VPN gateways. 3.1 Scope - This document will make no attempt to describe the problems in setting up a generic cluster. It describes only problems related to the IKE/IPsec protocols. - The problem of synchronizing the policy between cluster members is out of scope, as this is an administrative issue that is not particular to either clusters or to IPsec. - The interesting scenario here is VPN, whether tunneled site-to-site or remote access. Host-to-host transport mode is not expected to benefit from this work. - We do not describe in full the problems of the communication channel between cluster members (the Synch Channel), nor do we intend to specify anything in this space later. In other words, mixed-vendor clusters are out of scope. - The problem statement anticipates possible protocol-level solutions between IKE/IPsec peers, in order to improve the availability and/or performance of VPN clusters. One vendor's IPsec endpoint should be able to work, optimally, with another vendor's cluster. Thanks, Yaron From paul.hoffman@vpnc.org Sun May 30 08:53: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 2B94B3A68BF for ; Sun, 30 May 2010 08:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 lT+LznCCx2nz for ; Sun, 30 May 2010 08:53:37 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 842033A68A3 for ; Sun, 30 May 2010 08:53: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 hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o4UFrOJ5093585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 30 May 2010 08:53:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4BFC1384.2030905@gmail.com> References: <4BEFEAE6.2060700@gmail.com> <4BFC1384.2030905@gmail.com> Date: Sun, 30 May 2010 08:53:23 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03 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, 30 May 2010 15:53:38 -0000 At 9:14 PM +0300 5/25/10, Yaron Sheffer wrote: >With 5 more days to go, this is a quick reminder to review the problem statement draft so we can move it along, and get to the juicy protocol stuff. So, the WG LC on this document is over today, and I think the authors have heard lots of good input. Let's give them some space to do the -04 (soon, hopefully), and if the changes don't cause any more serious discussion, we can take it to IETF Last Call and then start thinking protocol. --Paul Hoffman, Director --VPN Consortium