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