Re: [anonsec] not so recent comments ...
Stephen Kent <firstname.lastname@example.org> Mon, 14 January 2008 19:44 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEVER-0003pU-LX for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 14:44:27 -0500
Received: from boreas.isi.edu ([184.108.40.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEVEP-0003my-IH for btns-archive-waDah9Oh@lists.ietf.org; Mon, 14 Jan 2008 14:44:27 -0500
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EJSPtW014050; Mon, 14 Jan 2008 11:28:25 -0800 (PST)
Received: from mx12.bbn.com (mx12.bbn.com [220.127.116.11]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EJRKog013915 for <email@example.com>; Mon, 14 Jan 2008 11:27:21 -0800 (PST)
Received: from dommiel.bbn.com ([18.104.22.168] helo=[192.168.0.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <firstname.lastname@example.org>) id 1JEUxr-0006WK-4g; Mon, 14 Jan 2008 14:27:19 -0500
References: <email@example.com> <20080114173719.GI810@Sun.COM>
Date: Mon, 14 Jan 2008 14:27:51 -0500
To: Nicolas Williams <Nicolas.Williams@sun.com>
From: Stephen Kent <firstname.lastname@example.org>
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: email@example.com, 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:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:email@example.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
At 11:37 AM -0600 1/14/08, Nicolas Williams wrote: >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.) Your rationale is better than what David cited. I suggest it be included in a discussion of why EAP is considered inappropriate hhere. >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. yes. > >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). we agree on this issue as well. Steve _______________________________________________