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
FW: [Emu] Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings
Message accidentally discarded by the moderator. -Original Message- From: Nicolas Williams [mailto:[EMAIL PROTECTED] Sent: Thursday, April 12, 2007 8:10 AM To: Lakshminath Dondeti Cc: [EMAIL PROTECTED]; Sam Hartman; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 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 ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Re: Thoughts on Password-based EAP Methods
Hi Steve, Sorry for jumping late. Internally within the design team and not having followed this thread, I suggested that we could follow the TTLS path in a way that it meets our requirements. The fact that Paul has agreed to give up control of the draft to IETF is really good news, however, I am a bit confused as how the process you suggested will happen, so let me understand this: We publish the current TTLSv0 as an RFC, and we also publish TTLSvX based on the changes EMU does as a separate RFC in a way that it does not deprecate the first one? (sort of like IKEv1 and IKEv2 scenario?) As good as that sounds to me, the not so rhetorical question would be: wouldn't the two versions still get two different method types? BTW, I am hearing that Paul has promised to add EMSK generation to TTLSv0, so may be TTLSv0 is not quite there yet:)? R, Madjid -Original Message- From: Stephen Hanna [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 3:00 PM To: [EMAIL PROTECTED] Subject: [Emu] Re: Thoughts on Password-based EAP Methods Sorry it took me a few days to respond to this thread. I agree with Bernard that there's no benefit in creating Yet Another Password-Based EAP Method (YAPBEM). There's no point in reinventing the wheel for a fourth time and it's not the IETF way. We're not researchers. We're practical engineers who respect running code and rough consensus. So, yes, we should have a bias toward existing, well-tested and well-understood protocols. In a security group, it's especially important to avoid the temptation to reinvent the wheel. We should focus our efforts on one secure tunneled EAP method and make that one secure. We should consider existing methods and only invent something new if we need to. I have spoken to Paul Funk, the primary author of the EAP-TTLSv0 spec. He is glad to proceed as Bernard suggested: 1. Publish an updated EAP-TTLSv0 spec that documents current practice (as Informational or Experimental) 2. Give up change control to the IETF so that the EMU WG can make any necessary changes or additions to EAP-TTLS I'm also glad to assist with this effort, since Paul is pretty busy these days. Thanks, Steve -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 8:07 AM To: [EMAIL PROTECTED] Subject: [Emu] Thoughts on Password-based EAP Methods After listening to the IETF 68 presentation on a password-based EAP method, I would like to voice some concerns. Today we already have an over abundance of such methods. These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions with customers, I invariably hear complaints about this explosion, and about various interoperability and compatibility problems that it causes. Simply put, customers do not want yet another password-based EAP method; they want a single method that is widely implemented and interoperable. I am concerned that by defining yet another password-based authentication mechanism, EMU WG will be making this problem worse, not better. Creating yet another mechanism which differs little from the existing ones also seems to have very little chance of being implemented. There is a better alternative that EMU WG should consider. This is to choose an existing method for inclusion on the IETF Standards Track, rather than creating a new one. In order to maintain backward compatibility, this would require that the owners give up change control to the IETF. I would suggest that the best candidate for this would be EAP-TTLSv0, since it is very widely implemented, and has an existing certification program in WFA. Also, EAP-TTLSv0 had previously been on the Standards Track in the PPPEXT WG, before work on EAP methods was removed from the PPPEXT WG charter and the EAP WG was formed. In terms of steps to be taken, this would require the following actions: a. Review and publication of the existing EAP-TTLSv0 specification as an RFC. The goal here would be to document EAP-TTLSv0 as it exists today. b. Agreement by the authors to give up change control to the IETF. c. EMU WG efforts to publish an EAP-TTLSv0 bis document, specifying additional capabilities (such as Channel Bindings). ___ Emu mailing list Emu at ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu
