Re: New drafts

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

Chris Lonvick <clonvick%cisco.com@localhost> writes:

> Just to summarize the discussion, I am planning on the following:
> 
> =====
> For SSH_MSG_CHANNEL_OPEN_FAILURE we will have
> 
> 0x0000 0000 - 0xFDFF FFFF        IETF CONSENSUS
> 0xFE00 0000 - 0xFEFF FFFF        PRIVATE USE - channel-type specific
> 0xFF00 0000 - 0xFFFF FFFF        PRIVATE USE - (experimental stuff)
> 
> with accompanying notes about
> 
> - The range starting with 0xFE should be used when localized names are
> used for opening a channel (e.g. SSH_MSG_CHANNEL_OPEN message with a
> 'channel type' of "secure-net-hearts%example.com@localhost").  Interoperability is
> assumed by a "gentleman's agreement" that IF you accept the localized
> channel open type THEN you will understand the failure 'reason code'
> values associated with that localized name.  Also, the IANA assigned
> 'reason code' values are still valid even when opening a channel using a
> localized name.

I don't think "localized" is the right word for referring to names of
the "name@domain" type. What are they called where this naming scheme
is introduced? "locally defined"?

>    Note that the 'plaintext password' value 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.  However, if the client
>    reads the password in some other encoding (e.g., ISO 8859-1 - ISO
>    Latin1), it MUST convert the password to ISO-10646 UTF-8 before
>    transmitting, and the server MUST convert the password to the
>    encoding used on that system for passwords.

I strongly prefer that we don't change that. The problem is the server
side. If a some unix system uses non-ascii characters in passwords,
there really ought to be a configuration somewhere on the system that
says what character set that is. Without that, I don't think there's a
sane way to get passwords right when more than one character set is
used (consider a unix server with latin-1 passwords, and a windows-ce
client using utf8).

I have one suggestion that may or may not satisfy der Mouse:

  If a server really has no clue about what character set is used in
  its password database, it SHOULD default to iso-8859-1.

Motivation: If you really need to pass an arbitrary octet string as a
password, you can do that by encoding the octet string into utf8. I
choose iso-8859-1 primarily because transformation between
utf8/unicode and iso-8859-1 is particularly easy.

Consider (a slight variation of) the given example: The user's
password is the octet string 0x72 0xc3 0xeb. The user likes 8859-7,
and thinks about the password as r, capital gamma, lowercase lambda,
but the sysadmin and the ssh server have no clue about that.

Now, the user sits at an utf8-only system (say, the windows-ce
client), and wants to login. Typing r, capital gamma, lowercase lambda
won't work (and it wouldn't work if the protocol treated passwords as
opaque octet strings either). However, if the server interprets the
utf8 it receives as latin 1, the user can login if he types "rÃë".

I think that der Mouse's point is that *if* the user is sitting at an
iso-8859-7-only device, then this won't work (there's no way to input
"rÃë" to the client), while things would work if passwords were octet
strings in the protocol. I can think of some kludges, but I see no
really good way to avoid the problem.

Sure, this way of logging in is obscure and not particularly friendly,
but I don't think it is worse than the given example.

To really support arbitrary character sets in passwords, different for
each user, the ssh server somehow needs to figure out the user's
preferred locale before trying to verify the password (say, storing it
in /etc/passwd, or in $HOME/.locale, whatever). I'm sorry that doesn't
seem very practical, but I really don't see any sane way to support
network login, from devices using different character sets, without
doing this.

Conversion on the client side is easier, since all per-user's locale
information should be available in the environment.

(Another issue is that servers that use utf8 passwords natively *must*
normalize the passwords in one way or the other, since no
normalization is required on the wire. Same applies to usernames. But
I really *hope* that is obvious for everybody who actually implements
utf8 for usernames and/or passwords).

Best regards,
/Niels