Sam Hartman wrote:
> The more I
> read what you, Bernard and Charles say, the more I'm convinced that I
> agree with your description of EAP and that my text is correct. The
> more I talk, the more you're convinced that my text is wrong.
> We're talking past each other somehow.
I think your text was correct, but incomplete. I think the SAP needs to
be included, as it does channel bindings under Nico's broader
definition. The SAP does an EAP lower-layer to EAP layer binding -- it
just doesn't provide the authorization you're looking for, hence why we
need EAP channel bindings to prevent the lying NAS problem.
Sam's suggested text:
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.
My suggestion for Sam's suggested text:
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.
The Secure Association Protocol (SAP) defined by the EAP lower layer
often binds lower-layer identities and sometimes even AAA identities
into the key derivation, serving to bind EAP keys to the EAP lower
layer. However, as this binding is done by the lower layer, and not
EAP, there is no explicit authorization by the EAP server for the
lower layer to use the EAP keys. Consequently, EAP channel bindings
are defined in RFC 3748 to perform the binding at the EAP layer.
Specific details 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.
--
t. charles clancy, ph.d. | tcc@xxxxxxx | www.cs.umd.edu/~clancy
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf