Subject: Re: Normalization of passwords in SASL and SSH

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Nov 2004 20:28:25 -0800

>>>>> "Niels" == Niels Möller <[email-masked]> writes:

    Niels> If I understand your proposal, as it applies to ssh, you're
    Niels> suggesting that we should

    Niels> 1. Strike the new text on normalization, in effect
    Niels> reverting to what was in older drafts
    Niels> (e.g. draft-ietf-secsh-userauth-18.txt says "Note that the
    Niels> password is encoded in ISO-10646 UTF-8. It is up to the
    Niels> server how it interprets the password and validates it
    Niels> against the password database.").

    Niels> 2. Add some new text saying that we recommend that systems
    Niels> supporting non-ascii passwords always normalize passwords
    Niels> and usernames whenever they are added to the database, or
    Niels> compared (with or without hashing) to existing entries in
    Niels> the database.

And say that ssh implementations that both store the passwords and
compare them SHOULD use saslprep for normalization.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Nov 2004 20:29:27 -0800

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> [email-masked] (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.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Nov 2004 20:28:25 -0800

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Nov 2004 20:29:27 -0800