Re: [Emu] Crypto-binding in TTLS-v0
Sam Hartman wrote: This isn't a bad idea. Think though about how it interacts with password databases used for multiple purposes. You sometimes get into situations where you need to do normalization both at the client and server. That too can be OK. You just need to think it all through when writing your specs. When people enter passwords, the pop-up window often says CASE SENSITIVE, and Make sure you don't have CAPS-LOCK pressed. Servers don't currently normalize passwords to do case-insensitive comparisons. I don't see why they would need to normalize passwords for composed/decomposed characters. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Sam Hartman wrote: Alan The whole composed / decomposed thing is a nightmare for Alan passwords. And one the emu working group needs to deal with. RFC 3629 says that overlong sequences are invalid: Implementations of the decoding algorithm above MUST protect against decoding invalid sequences. For instance, a naive implementation may decode the overlong UTF-8 sequence C0 80 ... I would therefore follow the lead of the UTF-8 experts, and suggest that decomposed characters are overlong, and thus invalid for the purposes of EMU. Therefore, UTF-8 sequences must consist solely of composed characters. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Alan == Alan DeKok [EMAIL PROTECTED] writes: Alan Sam Hartman wrote: The whole composed / decomposed thing is Alan a nightmare for passwords. And one the emu working group needs to deal with. Alan RFC 3629 says that overlong sequences are invalid: AlanImplementations of the decoding algorithm above MUST Alan protect against decoding invalid sequences. For instance, a Alan naive implementation may decode the overlong UTF-8 sequence Alan C0 80 ... Alan I would therefore follow the lead of the UTF-8 experts, Alan and suggest that decomposed characters are overlong, and Alan thus invalid for the purposes of EMU. Therefore, UTF-8 Alan sequences must consist solely of composed characters. This will be my last message on the subject. There are approaches to consider in this space, but it's not that simple. If only it were that simple. One of the simplest problems with this approach is that not all the combined characters that you need actually exist. Another potential issue is that I think normalizing towards decomposed may be easier than normalizing towards combined. --Sam ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Alan == Alan DeKok [EMAIL PROTECTED] writes: Alan My opinion is that normalization belongs at the edge, Alan which generally also has information about the language and Alan locale. Once normalization is performed, the password can Alan be sent over the wire *without* language or locale Alan information to the server. This isn't a bad idea. Think though about how it interacts with password databases used for multiple purposes. You sometimes get into situations where you need to do normalization both at the client and server. That too can be OK. You just need to think it all through when writing your specs. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Gene Chang (genchang) wrote: [EC: ] [EC: ] No... I implied that we cannot assume the backend UI and the client system UI will convert human input into normalized passwords the same way unless we explicitly specify the conversion. Yes. [EC: ] Whether it is a problem or not depends on your perspective and on our attitude of being user friendly. I have seen this issue in the past. Back then, the AAA system could not handle multiple inputs from multiple character sets. The solution then was to require all users of a system to speak the same language. In large international deployment, this usually means that all users us our English character set. The time is past for us to expect single language systems. I agree. The tests I've done on multiple AAA systems indicate that the majority now support UTF-8. This solves many 18n issues, other than composed / decomposed characters. [EC: ] It depends on where we want to put the normalization and where we want to handle differences between different operating systems. My opinion is that normalization belongs at the edge, which generally also has information about the language and locale. Once normalization is performed, the password can be sent over the wire *without* language or locale information to the server. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Gene Chang (genchang) wrote: - Passwords aren't just a random number. - Users often need mnemonic aids to accurately reproduce their passwords. This is why often passwords are related to words or phrases. The key is related. But they're not words, and we should not treat them as such. The only important requirement is *consistency*. All systems that are used to enter passwords must convert the users intention to the same sequence of bytes. Once that's done, the rest of the network can treat the password as an opaque token. Doing it this way simplifies the i18n issues enormously for the authentication systems. - It is also important that these passwords are normalized between the user system and the backend systems as the strings generated by the user's system may be handled differently from the backend. Are you really saying that the backend has to *interpret* the password that the user has entered? i.e. Turn o into ö? What happens when the back-end has stored the password in hashed format? Does *it* normalize the password sent to it by the client before doing the hash? Does it try hashing comparing both the normalized and non-normalized passwords? If the authentication server can normalize the password, why isn't that done on the client, which presumably has *more* information about the users language preferences? Doing that would also permit better scaling, as more per-user work is done at the edge, where it belongs. - There may be more variety for users that use multiple systems or speak multiple languages or for backend systems that support a community that use more than one language. I understand what you're trying to get at, but has this been a real problem in currently deployed networks? I see these issues as requirements on end user devices, UI, and data entry schemes. I don't see that these issues should affect the underlying authentication protocol. The client device should do any normalization or mangling, and send an opaque sequence of bytes to the authentication server. The authentication server shouldn't interpret those bytes, it should just compare them to previously stored credentials. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
-Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: Thursday, August 23, 2007 5:31 AM To: Gene Chang (genchang) Cc: Hao Zhou (hzhou); Sam Hartman; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Gene Chang (genchang) wrote: - Passwords aren't just a random number. - Users often need mnemonic aids to accurately reproduce their passwords. This is why often passwords are related to words or phrases. The key is related. But they're not words, and we should not treat them as such. [EC: ] Yes... The only important requirement is *consistency*. All systems that are used to enter passwords must convert the users intention to the same sequence of bytes. Once that's done, the rest of the network can treat the password as an opaque token. Doing it this way simplifies the i18n issues enormously for the authentication systems. - It is also important that these passwords are normalized between the user system and the backend systems as the strings generated by the user's system may be handled differently from the backend. Are you really saying that the backend has to *interpret* the password that the user has entered? i.e. Turn o into ö? What happens when the back-end has stored the password in hashed format? Does *it* normalize the password sent to it by the client before doing the hash? Does it try hashing comparing both the normalized and non-normalized passwords? If the authentication server can normalize the password, why isn't that done on the client, which presumably has *more* information about the users language preferences? Doing that would also permit better scaling, as more per-user work is done at the edge, where it belongs. [EC: ] [EC: ] No... I implied that we cannot assume the backend UI and the client system UI will convert human input into normalized passwords the same way unless we explicitly specify the conversion. Otherwise we are in agreement about the typical machinery. - There may be more variety for users that use multiple systems or speak multiple languages or for backend systems that support a community that use more than one language. I understand what you're trying to get at, but has this been a real problem in currently deployed networks? [EC: ] Whether it is a problem or not depends on your perspective and on our attitude of being user friendly. I have seen this issue in the past. Back then, the AAA system could not handle multiple inputs from multiple character sets. The solution then was to require all users of a system to speak the same language. In large international deployment, this usually means that all users us our English character set. The time is past for us to expect single language systems. I see these issues as requirements on end user devices, UI, and data entry schemes. I don't see that these issues should affect the underlying authentication protocol. The client device should do any normalization or mangling, and send an opaque sequence of bytes to the authentication server. The authentication server shouldn't interpret those bytes, it should just compare them to previously stored credentials. [EC: ] It depends on where we want to put the normalization and where we want to handle differences between different operating systems. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
Lakshminath: Do you mean channel binding, not compound binding? I thought crypto-binding is compound-binding. I think publishing a widely deployed EAP method is orthogonal to publishing a new method meeting EMU charter. I agree publishing the existing method as deployed is something needs to be done quickly. I am still doubtful that adding the extra stuff required to meet the charter (crypto-binding, crypto-agility, synchronized result indication, internationalization), to the existing method can be done without breaking backward compatibility. If indeed breaks it, then the argument of TTLS is widely deployed doesn't stand anymore. The new method or new version of the old method still needs to be implemented and deployed. -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 12:45 AM To: Alan DeKok Cc: Sam Hartman; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 I would like to see the crypto-binding stuff (not compound binding -- as others have noted, we don't have consensus on that topic) and extensibility (how to add new attributes) specified. That should not take more than 1-2 months to write-up, review and finalize :). That should also be least disruptive to existing implementations. I would also like to see TTLS-v0 published very soon. regards, Lakshminath On 8/21/2007 9:38 PM, Alan DeKok wrote: Sam Hartman wrote: So, if EMU is going to base its work on something existing, it is probably important for EMU to take on the entire method. If consensus is to use EAP-TTLS, then I would suggest publishing the base EAP-TTLS document pretty much as-is as a standards-track document. The additional EMU requirements can be addressed in a separate document. This process lets us get something done quickly. I would prefer to void spending years talking about a new EAP method, followed by years of trying to get it widely deployed. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Yeah, sorry. I meant channel binding. I am not necessarily tying TTLS-v0 with the password-based EMU method deliverable. If the extensibility is there, that decision could be separated from the much needed publication of TTLS-v0. regards, Lakshminath On 8/21/2007 11:17 PM, Hao Zhou (hzhou) wrote: Lakshminath: Do you mean channel binding, not compound binding? I thought crypto-binding is compound-binding. I think publishing a widely deployed EAP method is orthogonal to publishing a new method meeting EMU charter. I agree publishing the existing method as deployed is something needs to be done quickly. I am still doubtful that adding the extra stuff required to meet the charter (crypto-binding, crypto-agility, synchronized result indication, internationalization), to the existing method can be done without breaking backward compatibility. If indeed breaks it, then the argument of TTLS is widely deployed doesn't stand anymore. The new method or new version of the old method still needs to be implemented and deployed. -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 12:45 AM To: Alan DeKok Cc: Sam Hartman; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 I would like to see the crypto-binding stuff (not compound binding -- as others have noted, we don't have consensus on that topic) and extensibility (how to add new attributes) specified. That should not take more than 1-2 months to write-up, review and finalize :). That should also be least disruptive to existing implementations. I would also like to see TTLS-v0 published very soon. regards, Lakshminath On 8/21/2007 9:38 PM, Alan DeKok wrote: Sam Hartman wrote: So, if EMU is going to base its work on something existing, it is probably important for EMU to take on the entire method. If consensus is to use EAP-TTLS, then I would suggest publishing the base EAP-TTLS document pretty much as-is as a standards-track document. The additional EMU requirements can be addressed in a separate document. This process lets us get something done quickly. I would prefer to void spending years talking about a new EAP method, followed by years of trying to get it widely deployed. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Alan == Alan DeKok [EMAIL PROTECTED] writes: Alan Hao Zhou (hzhou) wrote: I think publishing a widely deployed EAP method is orthogonal to publishing a new method meeting EMU charter. I agree publishing the existing method as deployed is something needs to be done quickly. I am still doubtful that adding the extra stuff required to meet the charter (crypto-binding, crypto-agility, synchronized result indication, internationalization), Alan I'm not sure why internationalization is an issue. This Alan came up in RADEXT a while ago. The consensus at the time Alan was that RFC 4282 discusses internationalization of the NAI, Alan and that passwords don't need to be internationalized. Alan Internationalization matters for *display* to end users. Alan Internationalization is about *languages*. Passwords aren't Alan displayed, and they aren't words in any language. They're Alan opaque tokens that users have memorized, and can repeat on Alan demand to demonstrate secret knowledge. The consensus of the SASL and Kerberos communities has been different. In particular, these communities believe that it is strongly desirable that the same password when entered on two different systems actually work. To get that, you need to deal with issues like normalization. Otherwise, if you use a system with input methods that produce combined characters you will get different results than if you use input methods that produce decomposed characters. At some level, this is an implementation issue for the server. However to support the server, you definitely need to label the character set, discuss any normalization that the client should do (often none) and set interoperability goals. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
-Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 5:56 AM To: Hao Zhou (hzhou) Cc: Sam Hartman; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Hao Zhou (hzhou) wrote: I think publishing a widely deployed EAP method is orthogonal to publishing a new method meeting EMU charter. I agree publishing the existing method as deployed is something needs to be done quickly. I am still doubtful that adding the extra stuff required to meet the charter (crypto-binding, crypto-agility, synchronized result indication, internationalization), I'm not sure why internationalization is an issue. This came up in RADEXT a while ago. The consensus at the time was that RFC 4282 discusses internationalization of the NAI, and that passwords don't need to be internationalized. Internationalization matters for *display* to end users. Internationalization is about *languages*. Passwords aren't displayed, and they aren't words in any language. They're opaque tokens that users have memorized, and can repeat on demand to demonstrate secret knowledge. - Passwords aren't just a random number. - Users often need mnemonic aids to accurately reproduce their passwords. This is why often passwords are related to words or phrases. - It is also important that these passwords are normalized between the user system and the backend systems as the strings generated by the user's system may be handled differently from the backend. - There may be more variety for users that use multiple systems or speak multiple languages or for backend systems that support a community that use more than one language. Gene Chang to the existing method can be done without breaking backward compatibility. If indeed breaks it, then the argument of TTLS is widely deployed doesn't stand anymore. The new method or new version of the old method still needs to be implemented and deployed. One of the suggestions at IETF 69 was that TTLS was at least safely backwards compatible with any new feature. i.e. The new features would require changes to the content of the TLS tunnel, and not much else. Those changes could be done via AVP's with the M bit set. Existing clients would know enough to fail when they saw an M bit set on an AVP that they didn't understand. Do you expect that crypto-binding/agility features would require changes that are not compatible with existing TTLS deployments? If so, can you provide examples? Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
As a matter of process, if EMU is going to satisfy its charter item regarding passwords, it will need to refer to a standards-track EAP type of some kind. The existing process for getting EAP methods published as RFCs does not result in standards track RFCs. So, if EMU is going to base its work on something existing, it is probably important for EMU to take on the entire method. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Sam Hartman wrote: So, if EMU is going to base its work on something existing, it is probably important for EMU to take on the entire method. If consensus is to use EAP-TTLS, then I would suggest publishing the base EAP-TTLS document pretty much as-is as a standards-track document. The additional EMU requirements can be addressed in a separate document. This process lets us get something done quickly. I would prefer to void spending years talking about a new EAP method, followed by years of trying to get it widely deployed. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
I would like to see the crypto-binding stuff (not compound binding -- as others have noted, we don't have consensus on that topic) and extensibility (how to add new attributes) specified. That should not take more than 1-2 months to write-up, review and finalize :). That should also be least disruptive to existing implementations. I would also like to see TTLS-v0 published very soon. regards, Lakshminath On 8/21/2007 9:38 PM, Alan DeKok wrote: Sam Hartman wrote: So, if EMU is going to base its work on something existing, it is probably important for EMU to take on the entire method. If consensus is to use EAP-TTLS, then I would suggest publishing the base EAP-TTLS document pretty much as-is as a standards-track document. The additional EMU requirements can be addressed in a separate document. This process lets us get something done quickly. I would prefer to void spending years talking about a new EAP method, followed by years of trying to get it widely deployed. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Nancy Winget (ncamwing) wrote: Thanks Alan, I am glad to see that the evaluation is continuing on the thread.I think both TTLS and EAP-FAST are being widely deployed and both merit consideration. I think EAP-FAST has been considered, and has little support. I've never seen an EAP-FAST deployment, and most people I talk to haven't seen one, either. Most people I talk to don't plan on supporting EAP-FAST any time soon. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
Alan, I think we can all agree that without the help of the market analysts measuring deployment, comparing our personal perceptions of deployment is a bit like the five blind men and the elephant. I had the pleasure of helping to bring TTLS into the market. The industry conditions in 2003 was very different from 2005-2006. 2003 was a greenfield market so adoption of a strong EAP method was instant (especially with the then prevailing embarrassment of WEP as a protection scheme). By the time EAP-FAST arrived, EAP-FAST had to earn adoption on to its own merits. The adoption characteristic was naturally different from TTLS or PEAP. Gene Eugene Chang (genchang) WNBU, Technical Leader Office: 603-559-2978 Mobile: 781-799-0233 -Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 10:57 AM To: Gene Chang (genchang) Cc: Nancy Winget (ncamwing); Ryan Hurst; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Gene Chang (genchang) wrote: It is not unusual for developers to be unaware of the breath of the EAP-FAST market adoption. It has been growing under the radar for a lot of people since market research firms do not track market share of different EAP methods. I do rather a bit more than just development. I work with people deploying systems from 100 to 10M+ users. I don't see EAP-FAST being adopted. I *do* hear rumors about EAP-FAST from enterprises who have bought single source solutions. Part of the misperception that EAP-FAST has no market presence has been because no one has been drawing attention to the adoption success of EAP-FAST. I am hoping to assemble some public data to shed a light on the secret life of EAP-FAST. People haven't drawn attention to the adoption success of PEAP or TTLS, either. Instead, people just deployed it in large numbers. I started hearing about PEAP and TTLS almost as soon as they were proposed. There was quick and immediate demand for both protocols from a wide range of systems (small, medium, large). I've seen nothing similar happen with EAP-FAST (so far). Part of the misperception that EAP-FAST has a large market presence has been that the people who are deploying it don't talk to the people *not* deploying it, and vice versa. Within the EAP-FAST camp, it looks like there's wide-spread adoption. Outside of it, it just doesn't come up in any conversation. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Gene Chang (genchang) wrote: I think we can all agree that without the help of the market analysts measuring deployment, comparing our personal perceptions of deployment is a bit like the five blind men and the elephant. I disagree. Sufficient volumes of data make personal perception statistically significant. That's just what market analysts do. The adoption characteristic was naturally different from TTLS or PEAP. The only relevant characteristic is volume of deployments. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
There is an EAP-FAST module for EAPHost plug-in, which currently uses three hard coded inner methods, EAP-GTC, EAP-MSCHAPv2 and EAP-TLS. But it can be extended to work with EAPHost supplicant interface to load any inner method registered with EAPHost. Will you have a POTP plug-in soon? The problem is to find a server that supports provisioning with POTP. I can work with you to make it happen. -Original Message- From: Gene Chang (genchang) Sent: Thursday, August 16, 2007 11:36 AM To: [EMAIL PROTECTED]; emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 Dave, There is an EAP-FAST implementation on FreeRADIUS from Jouni Malinan. I don't know how much testing has already gone into the module. I don't know of a client side implementation with APIs for you to integrate the SecurID PAC provisioning. Gene -- -- Eugene Chang (genchang) WNBU, Technical Leader Office: 603-559-2978 Mobile: 781-799-0233 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 11:01 AM To: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I with Alan on this. I still haven't seen one yet either. But I'd love to see a version of EAP-FAST that I _could_ work with. Meaning; - it runs with something more accessible than the Cisco ACS server, preferably an open source or reference copy. Maybe even an Windows/IAS plugin. - there is a Windows EAPhost supplicant availible, preferably with interfaces for tunnelled methods and/or interfaces for the ID we wrote for SecurID PAC provisioning. draft-cam-winget-eap-fast-potp-provisioning-00.txt (hmm... time to renew that) If you have any of this, let me know. Dave Mitton, RSA - Security Division of EMC. Original Message From: [EMAIL PROTECTED] Date: Aug 16, 2007 10:13 To: Alan DeKok[EMAIL PROTECTED], Nancy Winget (ncamwing) [EMAIL PROTECTED] Cc: Ryan Hurst[EMAIL PROTECTED], emu@ietf.org Subj: RE: [Emu] Crypto-binding in TTLS-v0 Alan, It is not unusual for developers to be unaware of the breath of the EAP-FAST market adoption. It has been growing under the radar for a lot of people since market research firms do not track market share of different EAP methods. Part of the misperception that EAP-FAST has no market presence has been because no one has been drawing attention to the adoption success of EAP-FAST. I am hoping to assemble some public data to shed a light on the secret life of EAP-FAST. Gene -- -- Eugene Chang (genchang) WNBU, Technical Leader Office: 603-559-2978 Mobile: 781-799-0233 -Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 8:46 AM To: Nancy Winget (ncamwing) Cc: Ryan Hurst; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Nancy Winget (ncamwing) wrote: Thanks Alan, I am glad to see that the evaluation is continuing on the thread.I think both TTLS and EAP-FAST are being widely deployed and both merit consideration. I think EAP-FAST has been considered, and has little support. I've never seen an EAP-FAST deployment, and most people I talk to haven't seen one, either. Most people I talk to don't plan on supporting EAP-FAST any time soon. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
On Thu, Aug 16, 2007 at 11:39:31AM -0400, Alan DeKok wrote: Gene Chang (genchang) wrote: There is an EAP-FAST implementation on FreeRADIUS from Jouni Malinan. If there was, I would have known about it. Yes, and I would assume I would also be aware of this should such a thing have happened ;-). Jouni has added EAP-FAST to hostapd and to wpa_supplicant. While hostapd is a RADIUS server, it's pretty minimal. i.e. not database support, no policy language, etc. I added EAP-FAST support to hostapd mainly to make it (much) easier for me to test client side code in wpa_supplicant. Anyway, that means that there is an open source implementation available for both the server and peer side of EAP-FAST should someone be interested in testing them and was just waiting for broader set of available implementations or access to source code. I would obviously be interested in any feedback on the implementations, too. I try to run as complete interop tests with other implementations as feasible, but don't really have unlimited resources for doing this, so any additional testing would be welcome. Sure, hostapd as a RADIUS server is not meant for large and complex deployments, but I think it works well as a testbed component for testing various EAP methods, including EAP-FAST. In addition, based on past history, it looks like I have quite open view in adding support for new EAP methods regardless of their completeness, popularity, or even suitability for anything ;-). I see this as one of the best ways to evaluate protocol designs and specifications and more or less mandatory part of standard development. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
Hi Ryan, Well, I thought presenting tunneled methods were in general out of scope for the password based authentication. But it is a viable means to meeting the requirements.which I believe, is what the design team presented with PP-EAP. My point is that if we contemplate TTLS as a working group item, we should also be analyzing PEAP and EAP-FAST. Though PEAP may not have as much traction, I believe though EAP-FAST was instantiated after TTLS, is also widely deployed and addresses some of the deployment challenges (like crypto binding and the ability to establish tunnels without the need of asymmetric crypto) that were presented by PEAP and TTLS. Nancy. -Original Message- From: Ryan Hurst [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 4:45 PM To: Nancy Winget (ncamwing); Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I agree that PEAPv0 is a orthogonal issue Nancy, did not mean to suggest it was although in hindsight I can see how it might have read that way. On the topic of TTLS as a EMU working group item, I am not opposed to this as from the customer engagements I have had it appears to have a very strong existing deployment across a number of customer segments and from a protocol standpoint is pretty clean (It just needs a couple of additions like CryptoBindings). Ryan -Original Message- From: Nancy Winget (ncamwing) [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 4:29 PM To: Ryan Hurst; Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that there are deployments out there. However, I think that is a different item/issue than having it be taken as an EMU work item. For instance, it can be published as an informational RFC much the same way EAP-FAST is now RFC 4851. It is not clear why TTLS should become an EMU work item or standardized as the means to deliver a strong password based method. There are other tunnel methods such as PEAP and EAP-FAST that can also meet the requirements. If we are discussing what would need to be changed/updated to TTLS to meet the requirements, perhaps we should also be evaluating PEAP and EAP-FAST as alternatives as they also meet the requirements and perhaps more so than TTLS. Nancy. -Original Message- From: Ryan Hurst [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 9:57 AM To: Alan DeKok; Stephen Hanna Cc: emu@ietf.org Subject: RE: [Emu] Crypto-binding in TTLS-v0 I agree, I also want to see PEAPv0 published for the same reasons (I am working on a draft of this, no ETA I can share at this time). -Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 9:47 AM To: Stephen Hanna Cc: emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Stephen Hanna wrote: draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has been implemented by vendors and adopted by other SDOs. We plan to submit this for RFC status as part of the ongoing effort to document popular EAP methods as RFCs. I think this document should be published. It's widely used, and deserves documentation in the IETF process. As to your question about whether EAP-TTLSv0 is a chartered work item for the EMU WG, that may depend in part on how the WG decides to address the work item to deliver a strong password-based method. At the EMU WG in Chicago, there were two proposals: my proposal to use EAP-TTLSv0 with these new AVPs and another proposal to define a new EAP method especially for this purpose. The results of a hum were inconclusive and it was agreed to take this discussion to the email list. I am in favor of EAP-TTLSv0 + new AVP's. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
Thanks Alan, I am glad to see that the evaluation is continuing on the thread.I think both TTLS and EAP-FAST are being widely deployed and both merit consideration. Nancy. -Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 7:45 PM To: Nancy Winget (ncamwing) Cc: Ryan Hurst; Stephen Hanna; emu@ietf.org Subject: Re: [Emu] Crypto-binding in TTLS-v0 Nancy Winget (ncamwing) wrote: Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that there are deployments out there. However, I think that is a different item/issue than having it be taken as an EMU work item. For instance, it can be published as an informational RFC much the same way EAP-FAST is now RFC 4851. I would prefer at least that. It is not clear why TTLS should become an EMU work item or standardized as the means to deliver a strong password based method. There are other tunnel methods such as PEAP and EAP-FAST that can also meet the requirements. TTLS has a much more flexible structure for in-tunnel transport than PEAP does. TTLS is also widely deployed than EAP-FAST. If we are discussing what would need to be changed/updated to TTLS to meet the requirements, perhaps we should also be evaluating PEAP and EAP-FAST as alternatives as they also meet the requirements and perhaps more so than TTLS. I believe that the evaluation is ongoing on this list. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
Glen Zorn writes... I thought that the new method had already been defined by a design team? As a process observation, the work product and decisions of a design team are subject to acceptance by WG consensus. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Crypto-binding in TTLS-v0
The charter item is for a password based method that supports legacy password databases. I do not believe Crypto-binding is strictly required to satisfy this charter item. TTLS is being considered as part of the solution to this charter item, not necessarily a as method for tunneling generic authentication mechanisms so it is not clear if crypto-binding is required. However, for a protocol that tunnels arbitrary authentication mechanisms it is highly desirable to provide crypto-binding. -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 1:42 AM To: emu@ietf.org Subject: [Emu] Crypto-binding in TTLS-v0 This probably has been asked before, but I will ask it in a different context: as we try to standardize EAP-TTLS in EMU (is this a charter item, Joe?) is there a plan to support cryto-binding in TTLS-v0? My opinion: well, yeah! :) regards, Lakshminath ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Nancy Winget (ncamwing) wrote: Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that there are deployments out there. However, I think that is a different item/issue than having it be taken as an EMU work item. For instance, it can be published as an informational RFC much the same way EAP-FAST is now RFC 4851. I would prefer at least that. It is not clear why TTLS should become an EMU work item or standardized as the means to deliver a strong password based method. There are other tunnel methods such as PEAP and EAP-FAST that can also meet the requirements. TTLS has a much more flexible structure for in-tunnel transport than PEAP does. TTLS is also widely deployed than EAP-FAST. If we are discussing what would need to be changed/updated to TTLS to meet the requirements, perhaps we should also be evaluating PEAP and EAP-FAST as alternatives as they also meet the requirements and perhaps more so than TTLS. I believe that the evaluation is ongoing on this list. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
