Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes: I think that having a single abstraction that can describe what went by multiple names in different areas can be very useful because it facilitates cross-area communication. And missing an opportunity to point out how two things are more similar than they look would help perpetuate a perception that those two things are more different than they actually are. Lakshminath I can see your point of view. The other thing to Lakshminath worry about is that the more we try to cover under a Lakshminath single abstraction, the more watered down it might Lakshminath become to satisfy all viewpoints of applicability to Lakshminath all of the domains. In fact, I find the requirements Lakshminath and recommendations in the draft troublesome. Lakshminath As I thought about it, perhaps here is something that Lakshminath might make sense: Lakshminath Define channel binding so that we can cover all uses Lakshminath of that term. Define properties and specify how one Lakshminath can achieve those properties. Not sure this next one Lakshminath needs to be done in the current draft, define which Lakshminath properties apply to which protocol. Alternatively, Lakshminath different protocol drafts may specify which of the Lakshminath properties are required or recommended in each case. Lakshminath Does that make sense? That makes sense; I think that is exactly what we're doing. I continue to believe, having read all the messages here that my original text is very close to correct in describing the EAP channel bindings problems. I'd love to talk to someone off-line to discuss this, because there is some obvious confusion somewhere. 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. ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
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. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu
