Subject: Re: Normalization of passwords in SASL and SSH

From: Damien Miller <[email-masked]>
Date: Thu, 02 Dec 2004 14:25:57 +1100

Sam Hartman wrote:
> 
> Hi.  A discussion in the IETF 61 secsh meeting re-opened the issue of
> how to handle password normalization for passwords received by the
> server.  The ssh protocol had adopted a significantly different
> solution to this problem than the sasl plain mechanism.  This concerns
> me; I want to either solve the problem of password normalization in a
> consistent manner or to understand why the ssh requirements are
> different than the sasl requirements.  

What are the threats that this normalisation is intended to address?

I'm wary of any recommendations to substantively change the protocol,
especially ones that require implementation of a 91-page RFC
(stringprep) + SASLprep in the privileged path of a server.

-d

---

From: der Mouse <[email-masked]>
Date: Wed, 1 Dec 2004 23:10:06 -0500 (EST)

>> Hi.  A discussion in the IETF 61 secsh meeting re-opened the issue
>> of how to handle password normalization for passwords received by
>> the server.

As an implementer, writing code for use on systems where usernames and
passwords as handled by the OS are octet sequences rather than
character sequences, I think that any such specification is a mistake.
If such language survives, I will have to either blow off conformance
to that aspect of the spec or simply reject non-ASCII usernames and
passwords out of hand, since for non-ASCII strings I have no way, no
way whatsoever, to tell whether the octet sequence stored in the OS's
database corresponds in any useful way to the character sequence I get
on the wire.  (The information regarding what, if any, characters those
octet sequences are intended to correspond to quite probably is not
stored anywhere except human minds.)

Similar remarks apply to file names.

Not to mention that, as Damien points out, any such normalization, even
on systems where usernames and passwords _are_ character sequences,
involves a lot of complexity in a rather critical path.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Dec 2004 06:29:01 -0500

>>>>> "Damien" == Damien Miller <[email-masked]> writes:

    Damien> Sam Hartman wrote:
    >>  Hi.  A discussion in the IETF 61 secsh meeting re-opened the
    >> issue of how to handle password normalization for passwords
    >> received by the server.  The ssh protocol had adopted a
    >> significantly different solution to this problem than the sasl
    >> plain mechanism.  This concerns me; I want to either solve the
    >> problem of password normalization in a consistent manner or to
    >> understand why the ssh requirements are different than the sasl
    >> requirements.

    Damien> What are the threats that this normalisation is intended
    Damien> to address?

This isn't about threats so much as interoperability.  From an
internationalization standpoint, we desire that if a user enters their
password it will work regardless of what OS and client software they
used to enter their password.  Doing so requires normalization.

Note that stringprep is already required by IDN.  I suspect that we're
going to end up needing implementations of IDN suitable for running in
the TCB of a host even if ssh implementations do not end up needing
IDN on the server side.

Also, the normalization step does not strictly need to run in the
privilege domain of the rest of the authenication component.
Normalization is an operation on a string, yielding a string,
requiring access only to a variety of tables.  You want to isolate the
normalization performed on behalf of one authentication context from
that done on behalf of another context.  

--Sam