Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication)
Martin Willi <martin@strongswan.org> Mon, 03 May 2010 09:13 UTC
Return-Path: <martin@strongswan.org>
X-Original-To: ipsec@core3.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 <ipsec@core3.amsl.com>; 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 <ipsec@core3.amsl.com>; 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 <ipsec@ietf.org>; 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 <martin@strongswan.org>) id 1O8rhC-0008Hk-LR; Mon, 03 May 2010 11:12:10 +0200
From: Martin Willi <martin@strongswan.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <p06240886c7f51f814274@[10.20.30.158]>
References: <p06240886c7f51f814274@[10.20.30.158]>
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 <ipsec@ietf.org>
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 <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=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", > <http://tools.ietf.org/html/draft-ietf-ipsecme-eap-mutual-01>. 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
- [IPsec] Start of WG Last Call on draft-ietf-ipsec… Paul Hoffman
- Re: [IPsec] Start of WG Last Call on draft-ietf-i… Paul Hoffman
- Re: [IPsec] Start of WG Last Call on draft-ietf-i… Martin Willi
- Re: [IPsec] Start of WG Last Call on draft-ietf-i… Yoav Nir
- Re: [IPsec] Start of WG Last Call on draft-ietf-i… Yaron Sheffer
- Re: [IPsec] Start of WG Last Call on draft-ietf-i… Yaron Sheffer
- Re: [IPsec] Start of WG Last Call on draft-ietf-i… Andreas Steffen