RE: Secure legacy authentication for IKEv2

Paul Hoffman / VPNC <paul.hoffman@vpnc.org> Fri, 20 December 2002 22:43 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKMhFo13596; Fri, 20 Dec 2002 14:43:15 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09295 Fri, 20 Dec 2002 17:16:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05200f06ba29464c91d1@[165.227.249.18]>
In-Reply-To: <C9588551DE135A41AA2626CB6453093738EEFA@WIN-MSG-10.wingroup.windeploy.ntde v.microsoft.com>
References: <C9588551DE135A41AA2626CB6453093738EEFA@WIN-MSG-10.wingroup.windeploy.ntde v.microsoft.com>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Fri, 20 Dec 2002 14:17:12 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: RE: Secure legacy authentication for IKEv2
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

At 12:52 PM -0800 12/20/02, William Dixon wrote:
>Paul, why wasn't an EAP encapsulation chosen in a similar manner as PIC
>?  It seems you are re-inventing EAP types here.  For every new or
>different auth method type, you'd have to define a new one in the IKEv2
>spec.

If we used EAP, we would be susceptible to the man-in-the-middle 
attack described at 
<http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt>. 
The "EAP and EAP-like problem" is being discussed in many places, and 
is one of the things that is holding up PIC as well.

Dan and Derrell decided that the danger of mis-use of EAP was more 
worrisome than the need for automatic extensibility. Note that SLA 
already covers all of the methods that are covered by XAUTH, and 
there haven't been any calls in a quite a while for new XAUTH methods.

--Paul Hoffman, Director
--VPN Consortium