From: Lakshminath Dondeti [mailto:ldondeti@xxxxxxxxxxxx]
Sent: Wed 4/11/2007 11:03 PM
To: Sam Hartman
Cc: ietf@xxxxxxxx; Bernard Aboba; emu@xxxxxxxx; nicolas.williams@xxxxxxx
Subject: Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Hi Sam,
Here is my take on this topic:
After having reviewed "draft-williams-on-channel-binding-01," I feel
that putting EAP in scope of that document would require a rather
involved revision of the document. As Charles noted it might require
further abstraction of the concept of channel binding as defined in
draft-williams.
Now, I must say, I do see the similarities between the two notions of
channel binding. But the EAP/AAA model is unique and it is not easy to
map it to the other, let's say simpler, security models. The notion of
compound binding or crypto binding also has some similarities to the
notion of channel binding in draft-williams-on-channel-binding-01, but
there are also some differences.
Overall though, since expanding draft-williams-on-channel-binding-01's
scope to EAP means that the requirements, recommendations and
suggestions of Section 2.1 may be applied to EAP channel binding, it
would be a rather painful exercise to sort it all out. For now, I am
comfortable with the guidance in Section 7.15 of 3748.
thanks,
Lakshminath
Sam Hartman wrote:
>
>
> Hi.
>
> For the last couple of years, we've been believing that EAP and GSS
> used the term channel bindings inconsistently. For those of us
> dealing with both, it's been a bit annoying.
>
> I've been thinking about EAP a lot lately. and have come to the
> conclusion that actually the terms are used consistently.
>
> I'd like to see if people agree with the following change to Nico's channel binding draft:
>
> old:
>
> Also unfortunately there is a conflict with the Extensible
> Authentication Protocol (EAP) [RFC3748] which uses "channel binding"
> to refer to a facility that is subtly different from the one
> described here. (It does not seem feasible to adopt new terminology
> to avoid these problems now. The GSS-API, NFSv4 and other
> communities have been using the terms "channel binding" and "channel
> bindings" in these ways for a long time, sometimes with variations
> such as "channel binding facility" and so on.)
>
> new:
>
> The Extensible Authentication Protocol (EAP) [RFC3748] includes two
> facilities related to channel binding. The first, called channel
> binding, is used to bind the lower-layer channel created between the
> peer and the authenticator to the authentication performed using EAP.
> Specific detials of this facility have not been specified, but it is
> likely that this channel would use endpoint channel bindings carried
> in the EAP method exchange. The endpoint channel bindings would be
> defined for the specific lower layer. EAP also has a facility called
> cryptographic binding, which is another instance of channel binding.
> Cryptographic binding refers to binding the channel created by a
> tunneling EAP method to an inner authentication performed within that
> method. Cryptographic binding will likely use unique channel
> bindings.
>
> Do these changes make sense to people? Am I telling any lies or
> conflating two architectures in a bad way?
>
>
> _______________________________________________
> Emu mailing list
> Emu@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/emu
>
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf