Nicolas Williams <Nicolas.Williams@xxxxxxx> writes: > On Fri, Sep 25, 2009 at 02:00:58PM +0200, Simon Josefsson wrote: >> I'm hesitant to bring this up because it has so many other concerns, but >> if you are looking for alternatives, another one is to flag the >> normalization algorithm used in the protocol. E.g., add a flag >> 'c=saslprep' or 'c=net-utf-8' or 'c=utf-8'. This makes it possible to >> apply a better heuristic on the server side. Or treat normalization >> like the hash algorithm, since it is also an continuously evolving and >> apparently never-perfected technology, and make the mechanism name >> SCRAM-SHA-1-SASLPREP or SCRAM-SHA-1-NET-UTF-8. (You can figure out the >> problems with this approach as good as I can, so I won't go into them..) > > It doesn't really help because it'd have to be the server telling the > client what the user's password's form is -- not the other way around. > Chances are the password's been hashed already; recovering from use of a > different NF (or just-utf-8) is not going to be feasible. The server can store the password hashed in a couple of different forms, and use the flag to determine which to use. I realize that is possible anyway (just iterate through all locally stored hashes), although without some text in the document I don't think many servers will implement that. /Simon _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf