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. > 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. > There are some indication that the algorithm of > comparing two strings for equality is simpler to make robust and > ambigious-free than an algorithm that normalize strings. Yes. The systems which do end-user input likely have enough information to normalize the data. No one else does. As a result, everyone else should compare the two strings for equality. They should not normalize the strings. > 2) Passwords sent to servers. This has similar properties as 1) but > there could be differences in how they are treated. > > 3) Passwords sent to servers only in hashed form. This has stricter > normalization requirements than 1) and 2) -- NFC is most certainly > needed, and probably something more, similar to SASLprep but preferably > without some of the problems that SASLprep has. I beleive that (2) and (3) are the same case. For (3), we will end up checking for: hash(p1) == hash(p2) For strong hashes, the simplest way to ensure this is true is if: p1 == p2 > 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. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
