[anonsec] not so recent comments ...

[Stephen Kent]

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