Re: [anonsec] not so recent comments ...
Nicolas Williams <Nicolas.Williams@sun.com> Mon, 14 January 2008 17:51 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JETT9-0003VA-Mn for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 12:51:31 -0500
Received: from boreas.isi.edu ([126.96.36.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JETT8-0000kX-4N for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 12:51:31 -0500
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EHbh94025285; Mon, 14 Jan 2008 09:37:44 -0800 (PST)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [188.8.131.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EHbLTM025131 for <firstname.lastname@example.org>; Mon, 14 Jan 2008 09:37:22 -0800 (PST)
Received: from dm-central-02.central.sun.com ([184.108.40.206]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0EHbL1U024432 for <email@example.com>; Mon, 14 Jan 2008 17:37:21 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [220.127.116.11]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0EHbK4v042753 for <firstname.lastname@example.org>; Mon, 14 Jan 2008 10:37:21 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0EHbKJt004074; Mon, 14 Jan 2008 11:37:20 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0EHbJvH004073; Mon, 14 Jan 2008 11:37:19 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 14 Jan 2008 11:37:19 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Stephen Kent <email@example.com>
Mail-Followup-To: Stephen Kent <firstname.lastname@example.org>, Black_David@emc.com, email@example.com
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: firstname.lastname@example.org, Black_David@emc.com
Subject: Re: [anonsec] not so recent comments ...
List-Id: "Discussions of anonymous Internet security." <anonsec.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:firstname.lastname@example.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
On Mon, Jan 14, 2008 at 11:56:04AM -0500, Stephen Kent wrote: > Your most recent message cited text fro RFC 3748 (EAP) and stated > that the cited text argues against use of EAP with IPsec when the > applications are "bulk data transfer." The reality is that use of EAP > with IKE does happen, as well as in the TLS context, etc. So, given > the widespread use of EAP, this document needs to explain why it is > inapplicable. Your reference to network layer identities seems odd, > as EAP usually makes use of individual IDs. A better rationale is > still needed. RFC348, section 1.3 says: EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. That means that EAP is OK for use in VPN-type IKEv2 uses, but not really for end-to-end uses of IKEv2. BTNS is meant for end-to-end use where "IP layer connectivity" _is_ already available. Ergo EAP is not applicable. The key isn't "bulk data transport" but "network access authentication" and "where IP layer connectivity may not be available." (I.e., I agree with David that EAP is not applicable, but disagree as to why.) If your comment re: EAP is that the BTNS problem and applicability statement needs to be specific as to why other alternatives were rejected, then I agree. W.r.t. use for BGP, VoIP and what not, I do tend to agree that the easiest sells for BTNS are the channel binding and leap-of-faith cases. I've been skeptical of other user cases before, and still am, for in most, if not all the non-channel binding, non-LoF cases there are alternatives that seem relatively low-cost to develop (relative to BTNS). Nico -- _______________________________________________