Alan DeKok <al...@deployingradius.com> writes: > Simon Josefsson wrote: >> Should we suggest that passwords are sent over the wire at all? In good >> systems that should be the exception. > > It is widely deployed today with TTLS. I think that allowing this > practice to continue is a requirement.
I agree, but that does not necessarily mean that passwords-sent-over-the-wire and passwords-sent-hashed must have the same internationalization treatment or considerations. >> 1) Usernames. Should be sent over the wire as-is, or possibly >> Net-UTF-8. It is not clear to me that the even the weak NFC part of >> Net-UTF-8 is always a good idea for usernames, you could just send the >> username as-is and require that COMPARISONS are done in a way that >> reduces ambitious. > > Ouch. I fundamentally disagree. See RFC 4282, and my attempt to > update it, based on real-world deployment experience: > > http://tools.ietf.org/html/draft-dekok-radext-nai-00 > > My document explains why it's difficult (i.e. impossible) for third > parties to "normalize" the data. Interesting! It is good to see work in this area, and your reasons appears good to me. I believe it is desirable to reduce the amount of string normalization that happens, and instead use comparison-rules when possible, but sometimes normalization is required for one reason or the other. As soon as normalization rules are suggested, I believe it is worthwhile to evaluate why comparison-rules are not sufficient, and your document address that. >> The problem with normalization early is that you end up with a interop >> problem where both the client and server needs to implement the exact >> same normalization algorithms for things to be robust. If normalization >> only happens in one implementation, things will be predictable. > > RFC 5198 specifies a normalized form. If two implementations > "normalize" to the RFC 5198 form differently, one of them is wrong. Sure, but see section 4 of RFC 5198. If it happens that NFC backwards compatibility is broken, you end up with the interop problem. This has happened before for NFKC which has caused (theoretical) interop problems for IDNA and SASLprep -- if two implementations of RFC 3454 use different Unicode versions, they don't necessarily interop. /Simon _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
