Re: [Emu] EMU charter revision
Hi Hao, On Wed, April 30, 2008 9:34 am, Hao Zhou (hzhou) wrote: Dan wrote: The real thing holding up adoption of EAP-pwd as a work item is finishing work on the tunneled method. Which wouldn't be such a bad thing if we were further along towards that goal after Philly than we were after Vancouver and from the looks of it we won't be any further after Dublin than we were after Vancouver. :-( I don't think tunnel method is the real thing holding up the EAP-pw as a work item, so stop attacking the tunnel method or hurry it into some kind of sword fight. As others pointed out, EAP-pw might be quite useful for multiple WGs and should be bring to SAAG. But security review and IPR analysis need to be done before any WG is willing to take that work, I think. Let me quote the chairman of this group, Joe Salowey: The message from the ADs in the last meeting was pretty clear in that EAP-PWD style mechanisms is not something for the group to take on right now. This does not mean that we cannot take on an EAP-PWD style mechanism once we have made progress on the current charter items. And what are the current charter items? GPSK which is getting one last edit before going off to IETF LC and... the tunneled method! So until we have made some progress on the tunneled method the charter cannot change to make EAP-pwd in scope of the group. Let me mention once more I'm not interested in sword fights. Let's call it a beauty contest. And it would be really nice if the contestants would finish their hair-dos and make-up and get into their evening gowns and out on the runway so the winner can get crowned. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU charter revision,
[Joe] Jari had asked to keep this open to TLS. I think he was suggesting it could be done as a TLS extension and would not require tunneling. I agree that we do not want to extend EAP-TLS to do tunneling. How about: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on supporting EAP channel bindings within the tunnel method. The possiblity of adding channel bindings to EAP-TLS through a TLS extension or other standard TLS mechanism may also be investigated. [BA] I think we only want one mechanism for support of channel bindings in TLS-based methods. So it's ok to investigate a TLS extension vs. other mechanisms for supporting channel bindings, but I'd suggest we only want to choose one path. So my suggestion would be to modify the text as follows: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on adding support for EAP channel bindings. Potential mechanisms for addition of support for channel bindings will be investigated, including tunneling of channel binding parameters, or a TLS extension or other standard TLS mechanism. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU charter revision,
I like Bernard's text better. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard Aboba Sent: Wednesday, April 30, 2008 7:54 PM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: Re: [Emu] EMU charter revision, [Joe] Jari had asked to keep this open to TLS. I think he was suggesting it could be done as a TLS extension and would not require tunneling. I agree that we do not want to extend EAP-TLS to do tunneling. How about: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on supporting EAP channel bindings within the tunnel method. The possiblity of adding channel bindings to EAP-TLS through a TLS extension or other standard TLS mechanism may also be investigated. [BA] I think we only want one mechanism for support of channel bindings in TLS-based methods. So it's ok to investigate a TLS extension vs. other mechanisms for supporting channel bindings, but I'd suggest we only want to choose one path. So my suggestion would be to modify the text as follows: - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will focus on adding support for EAP channel bindings. Potential mechanisms for addition of support for channel bindings will be investigated, including tunneling of channel binding parameters, or a TLS extension or other standard TLS mechanism. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU charter revision
Hi Joe, I don't see much wrong with EAP-GTC, and I may end up using it for legacy RADIUS support, But there are two arguments against using it. 1. The typical deployment of an IKE gateway is that there's a RADIUS or LDAP server somewhere in the internal network or even on another network in the case of a branch office gateway. EAP is usually forwarded to that server. If the forwarded payload is GTC, it's something malicious (perhaps on the internal network) might sniff it and get the password. 2. There is a threat scenario described in http://eprint.iacr.org/2002/163 . The idea is that a client that does EAP-GTC will do it both in a secure tunnel (such as in IKEv2) and outside of a secure tunnel (such as 802.1x). Someone sniffing the 802.1x will be able to acquire the password. This sounds simplistic to me, but more realistically, if IKEv2 (or even more so - TLS) is authenticated with a password, it may be tempting, as Dan pointed out, to uncheck the verify server certificate because we're authenticating with a certificate. IOW, the user is actually authenticating to the RADIUS server, which tells the gateway that the user is authenticated. Since the gateway can't authenticate the user on its own, it makes sense that the client can't authenticate the gateway on its own. The RADIUS server sends the MSK to the gateway and the gateway sends a PoP to the client, and that is the proof the client has that the gateway is authentic. But for this to work, you need an EAP method that (1) generates keys, and (2) mutually authenticates the client and server. These are required in the IKEv2 RFC. Tunneling a method like EAP-GTC gives you the keys and the mutual authentication but it requires that the client be able to verify the server certificate, and it requires that the tunneling go all the way to the server, rather than GTC going to the server, while the tunnel terminates at the gateway. It still takes a lot of round trips to get it to work, and a non-tunneled method like EAP-SRP or EAP-pwd would probably be better suited. Yoav On Apr 28, 2008, at 9:41 PM, Joseph Salowey (jsalowey) wrote: Hi Yoav, You bring up an interesting point in discussing the need for EAP password based authentication within other protected protocols. If this is targeted at working with legacy databases then I think it can be accommodated under the current charter. An EAP protected tunnel is required for some deployments, however perhaps the tunneled password protocol can be designed to be used in other cases (IKEv2, TLS, etc.) if the group wants to take this direction. What do you see lacking in something like EAP-GTC? Cheers, Joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yoav Nir Sent: Monday, April 28, 2008 5:13 AM To: emu@ietf.org Subject: Re: [Emu] EMU charter revision Gene Chang said: Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method? Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term snail race is a pejorative. Thus I ask you, how do we do better? I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me. Gene Hi Gene, You did not specify what the uses that interest you are, and I don't know about the use cases that interest Dan either, but I can speak for the use cases that interest me. EAP has been used in several cases as a magic way to use legacy credentials in protocols. I'll cite three examples: 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, Cisco and others, where an EAP method is used to authenticate the user. 2. IKEv2 (RFC 4306) where EAP is used to magically authenticate the initiator using non-cert and non-PSK credentials. 3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate the user. In all three cases EAP is used by a protocol inside an encrypted tunnel, where the server, which is either trusted by the authenticator or co-located with it is already authenticated by a certificate or PSK. IMO EAP was used in all cases an some magical way of making passwords into a secure authentication mechanism. The problem is that there really is no publicly available EAP method for passwords. Tunneled methods don't really make sense here. There's no benefit in putting a TLS tunnel inside an IKEv2 exchange just to pass the password
Re: [Emu] EMU charter revision,
In re-reading this charter, I still don't think we're quite there: a. Why is there still a charter item for EAP-TLS? This work hasbeen completed, no? b. Attempting to extend EAP-TLS to support tunneling or channel bindings is not appropriate. EAP-TLS already widely deployed, with large investments in conformance tests. Given the number of existing TLS-based tunneling protocols, such a work item would serve no useful purpose. Let's focus on adding channel binding support to tunnel methods. c. To some extent, I agree with Dan and Yoav with respect to the need for password-based methods. Had such methods been availableearlier, it's questionable whether TLS tunneling would have takenoff to the extent that it has. Also, I think that such methods, if specified in the IETF, would be likely to be widely deployed. However, on the other hand I think that this is really an issue for the entire security area, not just for EMU. So I'd suggest that this issue be brought up in SAAG. =Below is a revision to the EMU charter that is intended to reflect thediscussions in the Philadelphia meeting. Please respond to the list ifyou approve of the charter or if you have any comments on the charter.I would like to have responses by 4/24. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU charter revision
Hold on a second there Hao. A security proof was never a requirement. I'm not aware of any other IETF protocols that required security proofs or even have security proofs. There is no formal proof required of the tunneled methods and I think it would be very difficult to do one. One of the problems with the tunneled solution is the consistency principle described in Hugo Krawczyk's SIGMA paper. The tunneled methods violate that security requirement. And the fact that these things can be repeatedly tunneled ad nauseum amplifies that violation. A use case? Surely you have noticed the friction between usability and security. Security needs bootstrapping of some sort and typically that is problematic for many people especially when they need to bootstrap a large number of distinct security associations. So they cut corners. How are these corners cut? Do not verify server certificate. That's why that little check box exists. Because people don't want to enroll everybody/everything into a CA. So they use a self-signed certificate and check the Do not verify server certificate check box. And then they send a password over this encrypted tunnel. So the use case is robust security that cannot be provisioned insecurely. It's scalable and doesn't require the cutting of corners by administrators who are too busy (or frankly lazy) to do it the Correct Way. I have used the it's their network and if they aren't so concerned about security then who am I to force a workload on them comments in the past but it really is disingenuous. There are frightfully many deployments of password-authentication-through- encrypted-TLS-tunnel that use self-signed certificates and then something analogous to PAP. And they are done that way because there isn't a viable standard alternative. That is the use case for EAP-pwd. Oh, and it can satisfy the consistency principle too. :-) Dan. On Mon, April 28, 2008 8:10 am, Hao Zhou (hzhou) wrote: Yoav: I thought we had clear consensus in IETF 71 WG meeting and instructed by the AD that while Dan's proposal is an interesting one, but it doesn't work with the legacy password databases and thus out-of the scope of the charter. Until we have the proof of security analysis and clear of IPR issues, the WG is going to work on the tunnel method. I think this is the use case, legacy password database, the working group is currently working on and Gene is talking about Can you also explain why in the three use case you cited, EAP-GTC or MD5 doesn't meet the requirements, as they are all running inside an authenticated and encrypted tunnel? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yoav Nir Sent: Monday, April 28, 2008 8:13 AM To: emu@ietf.org Subject: Re: [Emu] EMU charter revision Gene Chang said: Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method? Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term snail race is a pejorative. Thus I ask you, how do we do better? I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me. Gene Hi Gene, You did not specify what the uses that interest you are, and I don't know about the use cases that interest Dan either, but I can speak for the use cases that interest me. EAP has been used in several cases as a magic way to use legacy credentials in protocols. I'll cite three examples: 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, Cisco and others, where an EAP method is used to authenticate the user. 2. IKEv2 (RFC 4306) where EAP is used to magically authenticate the initiator using non-cert and non-PSK credentials. 3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate the user. In all three cases EAP is used by a protocol inside an encrypted tunnel, where the server, which is either trusted by the authenticator or co-located with it is already authenticated by a certificate or PSK. IMO EAP was used in all cases an some magical way of making passwords into a secure authentication mechanism. The problem is that there really is no publicly available EAP method for passwords. Tunneled methods don't really make sense here. There's no benefit
Re: [Emu] EMU charter revision
Dan: Now you have changed to argue that tunnel method is not the right solution for the use case EMU is targeted on, instead of arguing your proposed password should be included as addition to the tunnel method. I thought working on and standardizing the tunnel method is the WG consensus for few IETF meetings now, are you going to challenge that now? Maybe this also contributes to the snail race of tunnel method. As for the password method you proposed, I was at the last IETF meeting and you can also verify from he meeting minutes. The consensus is to have more security reviews and the IPR analysis. Also, since the use case it targeted maybe more broader than the EMU WG, it was suggested to bring up in SAAG as well, as multiple WGs can benefit from it. But the direction from the AD is to finish existing work first. Why are we keeping bring this up? -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 12:45 PM To: Hao Zhou (hzhou) Cc: Yoav Nir; emu@ietf.org Subject: Re: [Emu] EMU charter revision Hold on a second there Hao. A security proof was never a requirement. I'm not aware of any other IETF protocols that required security proofs or even have security proofs. There is no formal proof required of the tunneled methods and I think it would be very difficult to do one. One of the problems with the tunneled solution is the consistency principle described in Hugo Krawczyk's SIGMA paper. The tunneled methods violate that security requirement. And the fact that these things can be repeatedly tunneled ad nauseum amplifies that violation. A use case? Surely you have noticed the friction between usability and security. Security needs bootstrapping of some sort and typically that is problematic for many people especially when they need to bootstrap a large number of distinct security associations. So they cut corners. How are these corners cut? Do not verify server certificate. That's why that little check box exists. Because people don't want to enroll everybody/everything into a CA. So they use a self-signed certificate and check the Do not verify server certificate check box. And then they send a password over this encrypted tunnel. So the use case is robust security that cannot be provisioned insecurely. It's scalable and doesn't require the cutting of corners by administrators who are too busy (or frankly lazy) to do it the Correct Way. I have used the it's their network and if they aren't so concerned about security then who am I to force a workload on them comments in the past but it really is disingenuous. There are frightfully many deployments of password-authentication-through- encrypted-TLS-tunnel that use self-signed certificates and then something analogous to PAP. And they are done that way because there isn't a viable standard alternative. That is the use case for EAP-pwd. Oh, and it can satisfy the consistency principle too. :-) Dan. On Mon, April 28, 2008 8:10 am, Hao Zhou (hzhou) wrote: Yoav: I thought we had clear consensus in IETF 71 WG meeting and instructed by the AD that while Dan's proposal is an interesting one, but it doesn't work with the legacy password databases and thus out-of the scope of the charter. Until we have the proof of security analysis and clear of IPR issues, the WG is going to work on the tunnel method. I think this is the use case, legacy password database, the working group is currently working on and Gene is talking about Can you also explain why in the three use case you cited, EAP-GTC or MD5 doesn't meet the requirements, as they are all running inside an authenticated and encrypted tunnel? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yoav Nir Sent: Monday, April 28, 2008 8:13 AM To: emu@ietf.org Subject: Re: [Emu] EMU charter revision Gene Chang said: Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method? Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term snail race is a pejorative. Thus I ask you, how do we do better? I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me
Re: [Emu] EMU charter revision
Dan, I think we can all appreciate the entertainment value of bringing a reality show to the IETF. Imagine replacing the IETF social with an arena full of hyped up Internet engineers enjoying a night fellowship with beer and trash talk. Unfortunately, all we are doing is dressing up a down select with two 4-5 year old protocols that do not completely meet the requirements document that is being assembled. We aren't doing the industry a favor freezing the protocol choice to technology ca. 2004. If you are in such a rush, why not simply declare victory and have a tie. That enshrines the status quo. Picking one over the other won't change the status quo and thus won't change the deployment preference already established. Better for the industry would be a foot race where the candidate protocol that meets the requirements document and gains 10 million devices protected would win the standards title. This would advance the technology to cover the missing requirements and significantly grow adoption. Let's focus our efforts on moving the technology forward instead searching for an entertaining down select. I really don't see your sense of urgency. I don't see an adoption window that we are going to miss with the current effort. Yet, I can be really excited pushing to meet the needs of a critical adoption window. I would like to see things progress faster but not at the expense of a weak technical outcome. Gene Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 12:05 PM To: Gene Chang (genchang) Cc: Dan Harkins; Stephen Hanna; emu@ietf.org Subject: RE: [Emu] EMU charter revision Hi Gene, I'm not pushing a tunneled method. We have enough of those and their differences are not so great. Yes, I was using snail race as a pejorative. As I said at the last IETF we should have a cage-match-cum-beauty-contest between TTLS and FAST, turn the last RFC text of the winner into a -00 EMU draft, add the channel bindings stuff that was discussed back in Vancouver and then publish. Apparently this working group can work on nothing except a tunneled method. And that work is being done at a snail's pace. I'm glad to hear that you're open to a discussion of adding a non- tunneled method if there is sufficient demand, but you see we have this long-standing consensus and the mere mention of anything that remotely sounds like a non-tunneled method gets stifled with consensus! So apparently we're not allowed to have that discussion. At least until we finish work on a tunneled method. Dan. On Mon, April 28, 2008 3:35 am, Gene Chang (genchang) wrote: Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method? Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term snail race is a pejorative. Thus I ask you, how do we do better? I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me. Gene Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Harkins Sent: Monday, April 28, 2008 2:12 AM To: Stephen Hanna Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision That's true. One person's opinion does not negate consensus, even if that one person is the only one who is able to opine in the alloted time given for opinions (twice now). But so what? If someone asks then I'll give an honest opinion, especially since no one else seems to be able to. But maybe you're right. Any additional work taken on by this group would distract from the fantastic progress we've made in the past 9 months on the tunneled method. It would be a shame to lose all that. Yes, let's just focus on the snail race Dan. On Sun, April 27, 2008 6:10 pm, Stephen Hanna wrote: I apologize for my tardy response. I have been on vacation. I agree with and support the proposed charter below. As for Dan's suggestion that we not require the password based method to be based on the tunnel method, the WG already went through a long discussion and consensus check last fall
Re: [Emu] EMU charter revision
Hi Yoav, You bring up an interesting point in discussing the need for EAP password based authentication within other protected protocols. If this is targeted at working with legacy databases then I think it can be accommodated under the current charter. An EAP protected tunnel is required for some deployments, however perhaps the tunneled password protocol can be designed to be used in other cases (IKEv2, TLS, etc.) if the group wants to take this direction. What do you see lacking in something like EAP-GTC? Cheers, Joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yoav Nir Sent: Monday, April 28, 2008 5:13 AM To: emu@ietf.org Subject: Re: [Emu] EMU charter revision Gene Chang said: Dan, I am not sure I am able to clearly understand the end result you seek. It seems there is a clear consensus for a tunneled method. Are you pushing for the addition of a tunneled method? Ok... I am easily baited. What would you like to see to achieve more than a snail race? I am assuming we both believe the term snail race is a pejorative. Thus I ask you, how do we do better? I clearly hear your comment that there have been a paucity of comments, if nothing else, simply to affirm we are on track. I agree with the proposed charter. I am open to a discussion to add a non-tunneled method if there is sufficient demand. A non-tunneled method does not seem to promise enough features for the use cases that interest me. Gene Hi Gene, You did not specify what the uses that interest you are, and I don't know about the use cases that interest Dan either, but I can speak for the use cases that interest me. EAP has been used in several cases as a magic way to use legacy credentials in protocols. I'll cite three examples: 1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, Cisco and others, where an EAP method is used to authenticate the user. 2. IKEv2 (RFC 4306) where EAP is used to magically authenticate the initiator using non-cert and non-PSK credentials. 3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate the user. In all three cases EAP is used by a protocol inside an encrypted tunnel, where the server, which is either trusted by the authenticator or co-located with it is already authenticated by a certificate or PSK. IMO EAP was used in all cases an some magical way of making passwords into a secure authentication mechanism. The problem is that there really is no publicly available EAP method for passwords. Tunneled methods don't really make sense here. There's no benefit in putting a TLS tunnel inside an IKEv2 exchange just to pass the password. Something like EAP-SRP would be great if it (a) existed and (b) didn't have all that IPR baggage. The method that Dan is proposing would also be beneficial here, if we could get a WG behind it so we can get some solid security review. Instead, what implementors are doing is EAP-MD5 or EAP-GTC, which don't quite meet the requirements for any of the above protocols. Yoav ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU charter revision
Dan, Great, we are not back to lets get those requirements done. It's the gate to the next steps. Gene Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 3:22 PM To: Gene Chang (genchang) Cc: Dan Harkins; Stephen Hanna; emu@ietf.org Subject: RE: [Emu] EMU charter revision Gene, I don't think anyone would find an EMU reality show entertaining. The only comic relief would be one crazy guy who, once every 4 months, pokes his head in the window and says I do not approve to people sitting around watching paint dry. You are restating Stephen's comment from Philly that I'm more interested in the cage match than in the coronation of the winner. That is not true but it is also irrelevant. I actually don't care who wins or how much blood is let, I just want it to be over. It would really be an abuse of process to hold up all other work while each side crunches numbers and pays analysts to run surveys so that someone can claim to have reached an arbitrary 10M mark. And it would not be a service to anybody. So what we have is argument over the wording of requirements so that they will subtly favor one side over the other. Then we create a requirements document that captures all the carefully constructed verbage. And while that's getting advanced we then argue over which candidate best matches the customized wording of the requirements. And then we finally get down to the work of actually changing one of the specifications to add channel binding. And this must all be done serially. Sigh. Both FAST and TTLS are equally amenable to modification and their differences are not so great or we'd have had a clear winner already. No matter which one gets selected we will not end up with a weak solution. You don't see my sense of urgency because what you view as interesting work is not being held up. Dan. On Mon, April 28, 2008 11:26 am, Gene Chang (genchang) wrote: Dan, I think we can all appreciate the entertainment value of bringing a reality show to the IETF. Imagine replacing the IETF social with an arena full of hyped up Internet engineers enjoying a night fellowship with beer and trash talk. Unfortunately, all we are doing is dressing up a down select with two 4-5 year old protocols that do not completely meet the requirements document that is being assembled. We aren't doing the industry a favor freezing the protocol choice to technology ca. 2004. If you are in such a rush, why not simply declare victory and have a tie. That enshrines the status quo. Picking one over the other won't change the status quo and thus won't change the deployment preference already established. Better for the industry would be a foot race where the candidate protocol that meets the requirements document and gains 10 million devices protected would win the standards title. This would advance the technology to cover the missing requirements and significantly grow adoption. Let's focus our efforts on moving the technology forward instead searching for an entertaining down select. I really don't see your sense of urgency. I don't see an adoption window that we are going to miss with the current effort. Yet, I can be really excited pushing to meet the needs of a critical adoption window. I would like to see things progress faster but not at the expense of a weak technical outcome. Gene Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 12:05 PM To: Gene Chang (genchang) Cc: Dan Harkins; Stephen Hanna; emu@ietf.org Subject: RE: [Emu] EMU charter revision Hi Gene, I'm not pushing a tunneled method. We have enough of those and their differences are not so great. Yes, I was using snail race as a pejorative. As I said at the last IETF we should have a cage-match-cum-beauty-contest between TTLS and FAST, turn the last RFC text of the winner into a -00 EMU draft, add the channel bindings stuff that was discussed back in Vancouver and then publish. Apparently this working group can work on nothing except a tunneled method. And that work is being done at a snail's pace. I'm glad to hear that you're open to a discussion of adding a non- tunneled method if there is sufficient demand, but you see we have this long-standing consensus and the mere mention of anything that remotely sounds like a non-tunneled method gets stifled with consensus! So apparently we're not allowed to have
Re: [Emu] EMU charter revision
Oops... a key typo in the earlier version... Dan, Great, we are now back to let's get those requirements done. It's the gate to the next steps. Gene Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gene Chang (genchang) Sent: Monday, April 28, 2008 3:44 PM To: Dan Harkins Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision Dan, Great, we are not back to lets get those requirements done. It's the gate to the next steps. Gene Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 3:22 PM To: Gene Chang (genchang) Cc: Dan Harkins; Stephen Hanna; emu@ietf.org Subject: RE: [Emu] EMU charter revision Gene, I don't think anyone would find an EMU reality show entertaining. The only comic relief would be one crazy guy who, once every 4 months, pokes his head in the window and says I do not approve to people sitting around watching paint dry. You are restating Stephen's comment from Philly that I'm more interested in the cage match than in the coronation of the winner. That is not true but it is also irrelevant. I actually don't care who wins or how much blood is let, I just want it to be over. It would really be an abuse of process to hold up all other work while each side crunches numbers and pays analysts to run surveys so that someone can claim to have reached an arbitrary 10M mark. And it would not be a service to anybody. So what we have is argument over the wording of requirements so that they will subtly favor one side over the other. Then we create a requirements document that captures all the carefully constructed verbage. And while that's getting advanced we then argue over which candidate best matches the customized wording of the requirements. And then we finally get down to the work of actually changing one of the specifications to add channel binding. And this must all be done serially. Sigh. Both FAST and TTLS are equally amenable to modification and their differences are not so great or we'd have had a clear winner already. No matter which one gets selected we will not end up with a weak solution. You don't see my sense of urgency because what you view as interesting work is not being held up. Dan. On Mon, April 28, 2008 11:26 am, Gene Chang (genchang) wrote: Dan, I think we can all appreciate the entertainment value of bringing a reality show to the IETF. Imagine replacing the IETF social with an arena full of hyped up Internet engineers enjoying a night fellowship with beer and trash talk. Unfortunately, all we are doing is dressing up a down select with two 4-5 year old protocols that do not completely meet the requirements document that is being assembled. We aren't doing the industry a favor freezing the protocol choice to technology ca. 2004. If you are in such a rush, why not simply declare victory and have a tie. That enshrines the status quo. Picking one over the other won't change the status quo and thus won't change the deployment preference already established. Better for the industry would be a foot race where the candidate protocol that meets the requirements document and gains 10 million devices protected would win the standards title. This would advance the technology to cover the missing requirements and significantly grow adoption. Let's focus our efforts on moving the technology forward instead searching for an entertaining down select. I really don't see your sense of urgency. I don't see an adoption window that we are going to miss with the current effort. Yet, I can be really excited pushing to meet the needs of a critical adoption window. I would like to see things progress faster but not at the expense of a weak technical outcome. Gene Eugene Chang (genchang) Cisco Systems Office: 603-559-2978 Mobile: 781-799-0233 Skype: gene02421 -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 12:05 PM To: Gene Chang (genchang) Cc: Dan Harkins; Stephen Hanna; emu@ietf.org Subject: RE: [Emu] EMU charter revision Hi Gene, I'm not pushing a tunneled method. We have enough of those and their differences are not so great. Yes, I was using snail race as a pejorative. As I said
Re: [Emu] EMU charter revision
I apologize for my tardy response. I have been on vacation. I agree with and support the proposed charter below. As for Dan's suggestion that we not require the password based method to be based on the tunnel method, the WG already went through a long discussion and consensus check last fall on this matter. There was clear consensus that we should NOT work on a new password based method designed to function without the tunnel method. One person's opinion to the contrary does not negate that consensus. I think that the reason we are not seeing much email on this charter is that the issues and language have been hashed through many times. Thanks, Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Harkins Sent: Friday, April 25, 2008 5:43 PM To: Joseph Salowey (jsalowey) Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision Hi Joe, Once again, a call for comments and I'm the only one to comment. Whether removing that line achieves my goals or not I still think it should be removed. And that really seems to be the only comment on the charter you get when you ask. regards, Dan. On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Friday, April 11, 2008 10:38 AM To: Joseph Salowey (jsalowey) Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision Hi Joe, Thank you for giving me the opportunity to object, once again, to the last sentence in the last item in the charter. If you were to run the following sed filter on the charter I would approve: s/This item will be based on the above tunnel method.// [Joe] I do not think that removing this line would achieve the goal you wish. With this line removed EAP-PWD is still out of scope of the charter as it does not meet the requirements of supporting legacy password databases. The message from the ADs in the last meeting was pretty clear in that EAP-PWD style mechanisms is not something for the group to take on right now. This does not mean that we cannot take on an EAP-PWD style mechanism once we have made progress on the current charter items. What is the process here? This looks the same as the charter revision you made a consensus call on back in January. I was the only one to opine before your cutoff last time and my comment was the same as above. Now we're doing this again. [Joe] There have been several revisions posted to the list and feedback from several working group members that have been worked into the new proposal along with input from the discussion in the last meeting. If enough people respond positively, such that we have rough consensus, then we can move forward. Dan. On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: Below is a revision to the EMU charter that is intended to reflect the discussions in the Philadelphia meeting. Please respond to the list if you approve of the charter or if you have any comments on the charter. I would like to have responses by 4/24. Thanks, f Joe Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods, but some are documented in informational RFCs. In the past the lack of documented, open specifications has been a deployment and interoperability problem. There are currently only two EAP methods in the standards track that implement features such as key derivation that are required for many modern applications. Authentication types and credentials continue to evolve as do requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - A mechanism based on strong shared secrets. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism must support channel bindings in order to meet RFC 4962 requirements. This mechanism will support meeting the requirements of an enhanced TLS mechanism
Re: [Emu] EMU charter revision
Hi Joe, Once again, a call for comments and I'm the only one to comment. Whether removing that line achieves my goals or not I still think it should be removed. And that really seems to be the only comment on the charter you get when you ask. regards, Dan. On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: -Original Message- From: Dan Harkins [mailto:[EMAIL PROTECTED] Sent: Friday, April 11, 2008 10:38 AM To: Joseph Salowey (jsalowey) Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision Hi Joe, Thank you for giving me the opportunity to object, once again, to the last sentence in the last item in the charter. If you were to run the following sed filter on the charter I would approve: s/This item will be based on the above tunnel method.// [Joe] I do not think that removing this line would achieve the goal you wish. With this line removed EAP-PWD is still out of scope of the charter as it does not meet the requirements of supporting legacy password databases. The message from the ADs in the last meeting was pretty clear in that EAP-PWD style mechanisms is not something for the group to take on right now. This does not mean that we cannot take on an EAP-PWD style mechanism once we have made progress on the current charter items. What is the process here? This looks the same as the charter revision you made a consensus call on back in January. I was the only one to opine before your cutoff last time and my comment was the same as above. Now we're doing this again. [Joe] There have been several revisions posted to the list and feedback from several working group members that have been worked into the new proposal along with input from the discussion in the last meeting. If enough people respond positively, such that we have rough consensus, then we can move forward. Dan. On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: Below is a revision to the EMU charter that is intended to reflect the discussions in the Philadelphia meeting. Please respond to the list if you approve of the charter or if you have any comments on the charter. I would like to have responses by 4/24. Thanks, f Joe Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods, but some are documented in informational RFCs. In the past the lack of documented, open specifications has been a deployment and interoperability problem. There are currently only two EAP methods in the standards track that implement features such as key derivation that are required for many modern applications. Authentication types and credentials continue to evolve as do requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - A mechanism based on strong shared secrets. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism must support channel bindings in order to meet RFC 4962 requirements. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will extend EAP-TLS and/or the above tunnel method. - A mechanism that makes use of existing password databases such as AAA databases. This item will be based on the above tunnel method. Goals and Milestones: Done Form design team to work on strong shared secret mechanism Done Submit 2716bis I-D Done Submit first draft of shared secret mechanism I-D Done Form password based mechanism design team Done Submit 2716bis draft to IESG for Proposed Standard Apr 2008 Submit Strong Shared Secret Mechanism to IESG May 2008 Submit Tunnel and Password Method requirements first
Re: [Emu] EMU charter revision
Hi Joe, Thank you for giving me the opportunity to object, once again, to the last sentence in the last item in the charter. If you were to run the following sed filter on the charter I would approve: s/This item will be based on the above tunnel method.// What is the process here? This looks the same as the charter revision you made a consensus call on back in January. I was the only one to opine before your cutoff last time and my comment was the same as above. Now we're doing this again. Dan. On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) wrote: Below is a revision to the EMU charter that is intended to reflect the discussions in the Philadelphia meeting. Please respond to the list if you approve of the charter or if you have any comments on the charter. I would like to have responses by 4/24. Thanks, Joe Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods, but some are documented in informational RFCs. In the past the lack of documented, open specifications has been a deployment and interoperability problem. There are currently only two EAP methods in the standards track that implement features such as key derivation that are required for many modern applications. Authentication types and credentials continue to evolve as do requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - A mechanism based on strong shared secrets. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism must support channel bindings in order to meet RFC 4962 requirements. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. - Enable a TLS-based EAP method to support channel bindings. This item will not generate a new method, rather it will extend EAP-TLS and/or the above tunnel method. - A mechanism that makes use of existing password databases such as AAA databases. This item will be based on the above tunnel method. Goals and Milestones: Done Form design team to work on strong shared secret mechanism Done Submit 2716bis I-D Done Submit first draft of shared secret mechanism I-D Done Form password based mechanism design team Done Submit 2716bis draft to IESG for Proposed Standard Apr 2008 Submit Strong Shared Secret Mechanism to IESG May 2008 Submit Tunnel and Password Method requirements first Draft Sep 2008 Submit EAP Channel Bindings First Draft Sep 2008 Submit Tunnel Method first draft Oct 2008 Submit TLS based method channel binding first draft Oct 2008 Submit Password Method first draft Jan 2009 Send EAP Channel Bindings to IESG Mar 2009 Send Tunnel Method to IESG Apr 2009 Send TLS based method channel binding to IESG Apr 2009 Send Password based method to IESG ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU Charter revision
I agree with Bernard on all points. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard Aboba Sent: Friday, February 22, 2008 2:54 AM To: emu@ietf.org Subject: Re: [Emu] EMU Charter revision I also do NOT approve of the current charter revision, for several reasons: a. The Charter text contains statements that are no longer true. For example: Most of these methods are proprietary methods and only a few methods are documented in RFCs. The following EAP methods are now documented in RFCs: EAP-TLS (RFC 2716) EAP-SIM (RFC 4186) EAP-AKA (RFC 4187) EAP-PAX (RFC 4746) EAP-SAKE (RFC 4763) EAP-PSK (RFC 4764) EAP-POTP (RFC 4793) EAP-FAST (RFC 4851) EAP-IKEv2 (RFC 5106) 9 methods claiming to satify RFC 4017 critieria is more than a few. b. The Charter requires support for Channel Bindings without doing the preparatory work to define how Channel Bindings works. Either the requirement should be removed, or a work item should be added to better define the approach to Channel Bindings. c. The text on tunnel methods does not provide enough guidance to avoid potentially fruitless arguments. So far, the EMU WG has not been able to come to consensus on selection of one of the existing tunneling protocols, and efforts to design yet another tunneling protocol haven't gotten very far either. I'd like to see more specific language that would make it clear that work on improving existing tunneling protocols is within scope, and also that the EMU WG, if it cannot come to consensus on a single protocol, can proceed to work on one or more protocols with significant support. d. Password-based methods. While I can understand the desire to limit the number of charter items, I do agree with Dan that work on weak-password methods is important. With some of the IPR obstacles likely to fall by the wayside in coming years, it is time for the IETF to re-visit its policy on inclusion of zero knowledge algorithms within standards track documents. Dan Harkins said: Hi Joe, I do NOT approve of the current charter revision, specifically the change that says the password-based method can only be via the tunneled method. I do approve of the inclusion of tunneled methods in the charter though and would be willing to contribute as a reviewer. regards, Dan. On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote: The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00. txt) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU Charter revision
Hi Bernard, Comments inline below: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard Aboba Sent: Thursday, February 21, 2008 11:54 AM To: emu@ietf.org Subject: Re: [Emu] EMU Charter revision I also do NOT approve of the current charter revision, for several reasons: a. The Charter text contains statements that are no longer true. For example: Most of these methods are proprietary methods and only a few methods are documented in RFCs. The following EAP methods are now documented in RFCs: EAP-TLS (RFC 2716) EAP-SIM (RFC 4186) EAP-AKA (RFC 4187) EAP-PAX (RFC 4746) EAP-SAKE (RFC 4763) EAP-PSK (RFC 4764) EAP-POTP (RFC 4793) EAP-FAST (RFC 4851) EAP-IKEv2 (RFC 5106) 9 methods claiming to satify RFC 4017 critieria is more than a few. [Joe] In addition there is at least one more, EAP-TTLS that is in the process. We can revise the section of the charter. Do you have any suggested text? b. The Charter requires support for Channel Bindings without doing the preparatory work to define how Channel Bindings works. Either the requirement should be removed, or a work item should be added to better define the approach to Channel Bindings. [Joe] There is time set on the agenda in Philadelphia to discuss channel bindings. c. The text on tunnel methods does not provide enough guidance to avoid potentially fruitless arguments. So far, the EMU WG has not been able to come to consensus on selection of one of the existing tunneling protocols, and efforts to design yet another tunneling protocol haven't gotten very far either. I'd like to see more specific language that would make it clear that work on improving existing tunneling protocols is within scope, and also that the EMU WG, if it cannot come to consensus on a single protocol, can proceed to work on one or more protocols with significant support. [Joe] OK, do you have some recommended text in this area. I'm not sure how one would write this into the charter. I think this will need some discussion. d. Password-based methods. While I can understand the desire to limit the number of charter items, I do agree with Dan that work on weak-password methods is important. With some of the IPR obstacles likely to fall by the wayside in coming years, it is time for the IETF to re-visit its policy on inclusion of zero knowledge algorithms within standards track documents. [Joe] This will be a topic for discussion as well. We can see what the level of interest is. Dan Harkins said: Hi Joe, I do NOT approve of the current charter revision, specifically the change that says the password-based method can only be via the tunneled method. I do approve of the inclusion of tunneled methods in the charter though and would be willing to contribute as a reviewer. regards, Dan. On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote: The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunn el-req-00. txt) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU Charter revision
I have an opinion about Channel Binding. Based on discussion to create RFC 4962 and draft-ietf-hokey-key-mgt, I came to believe that EAP method is not the right tool to solve the Channel Binding problem even if RFC 3748 has Channel Binding in its list of security claims on EAP method. This is because EAP methods are based on two-party keying, while the Channel Binding problem essentially came from separation of EAP authenticator and EAP server. I think Channel Binding is best solved using a three-party key distribution protocol e.g., by re-designing EAP to be a 3-party protocol, but that is not what EMU WG is supposed to do, either. Said that I suggest removing Channel Binding support from the EMU charter. Yoshihiro Ohba On Thu, Feb 21, 2008 at 11:54:06AM -0800, Bernard Aboba wrote: I also do NOT approve of the current charter revision, for several reasons: a. The Charter text contains statements that are no longer true. For example: Most of these methods are proprietary methods and only a few methods are documented in RFCs. The following EAP methods are now documented in RFCs: EAP-TLS (RFC 2716) EAP-SIM (RFC 4186) EAP-AKA (RFC 4187) EAP-PAX (RFC 4746) EAP-SAKE (RFC 4763) EAP-PSK (RFC 4764) EAP-POTP (RFC 4793) EAP-FAST (RFC 4851) EAP-IKEv2 (RFC 5106) 9 methods claiming to satify RFC 4017 critieria is more than a few. b. The Charter requires support for Channel Bindings without doing the preparatory work to define how Channel Bindings works. Either the requirement should be removed, or a work item should be added to better define the approach to Channel Bindings. c. The text on tunnel methods does not provide enough guidance to avoid potentially fruitless arguments. So far, the EMU WG has not been able to come to consensus on selection of one of the existing tunneling protocols, and efforts to design yet another tunneling protocol haven't gotten very far either. I'd like to see more specific language that would make it clear that work on improving existing tunneling protocols is within scope, and also that the EMU WG, if it cannot come to consensus on a single protocol, can proceed to work on one or more protocols with significant support. d. Password-based methods. While I can understand the desire to limit the number of charter items, I do agree with Dan that work on weak-password methods is important. With some of the IPR obstacles likely to fall by the wayside in coming years, it is time for the IETF to re-visit its policy on inclusion of zero knowledge algorithms within standards track documents. Dan Harkins said: Hi Joe, I do NOT approve of the current charter revision, specifically the change that says the password-based method can only be via the tunneled method. I do approve of the inclusion of tunneled methods in the charter though and would be willing to contribute as a reviewer. regards, Dan. On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote: The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00. txt) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe ___ Emu mailing list Emu@ietf.org http://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org http://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU Charter revision
Hi Bernard, Bernard Aboba wrote: Zero knowledge is definitely crypto-intensive. For example, to get both privacy and strong password protection, at least two DHs are required. However, there are circumstances where server-side certificates aren't acceptable. Even in today, many/(most?) EAP deployments do not involve certificates (e.g. LEAP, FAST). The good thing is that the approach would work with even a self-signed certificate since there is a big difference between the certificates used in the Web environment and for network access. In the former case you want to make sure that the browser with any webserver on the Internet. This is an any-to-any relationship. For network access you have a many-to-one relationship. Even if zero knowledge isn't used on an ongoing basis (out of concern for load, for example), it still can be useful for initial provisioning. Provisioning the initial security is an entirely different problem. EAP is the wrong way todo that. See for example the interesting work done in the KEYPROV working group. For example, EAP FAST provisioning is vulnerable to man-in-the-middle attack or dictionary attack, which could be removed with use of zero knowledge algorithms. Need to look at this aspect of the draft again. Ciao Hannes Subject: AW: [Emu] EMU Charter revision Date: Fri, 22 Feb 2008 15:34:56 +0100 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; emu@ietf.org Hi Bernard, a question your excitment regarding strong password based EAP method. Why do you think they are useful? There are other ways (and they are deployed already) that can accomplish the same result without going along the SRP co track. Is it because you expect performance improvements or because the crypto-mechanisms look nicer? I cannot quite understand the motivation. Ciao Hannes Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von ext Bernard Aboba Gesendet: Donnerstag, 21. Februar 2008 21:54 An: emu@ietf.org Betreff: Re: [Emu] EMU Charter revision I also do NOT approve of the current charter revision, for several reasons: a. The Charter text contains statements that are no longer true. For example: Most of these methods are proprietary methods and only a few methods are documented in RFCs. The following EAP methods are now documented in RFCs: EAP-TLS (RFC 2716) EAP-SIM (RFC 4186) EAP-AKA (RFC 4187) EAP-PAX (RFC 4746) EAP-SAKE (RFC 4763) EAP-PSK (RFC 4764) EAP-POTP (RFC 4793) EAP-FAST (RFC 4851) EAP-IKEv2 (RFC 5106) 9 methods claiming to satify RFC 4017 critieria is more than a few. b. The Charter requires support for Channel Bindings without doing the preparatory work to define how Channel Bindings works. Either the requirement should be removed, or a work item should be added to better define the approach to Channel Bindings. c. The text on tunnel methods does not provide enough guidance to avoid potentially fruitless arguments. So far, the EMU WG has not been able to come to consensus on selection of one of the existing tunneling protocols, and efforts to design yet another tunneling protocol haven't gotten very far either. I'd like to see more specific language that would make it clear that work on improving existing tunneling protocols is within scope, and also that the EMU WG, if it cannot come to consensus on a single protocol, can proceed to work on one or more protocols with significant support. d. Password-based methods. While I can understand the desire to limit the number of charter items, I do agree with Dan that work on weak-password methods is important. With some of the IPR obstacles likely to fall by the wayside in coming years, it is time for the IETF to re-visit its policy on inclusion of zero knowledge algorithms within standards track documents. Dan Harkins said: Hi Joe, I do NOT approve of the current charter revision, specifically the change that says the password-based method can only be via the tunneled method. I do approve of the inclusion of tunneled methods in the charter though and would be willing to contribute as a reviewer. regards, Dan. On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote: The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer
Re: [Emu] EMU Charter revision
Hi Hannes, What you're saying is not that it would work but that it could work. If it's deployed correctly. And if there's some step that each and every client MUST go through to accept a certificate. So _if_ _every_ client goes through this step than it _can_ work. If, for some reason, this strict regime is not followed then it doesn't work. The issue isn't whether it can be made secure provided some series of steps are religiously followed. It's whether it will be secure even if those steps are not religiously followed. Dan. On Sat, February 23, 2008 1:19 am, Hannes Tschofenig wrote: Hi Bernard, Bernard Aboba wrote: Zero knowledge is definitely crypto-intensive. For example, to get both privacy and strong password protection, at least two DHs are required. However, there are circumstances where server-side certificates aren't acceptable. Even in today, many/(most?) EAP deployments do not involve certificates (e.g. LEAP, FAST). The good thing is that the approach would work with even a self-signed certificate since there is a big difference between the certificates used in the Web environment and for network access. In the former case you want to make sure that the browser with any webserver on the Internet. This is an any-to-any relationship. For network access you have a many-to-one relationship. Even if zero knowledge isn't used on an ongoing basis (out of concern for load, for example), it still can be useful for initial provisioning. Provisioning the initial security is an entirely different problem. EAP is the wrong way todo that. See for example the interesting work done in the KEYPROV working group. For example, EAP FAST provisioning is vulnerable to man-in-the-middle attack or dictionary attack, which could be removed with use of zero knowledge algorithms. Need to look at this aspect of the draft again. Ciao Hannes Subject: AW: [Emu] EMU Charter revision Date: Fri, 22 Feb 2008 15:34:56 +0100 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; emu@ietf.org Hi Bernard, a question your excitment regarding strong password based EAP method. Why do you think they are useful? There are other ways (and they are deployed already) that can accomplish the same result without going along the SRP co track. Is it because you expect performance improvements or because the crypto-mechanisms look nicer? I cannot quite understand the motivation. Ciao Hannes Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von ext Bernard Aboba Gesendet: Donnerstag, 21. Februar 2008 21:54 An: emu@ietf.org Betreff: Re: [Emu] EMU Charter revision I also do NOT approve of the current charter revision, for several reasons: a. The Charter text contains statements that are no longer true. For example: Most of these methods are proprietary methods and only a few methods are documented in RFCs. The following EAP methods are now documented in RFCs: EAP-TLS (RFC 2716) EAP-SIM (RFC 4186) EAP-AKA (RFC 4187) EAP-PAX (RFC 4746) EAP-SAKE (RFC 4763) EAP-PSK (RFC 4764) EAP-POTP (RFC 4793) EAP-FAST (RFC 4851) EAP-IKEv2 (RFC 5106) 9 methods claiming to satify RFC 4017 critieria is more than a few. b. The Charter requires support for Channel Bindings without doing the preparatory work to define how Channel Bindings works. Either the requirement should be removed, or a work item should be added to better define the approach to Channel Bindings. c. The text on tunnel methods does not provide enough guidance to avoid potentially fruitless arguments. So far, the EMU WG has not been able to come to consensus on selection of one of the existing tunneling protocols, and efforts to design yet another tunneling protocol haven't gotten very far either. I'd like to see more specific language that would make it clear that work on improving existing tunneling protocols is within scope, and also that the EMU WG, if it cannot come to consensus on a single protocol, can proceed to work on one or more protocols with significant support. d. Password-based methods. While I can understand the desire to limit the number of charter items, I do agree with Dan that work on weak-password methods is important. With some of the IPR obstacles likely to fall by the wayside in coming years, it is time for the IETF to re-visit its policy on inclusion of zero knowledge algorithms within standards track documents. Dan Harkins said: Hi Joe, I do NOT approve of the current charter revision, specifically the change that says the password-based method can only be via the tunneled method. I do approve of the inclusion of tunneled methods in the charter though and would be willing to contribute as a reviewer. regards, Dan. On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote: The response to the charter revision has been underwhelming. I am a bit concerned that we do not have
Re: [Emu] EMU charter revision
Hi Dorothy, The current charter item is for a method that works with existing password databases. This requires the method to work with databases where the EAP server does not have access to the cleartext password and in some cases does not have access even to the transform of the password (in these cases a comparison function is available). I don't believe the method proposed in http://www.ietf.org/internet-drafts/draft-harkins-emu-eap-pwd-00.txt meets this requirement. Can you clarify if you want to remove this requirement or if you want to add a charter item for a secure password only method such as the on proposed in the draft? Thanks, Joe -Original Message- From: Dorothy Stanley [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 8:25 AM To: Joseph Salowey (jsalowey) Cc: emu@ietf.org Subject: Re: [Emu] EMU charter revision Joe, I do not approve of the charter revision; the charter should not prohibit the group from using a non-tunneled method for the password-based method. My previous mail gave a suggested charter text change. I can participate as a reviewer. Thanks, Dorothy Stanley On Tue, Feb 19, 2008 at 11:14 AM, Joseph Salowey (jsalowey) [EMAIL PROTECTED] wrote: The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunn el-req-00. txt http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunn el-req-00.txt ) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe -Original Message- From: Joseph Salowey (jsalowey) Sent: Monday, February 04, 2008 9:13 PM To: emu@ietf.org Subject: EMU charter revision Below is a revised charter update based on the discussion on the list. I have left the password based method item as a tunnel method because this represents the consensus the working group has reached. I also believe the working group will have to focus on the tunnel method related items for the near term to make progress. This does not mean that we cannot work on additional methods as working group items in the future. Please review the charter update and post any issues you have with the carter. Please also indicate if you have reviewed the proposed charter and have no issues. It is difficult to judge working group consensus unless there are sufficient responses. Thanks, Joe Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods and only a few methods are documented in RFCs. The lack of documented, open specifications is a deployment and interoperability problem. In addition, none of the EAP methods in the standards track implement features such as key derivation that are required for many modern applications. This poses a problem for, among other things, the selection of a mandatory to implement EAP method in new network access technologies. For example, no standards track methods meet new requirements such as those posed in RFC 4017, which documents IEEE 802.11 requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748 and RFC 4017 requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document
Re: [Emu] EMU charter revision
Joe, I do not approve of the charter revision; the charter should not prohibit the group from using a non-tunneled method for the password-based method. My previous mail gave a suggested charter text change. I can participate as a reviewer. Thanks, Dorothy Stanley On Tue, Feb 19, 2008 at 11:14 AM, Joseph Salowey (jsalowey) [EMAIL PROTECTED] wrote: The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00. txthttp://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00.txt) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe -Original Message- From: Joseph Salowey (jsalowey) Sent: Monday, February 04, 2008 9:13 PM To: emu@ietf.org Subject: EMU charter revision Below is a revised charter update based on the discussion on the list. I have left the password based method item as a tunnel method because this represents the consensus the working group has reached. I also believe the working group will have to focus on the tunnel method related items for the near term to make progress. This does not mean that we cannot work on additional methods as working group items in the future. Please review the charter update and post any issues you have with the carter. Please also indicate if you have reviewed the proposed charter and have no issues. It is difficult to judge working group consensus unless there are sufficient responses. Thanks, Joe Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods and only a few methods are documented in RFCs. The lack of documented, open specifications is a deployment and interoperability problem. In addition, none of the EAP methods in the standards track implement features such as key derivation that are required for many modern applications. This poses a problem for, among other things, the selection of a mandatory to implement EAP method in new network access technologies. For example, no standards track methods meet new requirements such as those posed in RFC 4017, which documents IEEE 802.11 requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748 and RFC 4017 requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - A mechanism based on strong shared secrets that meets RFC 3748 and RFC 4017 requirements. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A mechanism to support extensible communication within a TLS protected tunnel that meets RFC 3748 and RFC 4017 requirements. This mechanism must support channel bindings in order to meet RFC 4962 requirements and it must provide cryptographic algorithm agility. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. - Enable a TLS-based EAP method to support channel bindings. So as to enable RFC 2716bis to focus solely on clarifications to the existing protocol, this effort will be handled in a separate document. This item will not generate a new method, rather it will enhance EAP-TLS or the TLS based tunnel method work item. - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. This item will be based on the tunnel method work item. Goals and Milestones: Done Form
Re: [Emu] EMU Charter revision
Hi Hannes, What are these methods? And is their security completely based on an assumption that the one deploying this method is following some strict regime (e.g. no weak passwords)? regards, Dan. On Fri, February 22, 2008 6:34 am, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi Bernard, a question your excitment regarding strong password based EAP method. Why do you think they are useful? There are other ways (and they are deployed already) that can accomplish the same result without going along the SRP co track. Is it because you expect performance improvements or because the crypto-mechanisms look nicer? I cannot quite understand the motivation. Ciao Hannes Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von ext Bernard Aboba Gesendet: Donnerstag, 21. Februar 2008 21:54 An: emu@ietf.org Betreff: Re: [Emu] EMU Charter revision I also do NOT approve of the current charter revision, for several reasons: a. The Charter text contains statements that are no longer true. For example: Most of these methods are proprietary methods and only a few methods are documented in RFCs. The following EAP methods are now documented in RFCs: EAP-TLS (RFC 2716) EAP-SIM (RFC 4186) EAP-AKA (RFC 4187) EAP-PAX (RFC 4746) EAP-SAKE (RFC 4763) EAP-PSK (RFC 4764) EAP-POTP (RFC 4793) EAP-FAST (RFC 4851) EAP-IKEv2 (RFC 5106) 9 methods claiming to satify RFC 4017 critieria is more than a few. b. The Charter requires support for Channel Bindings without doing the preparatory work to define how Channel Bindings works. Either the requirement should be removed, or a work item should be added to better define the approach to Channel Bindings. c. The text on tunnel methods does not provide enough guidance to avoid potentially fruitless arguments. So far, the EMU WG has not been able to come to consensus on selection of one of the existing tunneling protocols, and efforts to design yet another tunneling protocol haven't gotten very far either. I'd like to see more specific language that would make it clear that work on improving existing tunneling protocols is within scope, and also that the EMU WG, if it cannot come to consensus on a single protocol, can proceed to work on one or more protocols with significant support. d. Password-based methods. While I can understand the desire to limit the number of charter items, I do agree with Dan that work on weak-password methods is important. With some of the IPR obstacles likely to fall by the wayside in coming years, it is time for the IETF to re-visit its policy on inclusion of zero knowledge algorithms within standards track documents. Dan Harkins said: Hi Joe, I do NOT approve of the current charter revision, specifically the change that says the password-based method can only be via the tunneled method. I do approve of the inclusion of tunneled methods in the charter though and would be willing to contribute as a reviewer. regards, Dan. On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote: The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00. txt) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe ___ Emu mailing list Emu@ietf.org http://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org http://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU Charter revision
Hi Dan, you are asking me which EAP methods support weak passwords? If so, here are a few examples: * TTLS * PEAP * EAP-PAX * EAP-FAST * EAP-IKEv2 Please note that I am not against doing the work; I would just like to understand what the main motivation is. Ciao Hannes Dan Harkins wrote: Hi Hannes, What are these methods? And is their security completely based on an assumption that the one deploying this method is following some strict regime (e.g. no weak passwords)? regards, Dan. On Fri, February 22, 2008 6:34 am, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi Bernard, a question your excitment regarding strong password based EAP method. Why do you think they are useful? There are other ways (and they are deployed already) that can accomplish the same result without going along the SRP co track. Is it because you expect performance improvements or because the crypto-mechanisms look nicer? I cannot quite understand the motivation. Ciao Hannes Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von ext Bernard Aboba Gesendet: Donnerstag, 21. Februar 2008 21:54 An: emu@ietf.org Betreff: Re: [Emu] EMU Charter revision I also do NOT approve of the current charter revision, for several reasons: a. The Charter text contains statements that are no longer true. For example: Most of these methods are proprietary methods and only a few methods are documented in RFCs. The following EAP methods are now documented in RFCs: EAP-TLS (RFC 2716) EAP-SIM (RFC 4186) EAP-AKA (RFC 4187) EAP-PAX (RFC 4746) EAP-SAKE (RFC 4763) EAP-PSK (RFC 4764) EAP-POTP (RFC 4793) EAP-FAST (RFC 4851) EAP-IKEv2 (RFC 5106) 9 methods claiming to satify RFC 4017 critieria is more than a few. b. The Charter requires support for Channel Bindings without doing the preparatory work to define how Channel Bindings works. Either the requirement should be removed, or a work item should be added to better define the approach to Channel Bindings. c. The text on tunnel methods does not provide enough guidance to avoid potentially fruitless arguments. So far, the EMU WG has not been able to come to consensus on selection of one of the existing tunneling protocols, and efforts to design yet another tunneling protocol haven't gotten very far either. I'd like to see more specific language that would make it clear that work on improving existing tunneling protocols is within scope, and also that the EMU WG, if it cannot come to consensus on a single protocol, can proceed to work on one or more protocols with significant support. d. Password-based methods. While I can understand the desire to limit the number of charter items, I do agree with Dan that work on weak-password methods is important. With some of the IPR obstacles likely to fall by the wayside in coming years, it is time for the IETF to re-visit its policy on inclusion of zero knowledge algorithms within standards track documents. Dan Harkins said: Hi Joe, I do NOT approve of the current charter revision, specifically the change that says the password-based method can only be via the tunneled method. I do approve of the inclusion of tunneled methods in the charter though and would be willing to contribute as a reviewer. regards, Dan. On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote: The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00. txt) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe ___ Emu mailing list Emu@ietf.org http://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU Charter revision
Hi Hannes, The first 4 of those require a certificate (well, PAX doesn't but as it says in its Security Considerations if you don't use one then it's open to dictionary attack) and in some situations it is desirable to not have one. From personal experience I have run into scores and scores of systems that get deployed using self-signed certificates and then something that is not resistant to dictionary attack as the client-side authentication method. So the end result is a system that does not have the properties that the protocols it implements claim it should have. The fact that verify server certificate is an option underscores this problem. I think it is very valuable to have protocols that are secure in the presence of poor operational deployment. We all know things will get deployed in the most expeditious manner possible so having protocols that remain secure in the presence of weak passwords or self-signed certificates or whathaveyou is A Good Thing (tm). They are robust, not fragile. About EAP-IKEv2 Please don't take offense but I think it is an abomination. We can have EAP-IKEv2 with AAA1 authenticating with a certificate and the client doing EAP for client-side authentication which gets passed to AAA2 which does TTLS (or FAST or PEAP) and authenticates with its own certificate and the client authentication is...EAP! Which gets passed to AAA3 where EAP-MSCHAPv2 is done and AAA4 is asked if some particular username/password is correct or not. Is that username the same as the one provided in EAP-IKEv2 or in TTLS? Who knows! But some server somewhere says that a single username/password combination is correct and that's just supposed to be OK. Note that if a TLS ciphersuite to do EAP for client-side authentication goes past I-D stage then this can be extended several more steps, involving AAA5 and AAA6, without even duplicating EAP methods anywhere. regards, Dan. On Fri, February 22, 2008 11:14 am, Hannes Tschofenig wrote: Hi Dan, you are asking me which EAP methods support weak passwords? If so, here are a few examples: * TTLS * PEAP * EAP-PAX * EAP-FAST * EAP-IKEv2 Please note that I am not against doing the work; I would just like to understand what the main motivation is. Ciao Hannes Dan Harkins wrote: Hi Hannes, What are these methods? And is their security completely based on an assumption that the one deploying this method is following some strict regime (e.g. no weak passwords)? regards, Dan. On Fri, February 22, 2008 6:34 am, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi Bernard, a question your excitment regarding strong password based EAP method. Why do you think they are useful? There are other ways (and they are deployed already) that can accomplish the same result without going along the SRP co track. Is it because you expect performance improvements or because the crypto-mechanisms look nicer? I cannot quite understand the motivation. Ciao Hannes Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von ext Bernard Aboba Gesendet: Donnerstag, 21. Februar 2008 21:54 An: emu@ietf.org Betreff: Re: [Emu] EMU Charter revision I also do NOT approve of the current charter revision, for several reasons: a. The Charter text contains statements that are no longer true. For example: Most of these methods are proprietary methods and only a few methods are documented in RFCs. The following EAP methods are now documented in RFCs: EAP-TLS (RFC 2716) EAP-SIM (RFC 4186) EAP-AKA (RFC 4187) EAP-PAX (RFC 4746) EAP-SAKE (RFC 4763) EAP-PSK (RFC 4764) EAP-POTP (RFC 4793) EAP-FAST (RFC 4851) EAP-IKEv2 (RFC 5106) 9 methods claiming to satify RFC 4017 critieria is more than a few. b. The Charter requires support for Channel Bindings without doing the preparatory work to define how Channel Bindings works. Either the requirement should be removed, or a work item should be added to better define the approach to Channel Bindings. c. The text on tunnel methods does not provide enough guidance to avoid potentially fruitless arguments. So far, the EMU WG has not been able to come to consensus on selection of one of the existing tunneling protocols, and efforts to design yet another tunneling protocol haven't gotten very far either. I'd like to see more specific language that would make it clear that work on improving existing tunneling protocols is within scope, and also that the EMU WG, if it cannot come to consensus on a single protocol, can proceed to work on one or more protocols with significant support. d. Password-based methods. While I can understand the desire to limit the number of charter items, I do agree with Dan that work on weak-password methods is important. With some
Re: [Emu] EMU Charter revision
I also do NOT approve of the current charter revision, for several reasons: a. The Charter text contains statements that are no longer true. For example: Most of these methods are proprietary methods and only a few methods are documented in RFCs. The following EAP methods are now documented in RFCs: EAP-TLS (RFC 2716) EAP-SIM (RFC 4186) EAP-AKA (RFC 4187) EAP-PAX (RFC 4746) EAP-SAKE (RFC 4763) EAP-PSK (RFC 4764) EAP-POTP (RFC 4793) EAP-FAST (RFC 4851) EAP-IKEv2 (RFC 5106) 9 methods claiming to satify RFC 4017 critieria is more than a few. b. The Charter requires support for Channel Bindings without doing the preparatory work to define how Channel Bindings works. Either the requirement should be removed, or a work item should be added to better define the approach to Channel Bindings. c. The text on tunnel methods does not provide enough guidance to avoid potentially fruitless arguments. So far, the EMU WG has not been able to come to consensus on selection of one of the existing tunneling protocols, and efforts to design yet another tunneling protocol haven't gotten very far either. I'd like to see more specific language that would make it clear that work on improving existing tunneling protocols is within scope, and also that the EMU WG, if it cannot come to consensus on a single protocol, can proceed to work on one or more protocols with significant support. d. Password-based methods. While I can understand the desire to limit the number of charter items, I do agree with Dan that work on weak-password methods is important. With some of the IPR obstacles likely to fall by the wayside in coming years, it is time for the IETF to re-visit its policy on inclusion of zero knowledge algorithms within standards track documents. Dan Harkins said: Hi Joe, I do NOT approve of the current charter revision, specifically the change that says the password-based method can only be via the tunneled method. I do approve of the inclusion of tunneled methods in the charter though and would be willing to contribute as a reviewer. regards, Dan. On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote: The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00. txt) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe ___ Emu mailing list Emu@ietf.org http://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EMU charter revision
Joe: I approve the current charter revision and am willing to contribute to the tunnel method. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Salowey (jsalowey) Sent: Tuesday, February 19, 2008 2:15 PM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: Re: [Emu] EMU charter revision The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunn el-req-00. txt) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe -Original Message- From: Joseph Salowey (jsalowey) Sent: Monday, February 04, 2008 9:13 PM To: emu@ietf.org Subject: EMU charter revision Below is a revised charter update based on the discussion on the list. I have left the password based method item as a tunnel method because this represents the consensus the working group has reached. I also believe the working group will have to focus on the tunnel method related items for the near term to make progress. This does not mean that we cannot work on additional methods as working group items in the future. Please review the charter update and post any issues you have with the carter. Please also indicate if you have reviewed the proposed charter and have no issues. It is difficult to judge working group consensus unless there are sufficient responses. Thanks, Joe Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods and only a few methods are documented in RFCs. The lack of documented, open specifications is a deployment and interoperability problem. In addition, none of the EAP methods in the standards track implement features such as key derivation that are required for many modern applications. This poses a problem for, among other things, the selection of a mandatory to implement EAP method in new network access technologies. For example, no standards track methods meet new requirements such as those posed in RFC 4017, which documents IEEE 802.11 requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748 and RFC 4017 requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - A mechanism based on strong shared secrets that meets RFC 3748 and RFC 4017 requirements. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A mechanism to support extensible communication within a TLS protected tunnel that meets RFC 3748 and RFC 4017 requirements. This mechanism must support channel bindings in order to meet RFC 4962 requirements and it must provide cryptographic algorithm agility. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. - Enable a TLS-based EAP method to support channel bindings. So as to enable RFC 2716bis to focus solely on clarifications to the existing protocol, this effort will be handled in a separate document. This item will not generate a new method, rather it will enhance EAP-TLS or the TLS based tunnel method work item. - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. This item will be based on the tunnel method work item. Goals and Milestones
Re: [Emu] EMU charter revision
I approve of the current charter revision and would be willing to contribute towards tunneled method development as a contributor. Thanks, Steve Hanna -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Salowey (jsalowey) Sent: Tuesday, February 19, 2008 2:15 PM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: Re: [Emu] EMU charter revision The response to the charter revision has been underwhelming. I am a bit concerned that we do not have enough participation to complete the tunnel method work (most of the recent discussion has been about other methods). I would like to get an idea of the number working group members that approve of working on the tunnel method items and are able to participate in the development of requirements and specifications as contributors and/or reviewers. Please respond to this message and state whether you approve of the current charter revision and what capacity you would be willing to contribute towards tunneled method development: contributor, reviewer or not able to contribute. I have submitted an internet draft attempt at an outline of requirements for tunneled methods (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00. txt) that I hope can provided a starting point for discussions on the list and in the Philadelphia meeting. Thanks, Joe -Original Message- From: Joseph Salowey (jsalowey) Sent: Monday, February 04, 2008 9:13 PM To: emu@ietf.org Subject: EMU charter revision Below is a revised charter update based on the discussion on the list. I have left the password based method item as a tunnel method because this represents the consensus the working group has reached. I also believe the working group will have to focus on the tunnel method related items for the near term to make progress. This does not mean that we cannot work on additional methods as working group items in the future. Please review the charter update and post any issues you have with the carter. Please also indicate if you have reviewed the proposed charter and have no issues. It is difficult to judge working group consensus unless there are sufficient responses. Thanks, Joe Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods and only a few methods are documented in RFCs. The lack of documented, open specifications is a deployment and interoperability problem. In addition, none of the EAP methods in the standards track implement features such as key derivation that are required for many modern applications. This poses a problem for, among other things, the selection of a mandatory to implement EAP method in new network access technologies. For example, no standards track methods meet new requirements such as those posed in RFC 4017, which documents IEEE 802.11 requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748 and RFC 4017 requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - A mechanism based on strong shared secrets that meets RFC 3748 and RFC 4017 requirements. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A mechanism to support extensible communication within a TLS protected tunnel that meets RFC 3748 and RFC 4017 requirements. This mechanism must support channel bindings in order to meet RFC 4962 requirements and it must provide cryptographic algorithm agility. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. - Enable a TLS-based EAP method to support channel bindings. So as to enable RFC 2716bis to focus solely on clarifications to the existing protocol, this effort will be handled in a separate document. This item will not generate a new method, rather it will enhance EAP-TLS or the TLS based tunnel method work item. - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. This item will be based on the tunnel method work item. Goals and Milestones: Done Form design team to work on strong shared secret mechanism Done
