> -----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
