Alan DeKok <al...@deployingradius.com> writes: > Simon Josefsson wrote: >> Perhaps you want to consider an approach where passwords are normalized >> using Net-UTF-8 and usernames are sent as-is but mandate that >> username-to-username comparisons use Net-UTF-8 on both strings before >> comparing them. > > I would like to see some more details around this suggestion. Issues > of data entry (user -> keyboard -> ?? -> EAP) and user store (admin -> > keyboard -> ??? -> database) are important.
Yes, more details are definitely needed. > Something like: > > The canonical form of the username and password as carried in EAP or > placed in an authentication store SHOULD be Net-UTF-8. Should we suggest that passwords are sent over the wire at all? In good systems that should be the exception. I think there are three different kind of strings that needs to be discussed. 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. 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. 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. >> Username and passwords strings are somewhat different beasts, and it >> does not necessarily make sense to use the same normalization or >> comparison algorithms for both strings. > > Why not? memcmp(s1, s2, length) would be fine if we assume that the > strings are both canonicalized *before* the comparison is done. Stating > *who* does the canonicalization ensures that only a limited number of > entities do the canonicalization, which minimizes errors and > inter-operability. 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. Of course, it is not possible to avoid this problem for hashed password strings. They need to be normalized before hashing happens, on all systems. > The nice thing about that requirement is that it is very compatible > with sites choosing to not use Net-UTF-8. If they choose to put > something else in a DB as the authentication credentials, it will work > so long as the supplicant puts exactly the same data into the EAP packet. Right, it is a tradeoff between different neat properties. I'm not sure we have a good understanding of all the factors that are important yet. /Simon _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
