[anonsec] not so recent comments ...

[Nicolas Williams]

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
BTNS).

Nico
--