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

Nicolas Williams <> Mon, 14 January 2008 17:51 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1JETT9-0003VA-Mn for; Mon, 14 Jan 2008 12:51:31 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1JETT8-0000kX-4N for; Mon, 14 Jan 2008 12:51:31 -0500
Received: from (localhost []) by (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 []) by (8.13.8/8.13.8) with ESMTP id m0EHbLTM025131 for <>; Mon, 14 Jan 2008 09:37:22 -0800 (PST)
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id m0EHbL1U024432 for <>; Mon, 14 Jan 2008 17:37:21 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m0EHbK4v042753 for <>; Mon, 14 Jan 2008 10:37:21 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost []) 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 using -f
Date: Mon, 14 Jan 2008 11:37:19 -0600
From: Nicolas Williams <>
To: Stephen Kent <>
Message-ID: <20080114173719.GI810@Sun.COM>
Mail-Followup-To: Stephen Kent <>,,
References: <p06240512c3b139bc4648@[]>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <p06240512c3b139bc4648@[]>
User-Agent: Mutt/1.5.7i
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: 7baded97d9887f7a0c7e8a33c2e3ea1b

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