Re: [anonsec] not so recent comments ...

Stephen Kent <> Mon, 14 January 2008 19:44 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1JEVER-0003pU-LX for; Mon, 14 Jan 2008 14:44:27 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1JEVEP-0003my-IH for; Mon, 14 Jan 2008 14:44:27 -0500
Received: from (localhost []) by (8.13.8/8.13.8) with ESMTP id m0EJSPtW014050; Mon, 14 Jan 2008 11:28:25 -0800 (PST)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m0EJRKog013915 for <>; Mon, 14 Jan 2008 11:27:21 -0800 (PST)
Received: from ([] helo=[]) by with esmtp (Exim 4.60) (envelope-from <>) id 1JEUxr-0006WK-4g; Mon, 14 Jan 2008 14:27:19 -0500
Mime-Version: 1.0
Message-Id: <p06240519c3b167c65116@[]>
In-Reply-To: <20080114173719.GI810@Sun.COM>
References: <p06240512c3b139bc4648@[]> <20080114173719.GI810@Sun.COM>
Date: Mon, 14 Jan 2008 14:27:51 -0500
To: Nicolas Williams <>
From: Stephen Kent <>
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [anonsec] not so recent comments ...
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Discussions of anonymous Internet security." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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.


>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

we agree on this issue as well.