> -----Original Message----- > From: Alan DeKok [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 23, 2007 5:31 AM > To: Gene Chang (genchang) > Cc: Hao Zhou (hzhou); Sam Hartman; [email protected] > Subject: Re: [Emu] Crypto-binding in TTLS-v0 > > Gene Chang (genchang) wrote: > > - 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. > > The key is "related". But they're not words, and we should not treat > them as such. [EC: ] Yes... > > The only important requirement is *consistency*. All systems that are > used to enter passwords must convert the users intention to the same > sequence of bytes. Once that's done, the rest of the network can treat > the password as an opaque token. Doing it this way simplifies the i18n > issues enormously for the authentication systems. > > > - 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. > > Are you really saying that the backend has to *interpret* the password > that the user has entered? i.e. Turn o" into รถ? > > What happens when the back-end has stored the password in hashed > format? Does *it* normalize the password sent to it by the client > before doing the hash? Does it try hashing & comparing both the > normalized and non-normalized passwords? > > If the authentication server can normalize the password, why isn't > that done on the client, which presumably has *more* information about > the users language preferences? Doing that would also permit better > scaling, as more per-user work is done at the edge, where it belongs. > [EC: ] [EC: ] No... I implied that we cannot assume the backend UI and the client system UI will convert human input into normalized passwords the same way unless we explicitly specify the conversion. Otherwise we are in agreement about the typical machinery.
> > - 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. > > I understand what you're trying to get at, but has this been a real > problem in currently deployed networks? > [EC: ] Whether it is a problem or not depends on your perspective and on our attitude of being user friendly. I have seen this issue in the past. Back then, the AAA system could not handle multiple inputs from multiple character sets. The solution then was to require all users of a system to "speak" the same language. In large international deployment, this usually means that all users us our "English" character set. The time is past for us to expect single language systems. > I see these issues as requirements on end user devices, UI, and data > entry schemes. I don't see that these issues should affect the > underlying authentication protocol. The client device should do any > normalization or mangling, and send an opaque sequence of bytes to the > authentication server. The authentication server shouldn't interpret > those bytes, it should just compare them to previously stored credentials. > [EC: ] It depends on where we want to put the normalization and where we want to handle differences between different operating systems. > Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
