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
_______________________________________________