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