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
[Emu] Chennal binding
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes: Lakshminath I would like to see the crypto-binding stuff (not Lakshminath compound binding -- as others have noted, we don't Lakshminath have consensus on that topic) and extensibility (how Lakshminath to add new attributes) specified. I'd really appreciate it if someone would think hard about the interactions of draft-housley-aaa-key-mgmt and channel binding. I'd like to understand whether we can meet all the requirements of that BCP without channel binding and if not, what we need to do about it. ___ 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
