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: ietf@ietf.org; 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Below are diffs to draft-williams-on-channel-binding-01.txt including: - Alexey Melnikov's IANA text - Fixes to Eric Gray's nits - New text about EAP channel binding - A clarification requested by Sam: this doc describes a generic notion of channel binding, not [just] the GSS-API's Please review and comment. Particularly w.r.t. EAP channel binding. --- on-channel-binding-01.txt +++ on-channel-binding-02.txt @@ -1,18 +1,18 @@ NETWORK WORKING GROUPN. Williams Internet-Draft Sun -Expires: September 6, 2007 March 5, 2007 +Expires: October 18, 2007 April 16, 2007 On the Use of Channel Bindings to Secure Channels -draft-williams-on-channel-binding-01.txt +draft-williams-on-channel-binding-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. @@ -27,17 +27,17 @@ material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 6, 2007. + This Internet-Draft will expire on October 18, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). @@ -47,19 +47,19 @@ -WilliamsExpires September 6, 2007 [Page 1] +WilliamsExpires October 18, 2007[Page 1] -Internet-Draft On Channel BindingsMarch 2007 +Internet-Draft On Channel BindingsApril 2007 Abstract The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to @@ -71,59 +71,59 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 1.1.Conventions used in this document . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . 5 2.1.Properties of channel binding . . . . . . . . . . . . 6 + 2.2.EAP channel binding . . . . . . . . . . . . . . . . . 8 3. Authentication and channel binding semantics . . . . . 9 3.1.The GSS-API and channel binding . . . . . . . . . . . 9 3.2.SASL and channel binding . . . . . . . . . . . . . . . 9 4. Channel bindings specifications . . . . . . . . . . . 11 4.1.Examples of unique channel bindings . . . . . . . . . 11 4.2.Examples of end-point channel bindings . . . . . . . . 11 5. Uses of channel binding . . . . . . . . . . . . . . . 13 6. Benefits of channel binding to secure channels . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . 16 - 8. Security Considerations . . . . . . . . . . . . . . . 17 + 7.1.Registration Procedure . . . . . . . . . . . . . . . . 16 + 7.2.Comments on channel bindings Registrations . . . . . . 17 + 7.3.Change control . . . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . 19 8.1.Non-unique channel bindings and channel binding - re-establishment . . . . . . . . . . . . . . . . . . . 17 - 9. References . . . . . . . . . . . . . . . . . . . . . . 19 - 9.1.Normative References . . . . . . . . . . . . . . . . . 19 - 9.2.Informative References . . . . . . . . . . . . . . . . 19 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 - Author's Address . . . . . . . . . . . . . . . . . . . 23 - Intellectual Property and Copyright Statements . . . . 24 + re-establishment . . . . . . . . . . . . . . . . . . . 19 + 9. References . . . . . . . . . . . . . . . . . . . . . . 21 + 9.1.Normative References . . . . . . . . . . . . . . . . . 21 + 9.2.Informative References . . . . . . . . . . . . . . . . 21 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 24 + Author's Address . . . . . . . . . . . . . . . . . . . 25 + Intellectual Property and Copyright Statements . . . . 26 +WilliamsExpires October 18, 2007
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
On Mon, April 9, 2007 6:38 pm, [EMAIL PROTECTED] wrote: Charles == Charles Clancy [EMAIL PROTECTED] writes: Charles Sam Hartman wrote: Charles == Charles Clancy [EMAIL PROTECTED] writes: Charles I don't think I'm convinced that EAP channel bindings are Charles doing this binding to the L2 channel. The identity used Charles in an EAP channel binding must be bound to the AAA Charles security association between the authenticator and the Charles peer in order for everything to work, so it would be more I'm not sure I'd describe the association between the peer and authenticator as an AAA association. I agree with the rest. Charles Ah, I mistyped. I meant AAA security association between Charles the authenticator and EAP server. 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. In performing this authorization the EAP server must authorize that the authenticator is actually allowed to claim the lower layer identity it wants to claim. I think this is implicit -- you gave the MSK to an authenticator, therefore that authenticator's lower layer (regardless of its identity) is authorized to use that key. Of course, this assumes an authenticator has a single lower layers. I'm not sure the case of multiple lower layers been addressed. EAP could simply forbid it (i.e. one lower layer per authenticator), or say that giving a key to an authenticator authorizes it for all lower layers. In doing that it will have to make an authorization decision about whether the identity the authenticator uses to authenticate to the AAA server is authorized to claim the given lower layer identity. Currently there's no AAA mechanism for an authenticator to claim a lower-layer identity to an EAP server. Lower layer identities would have to be statically provided to the EAP server if the EAP server is going to use them for channel bindings. However that identity--between the NAS and the AAA server doesn't inherently appear anywhere else. It sounds like 802.11R does plan to expose that identity, but that's a design decision for that lower layer. I guess the point of all my commentary is that the SAP needs to be involved in your discussion of EAP channel bindings. Most cryptographically binds an L2 identities to an EAP key, and some new ones (11r) even bind AAA identities to an EAP key. If EAP channel bindings could include AAA identities, then the peer would actually have enough information to start doing identity comparisons and catch lying NASes. -- t. charles clancy, ph.d.[EMAIL PROTECTED]www.cs.umd.edu/~clancy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
On Mon, Apr 16, 2007 at 01:10:32AM -0500, Nicolas Williams wrote: - New text about EAP channel binding Actually, some of that text is incorrect -- I misunderstood the lying NAS issue: it's not about MITM attacks but about making sure that the client knows the correct name for the NAS so that it can make authorization decisions based on it (e.g., applying a specific firewall policy). I'll fix the text and re-send. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
On Fri, Apr 13, 2007 at 07:52:17PM -0400, Charles Clancy wrote: 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: [...] My suggestion for Sam's suggested text: [...] The problem you call the lying NAS problem sounds like nothing other than an MITM attack on the peer: the MITM pretends to be the NAS to the peer and the peer to the real NAS, passing through any other traffic between the peer and the server, and when all is done the lying NAS has had access to all the plaintext that the peer might have sent to or received from the network it connected to. This matches the generic channel binding problem statement quite nicely. The solution that's been described consists of: a) authentication of the NAS to the peer at the lower layer, b) mutual authentication of the peer and the EAP server, c) authentication of the NAS to the EAP server, d) an authorization step where the peer sends the NAS' lower-layer ID to the EAP server and where the EAP server decides whether the NAS that authenticated to it is the same as that which authenticated to the client and e) also decides whether the NAS is allowed to serve the peer. This can be described as a use end-point channel bindings where the application _knows_ that that's the type of channel binding provided by the channel and where the end-point IDs are meaningful to the application (the EAP server in this case). More importantly: step (a) is difficult to arrange. How does one authenticate BSSIDs, MAC addresses, etc.? It would be a lot simpler to have an unauthenticated channel between the peer and the NAS and bind that channel into the peer-EAP server authentication. Thus unique channel bindings too could be used in EAP channel binding. Unless I misunderstood something and the above text is incorrect then I think Sam's text is sufficient. A more detailed description of the EAP channel binding problem and proposed solutions, and an analysis of how that resembles the generic channel binding problem and solutions might help. I would place such text in a sub-section of the introduction. Finally, to address Lakshminath's comments, I would insist that all EAP-related text in this document is and should be informative, and it should be clearly labelled as such. If the EAP community finds this document useful then it can choose to update RFC3748 to include this document as a normative reference. Nico -- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
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. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
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 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
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 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
On Wed, Apr 11, 2007 at 11:03:29PM -0700, Lakshminath Dondeti wrote: 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. My impression was that Sam's suggested text was introductory and informative, and not at all intended to cause this doc to normatively constrain EAP. 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. Nico -- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Hi Nico, Please see inline: Nicolas Williams wrote: On Wed, Apr 11, 2007 at 11:03:29PM -0700, Lakshminath Dondeti wrote: 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. My impression was that Sam's suggested text was introductory and informative, and not at all intended to cause this doc to normatively constrain EAP. The draft is standards track and there is a lot of 2119 language in there. 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. I can see your point of view. The other thing to worry about is that the more we try to cover under a single abstraction, the more watered down it might become to satisfy all viewpoints of applicability to all of the domains. In fact, I find the requirements and recommendations in the draft troublesome. As I thought about it, perhaps here is something that might make sense: Define channel binding so that we can cover all uses of that term. Define properties and specify how one can achieve those properties. Not sure this next one needs to be done in the current draft, define which properties apply to which protocol. Alternatively, different protocol drafts may specify which of the properties are required or recommended in each case. Does that make sense? I know I am suggesting this, but until something like that is written, I am not sure we can get there (haven't put enough thought into whether a common consensus abstraction is possible here or not). As I noted in my review of your draft, EAP model is different from some of the other security models in the IETF. best regards, Lakshminath Nico ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Sam Hartman wrote: Charles == Charles Clancy [EMAIL PROTECTED] writes: Charles I don't think I'm convinced that EAP channel bindings are Charles doing this binding to the L2 channel. The identity used Charles in an EAP channel binding must be bound to the AAA Charles security association between the authenticator and the Charles peer in order for everything to work, so it would be more I'm not sure I'd describe the association between the peer and authenticator as an AAA association. I agree with the rest. Ah, I mistyped. I meant AAA security association between the authenticator and EAP server. Charles likely a NAS-ID than a MAC address. Are you sure that the binding happens between the mac address and NAS ID? I don't understand how the peer ever confirms the NAS ID at layer two unless it also happens to be a MAC address. 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) 2. The EAP server maintains a static mapping between NAS IDs and MAC addresses, manually binding MAC addresses to AAA security associations I do agree with you though that EAP channel bindings include the peer's lower layer identity and the identity of the authenticator that the peer will later be able to verify. Right -- but there needs to be some way for the EAP server to know the authenticator's lower-layer information in such a way that the authenticator can't lie about its lower-layer information to the EAP server. Charles I guess I see EAP channel bindings as an EAP-AAA Charles binding, and the L2 secure association protocol as the Charles EAP-L2 binding. The L2 secure association protocol cannot be an eap-anything binding: it does not typically use EAP level identifiers. It uses EAP keys though. If from a higher layer we know EAP keys could have only been delivered to a particular EAP/AAA identity, and those keys are exported to the lower layer, then I'd think you have a binding from the EAP identity to the EAP keys to the lower-layer keys to the lower-layer identity. -- t. charles clancy, ph.d.[EMAIL PROTECTED]www.cs.umd.edu/~clancy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Charles == Charles Clancy [EMAIL PROTECTED] writes: Charles Sam Hartman wrote: Charles == Charles Clancy [EMAIL PROTECTED] writes: Charles I don't think I'm convinced that EAP channel bindings are Charles doing this binding to the L2 channel. The identity used Charles in an EAP channel binding must be bound to the AAA Charles security association between the authenticator and the Charles peer in order for everything to work, so it would be more I'm not sure I'd describe the association between the peer and authenticator as an AAA association. I agree with the rest. Charles Ah, I mistyped. I meant AAA security association between Charles the authenticator and EAP server. 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. In performing this authorization the EAP server must authorize that the authenticator is actually allowed to claim the lower layer identity it wants to claim. In doing that it will have to make an authorization decision about whether the identity the authenticator uses to authenticate to the AAA server is authorized to claim the given lower layer identity. However that identity--between the NAS and the AAA server doesn't inherently appear anywhere else. It sounds like 802.11R does plan to expose that identity, but that's a design decision for that lower layer. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
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? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
On Fri, Apr 06, 2007 at 02:41:09PM -0400, Charles Clancy wrote: Sam, In skimming through Nico's draft, it looks like EAP's crypto bindings look something like GSS channel bindings. Note: my I-D does not describe GSS channel binding -- it describes channel binding. The reference to GSS channel binding is there as an informative, historical note. 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 ^ When the identities of the two end-points of a channel are: a) cryptographically bound into that channel b) such that other channels between different pairs of end-points could not have the same end-point identities, THEN we can call that pair of channel end-points identities end-point channel bindings -- as my I-D explains. 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. 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. No, I think we did just that, but I had not noticed that, in fact, the two kinds of EAP binding map to the two kinds of channel binding described in my draft. Thanks Sam! Nico -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Sam, Your observation is brilliant. Yes, I agree, EAP channel binding and EAP cryptographic binding map to what my draft calls end-point channel binding and unique channel binding, respectively. I had not noticed this before. Also, I think my draft's definition of end-point channel bidning needs to be tightened just a bit: not only must the end-point IDs be cryptographically bound into the channel, it must also be the case that the IDs meaningfully identify the channel end-points -- that is, that one nodes cannot assert the same ID as another without sharing credentials with it. I think my text implies this but does not make it sufficiently explicit. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Nicolas == Nicolas Williams [EMAIL PROTECTED] writes: Nicolas Also, I think my draft's definition of end-point channel Nicolas bidning needs to be tightened just a bit: not only must Nicolas the end-point IDs be cryptographically bound into the Nicolas channel, it must also be the case that the IDs Nicolas meaningfully identify the channel end-points -- that is, Nicolas that one nodes cannot assert the same ID as another Nicolas without sharing credentials with it. I think my text Nicolas implies this but does not make it sufficiently explicit. Be careful. A DN given a trust anchor seems like a find end-point identifier. However two nodes can share the same DN without sharing the same credential. Under 3280 rules either the CA issued a certificate it should not have issued or the two nodes are the same subject. That's strong enough for the channel binding to be useful even though the nodes may not share a credential. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Charles == Charles Clancy [EMAIL PROTECTED] writes: 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. Charles I don't think I'm convinced that EAP channel bindings are Charles doing this binding to the L2 channel. The identity used Charles in an EAP channel binding must be bound to the AAA Charles security association between the authenticator and the Charles peer in order for everything to work, so it would be more I'm not sure I'd describe the association between the peer and authenticator as an AAA association. I agree with the rest. Charles Charles likely a NAS-ID than a MAC address. Are you sure that the binding happens between the mac address and NAS ID? I don't understand how the peer ever confirms the NAS ID at layer two unless it also happens to be a MAC address. I do agree with you though that EAP channel bindings include the peer's lower layer identity and the identity of the authenticator that the peer will later be able to verify. Charles That's not to say there isn't an L2 binding happening -- Charles but I think it's being performed by the L2 secure Charles association phase that uses the EAP key to derive L2 Charles keys. Then during that handshake, a MAC address may be Charles involved, binding in an L2 identity. ANd if things are secure some L2 identity of the authenticator. Charles I guess I see EAP channel bindings as an EAP-AAA Charles binding, and the L2 secure association protocol as the Charles EAP-L2 binding. The L2 secure association protocol cannot be an eap-anything binding: it does not typically use EAP level identifiers. Charles -- t. charles clancy, ph.d. [EMAIL PROTECTED] Charles www.cs.umd.edu/~clancy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
