Re: [anonsec] not so recent comments ...
Stephen Kent <kent@bbn.com> Mon, 14 January 2008 19:44 UTC
Return-path: <anonsec-bounces@postel.org>
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 ([128.9.160.161]) 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 [128.33.0.81]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m0EJRKog013915 for <anonsec@postel.org>; Mon, 14 Jan 2008 11:27:21 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.101]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1JEUxr-0006WK-4g; Mon, 14 Jan 2008 14:27:19 -0500
Mime-Version: 1.0
Message-Id: <p06240519c3b167c65116@[192.168.0.101]>
In-Reply-To: <20080114173719.GI810@Sun.COM>
References: <p06240512c3b139bc4648@[192.168.0.101]> <20080114173719.GI810@Sun.COM>
Date: Mon, 14 Jan 2008 14:27:51 -0500
To: Nicolas Williams <Nicolas.Williams@sun.com>
From: Stephen Kent <kent@bbn.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: kent@bbn.com
Cc: anonsec@postel.org, Black_David@emc.com
Subject: Re: [anonsec] not so recent comments ...
X-BeenThere: anonsec@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Discussions of anonymous Internet security." <anonsec.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/anonsec>
List-Post: <mailto:anonsec@postel.org>
List-Help: <mailto:anonsec-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: anonsec-bounces@postel.org
Errors-To: anonsec-bounces@postel.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
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 _______________________________________________
- [anonsec] not so recent comments ... Stephen Kent
- Re: [anonsec] not so recent comments ... Nicolas Williams
- Re: [anonsec] not so recent comments ... Stephen Kent