Re: Russ Housley: IESG comments on draft-ietf-secsh-auth-kbdinteract-05.txt

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

Frank Cusack <fcusack%fcusack.com@localhost> writes:

> > There are also a lot of worms under the carpet of "if the client reads the
> > responses in some other encoding...it MUST convert the responses".
> > It is particularly problematic when you have the possibility of authentication
> > mechanisms that are not exact match, as the temptation is to increase
> > the set of matches rather than strongly define the conversion.  There
> > are clear security concerns there.
> 
> The text is simply lifted from the userauth draft (-18, sec 3.4).  I
> don't know enough about this stuff to comment further or to come up
> with a reasonable description.  help!

I think it makes sense to do whatever the userauth spec does.

The use of utf-8 in the userauth spec (for usernames and passwords)
was discussed some moths ago. There seems to be two alternatives:

1. Say that all utf-8 data should be normalized on the wire. The
   details would be, or look very much like, a stringprep profile.

2. Say that it's always the receiver's responsibility to perform any
   normalization that is appropriate. At the minumum, the receiver
   *must* respect canonical unicode equivalence as defined in the
   unicode specification.

   My current thinking is that the normalization needs are genuinely
   system dependent. If the system allows unicode/utf-8 usernames and
   passwords in /etc/passwd, and the system convention is to use utf-8
   normalized in some particular way, then the receiving ssh server
   needs to normalize the data according to the same conventions.

   And if the receiver just converts the input to its favourite 8-bit
   character set, then correct conversion will often imply
   normalization. E.g. all of "\u00C5", "\u212B" and "\u0041\u030A" would
   map to "Å" (0xC5) in latin-1. 

Last time, it seemed that (2) was what the people in the wg wanted.
Most other new protocols that use utf-8 on the wire seems to choose
(1).

Does anybody here have experience with systems that use usernames and
passwords in unicode or utf-8? What normalization do such systems use
and expect?

Regards,
/Niels