Re: Normalization of passwords in SASL and SSH

[nisse%lysator.liu.se@localhost (Niels Möller)]

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

> An ssh implementation that used a unix password file would not
> normalize passwords for comparison.  This is true even if the ssh
> implementation sometimes was used to set passwords, because the passwd
> command could be used independently of the ssh implementation.

I'd like to this description that I think the only sane way to support
passwords beyond ascii on unix systems is to use normalization (either
to utf8 + normalization, or to some system-wide fixed 8-bit character
set. The passwd program, and other programs handling passwords, must
be fixed to do the right thing.

> Does this seem like a reasonable approach to people?  If so, we can
> work on appropriate text.

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

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

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.

Am I missing something? 

To me, (2) seems slightly out of scope for the secsh wg, but I won't
object if such a recommendation is added, provided the text can be
kept short and to the point.

As for (1), I don't care very much either way. Normalizing identifiers
in wire formats is generally a good thing to do, but in this case, it
doesn't really solve the problems with non-normalized entries in
various legacy user databases. I'll also note that what you're
proposing now, appeared to be the wg consensus up to quite recently.

>From the ssh point of view, I think it is very important to keep
changes minimal, so that we can get our severly delayed spec
published at last.

Regards,
/Niels