Re: additional core draft nits in need of WG attention.

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Tue, Nov 11, 2003 at 06:42:32PM +0100, Jon Bright wrote:
> Nicolas Williams wrote:
> >
> >In the case of "password" and "keyboard-interactive" userauth it's clear
> >that the server processes the password so no stringprep profile is
> >needed for the password in "password" userauth or for replies to
> >"keyboard-interactive" userauth prompts.
> 
> Does what you're saying here imply that the client should really be
> required to send a character set string together with the password in
> those situations (such that the server can then make the appropriate
> translations), or have I misunderstood?

I'm saying that the client send UTF-8 encoded strings to the server for
these two cases ("password" and "keyboard-interactive" userauth
responses) without applying _any_ string preparation to whatever the UI
interfaces produced as responses typed in by the user.

E.g., if the UI produces decomposed character sequences for, say, Latin
vowels with accents, then that is what the client sends, and if
sometimes the UI produces decomposed sequences and sometimes composed
characters, then that is what the client sends, and if the UI produces
something other than Unicode, then the client will convert to Unicode
before sending and will send whatever its converter produces, and if the
_server_ needs a particular string preparation for passwords, or if it
needs to process only passwords in 8859-1, then the _server_ applies
whatever stringprep profiles/charset conversions/whatever that it needs,
and then processes the password (e.g., hash it then compare it to some
hash).  The client cannot know what preparation the server needs for
passwords sent to the server.

But if the client were doing MD5-Digest authentication (which SSHv2 does
not provide for), then the client would have to know what preparations
to apply to passwords prior to using them with MD5-Digest.

Cheers,

Nico
--