Re: Normalization of passwords in SASL and SSH

[Simon Josefsson <jas%extundo.com@localhost>]

Sam Hartman <hartmans-ietf%mit.edu@localhost> writes:

> I'm proposing the following approach to address this situation.  For
> both ssh and sasl plain, normalization should be done on the server if
> at all.  Only the server knows what the password store technology in
> use is.

For what it's worth, I support this view.  I'd like to add one other
advantage, that I feel is a strong argument for this approach.

If client-side normalization is deployed based on SASLprep in SSH,
upgrading to a new revision of SASLprep will be more difficult.  This
is because the server may need to know which SASLprep revision is
used, to select the hashed password that was prepared using the proper
SASLprep version.  That could be solved by signaling the SASLprep
version in SSH, but I'd prefer to avoid that, if possible.

Further, if the revised SASLprep turn out to be backwards
incompatible, which doesn't seem unlikely (given the normalization
flaw in Unicode 3.2), the server would receive SASLprep(password).
Computing SASLprep2(SASLprep(x)) may not in general be equal to
SASLprep2(x).

Having normalization occur on the server also make it easier to switch
from SASLprep to something else in the future.  In my opinion, sending
SASLprep data over the wire should always be avoided, in favor of
sending Unicode code points.

I think we should get used to the idea of a SASLprep2, and design
protocols that use SASLprep with this in mind.

Thanks,
Simon