Nicolas Williams <Nicolas(_dot_)Williams(_at_)sun(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf