Re: Normalization of passwords in SASL and SSH

[Sam Hartman <hartmans-ietf%mit.edu@localhost>]

>>>>> "Simon" == Simon Josefsson <jas%extundo.com@localhost> writes:

    Simon> nisse%lysator.liu.se@localhost (Niels Möller) writes:
    >> 2. Add some new text saying that we recommend that systems
    >> supporting non-ascii passwords always normalize passwords and
    >> usernames whenever they are added to the database, or compared
    >> (with or without hashing) to existing entries in the database.

    Simon> I believe the part about storing normalized strings in
    Simon> databases is a poor recommendation.

    Simon> If the password is stored, then I believe it would be
    Simon> better to store the unprepared string than the prepared
    Simon> string.  Otherwise, there is an upgrade problem when
    Simon> SASLprep2 is released.

Note that the sasl working group considered Simon's argument and ended
up disagreeing with him.

As  I recall, Simon  was concerned  about cases  where either  bugs in
Unicode (which do exist) or explicit changes to saslprep 2 designed to
be incompatible would create  a situation where saslprep2(foo) was not
the same as saslprep1(foo).  

The stringprep specification has a reasonable versioning model.  It is
generally true that if applying one version of a stringprep profile to
some string succeeds with unassigned code points prohibited, then
later versions of the same profile will yield the same result.


Simon's concern is that generally true is not the same as always true.

The SASL working group did not decide to adopt this interpretation.  I
don't think a consensus was declared on the reasoning.