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
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 [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu ___ 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
On Mon, April 9, 2007 3:38 pm, [EMAIL PROTECTED] wrote: [snip] I'd define the EAP channel binding problem as follows. There are two sets of identities that the peer and authenticator use: one at the EAP layer and one at a lower layer. There is an additional identity that the authenticator may use to authenticate to the AAA server. The channel binding problem is to make sure that the EAP server authorizes the authenticator's use of the lower layer identity to the peer and the peer's use of a given lower layer identity. I don't agree. The channel binding problem is to make sure the EAP server and the peer agree to whom the key is being disclosed. They have to agree on a common identity that is relevant at the EAP layer. You're right that the authenticator can have 3 identities-- a lower layer identity like a MAC address, a NAS ID, and some identity that was used to create a security association with the AS. The AS doesn't know and doesn't care what the lower layer identity of the authenticator is. Likewise the peer doesn't know and doesn't care what identity the authenticator used to establish a security association with the AS (most likely an IP address). But they are both speaking EAP and there is an identity of the authenticator that they can both agree on and that is relevant at that layer-- the NAS ID. EAP channel binding is a protected exchange, between the peer and AS, of this identity (the NAS ID not a lower layer identity) and the identity passed in the protected exchange is verified with the identity established in some out-of-band fashion (for instance, at provisioning time of the NAS). If they are equal then all systems are go, if they are not then houston we have a problem. Dan. ___ 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
I agree with Lakshminath on this. From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Wed 4/11/2007 11:03 PM To: Sam Hartman Cc: [EMAIL PROTECTED]; Bernard Aboba; [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu ___ 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
On Sat, Apr 07, 2007 at 04:44:54PM -0400, Charles Clancy wrote: This is one of the fundamental issues with EAP channel bindings. The NAS ID is bound to the AAA security association between the authenticator and the EAP server. The MAC address is visible to the client. Thus the peer and EAP server each know a different identity for the authenticator. Whatever identity is used must be channel-bound to the AAA security association, otherwise the authenticator could lie to the EAP server about its identity. I see two solutions: 1. The NAS ID is broadcast to the peer before EAP authentication (e.g. in an 802.11 beacon) This is something that IEEE 802.11r/D5.0 is doing. R0KH-ID is set to the identity of the NAS Client (e.g., NAS-Identifier if RADIUS is used as the backend protocol) and this identifier is sent to the peer during association (before EAP authentication). In addition, both the R0KH-ID (NAS-Identifier) and R1KH-ID (authenticator MAC address) are mixed in into the key derivation after the EAP authentication. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
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.[EMAIL PROTECTED]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@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
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. As long as it's cryptographically bound to the L2 channel and that channel provides suitable protection for the EAP method doing the EAP channel binding, THEN Sam's observation is correct: EAP channel binding uses what I termed end-point channel binding and EAP cryptographic binding uses what I termed unique channel binding. I don't think I'm convinced that EAP channel bindings are doing this binding to the L2 channel. The identity used in an EAP channel binding must be bound to the AAA security association between the authenticator and the peer in order for everything to work, so it would be more likely a NAS-ID than a MAC address. That's not to say there isn't an L2 binding happening -- but I think it's being performed by the L2 secure association phase that uses the EAP key to derive L2 keys. Then during that handshake, a MAC address may be involved, binding in an L2 identity. I guess I see EAP channel bindings as an EAP-AAA binding, and the L2 secure association protocol as the EAP-L2 binding. -- t. charles clancy, ph.d.[EMAIL PROTECTED]www.cs.umd.edu/~clancy ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
