Sam,
In skimming through Nico's draft, it looks like EAP's crypto bindings look
something like GSS channel bindings.
EAP's channel bindings, on the other hand, don't really look like GSS
channel bindings. In order for EAP's channel binding to look like GSS
channel binding, EAP channel binding would have to cryptographically bind
an L2 security association to EAP keys -- but that's not what it's doing.
It's binding L2 identities to EAP keys. In fact, there's no reason it has
to be an L2 identity. It can be any identity that's meaningful to the
parties involved, and can serve as the basis for making authorization
decisions.
Perhaps you could abstract the definition of channel bindings even further
such that all three are subsets of some common terminology... but that
sounds painful.
--
t. charles clancy, ph.d. <> tcc(_at_)umd(_dot_)edu <> www.cs.umd.edu/~clancy
On Fri, April 6, 2007 1:43 pm, 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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf