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

From: Frank Cusack <[email-masked]>
Date: Mon, 2 Feb 2004 02:10:36 -0800

On Fri, Oct 17, 2003 at 04:36:26PM -0400, Bill Sommerfeld wrote:
> FYI, comments from the IESG.  In summary, looks like an IANA issue, a
> few I18N issues, some matters of taste, plus a few nits.
> 
> We'll need to re-spin the document and resubmit it.

My responses are inline.

> ------- Forwarded Message
> 
> From [email-masked] Fri Oct 17 16:32:34 2003
> Date: Fri, 17 Oct 2003 16:31:21 -0400
> To: [email-masked]
> From: Russ Housley <[email-masked]>
> Subject: IESG comments on draft-ietf-secsh-auth-kbdinteract-05.txt
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> Content-Length: 3128
> 
> Bill:
> 
> A revised Internet-Draft is needed to resolve the comments.
> 
> Russ
> 
> = = = = = = =
> 
> DISCUSS
> 
> 1.  This sentence caused a lot of trouble:
> 
>    The actual names of the submethods is something which the user and
>    the server needs to agree upon.
> 
> These submethods need to be specified by RFC, probably a standards-track 
> RFC, and listed in an IANA registry, otherwise there can't be any 
> standards-based interoperability of submethods.

There isn't intended to be.  This is explicitly stated in the paragraph
just following the quoted text above:

   Server interpretation of the submethods field is implementation-
   dependent.

It continues:

   One possible implementation strategy of the submethods field on the
   server is that, unless the user may use multiple different
   submethods, the server ignores this field.

So by example the text makes it clear that a client must expect that
the server may ignore this field totally.  There is no standards-based
interoperability of submethods.

But if, say, the XYZ vendor client learns in the connect phase that it's
talking to an XYZ vendor server, it might optimistically set a submethod.

What if we defined a namespace for submethods?  VENDOR-submethod?  With
IETF-* reserved for standards based submethods and anything thing else
is wide open.  Or submethod@VENDOR.

I really want to keep this as minimal as possible.  The paragraph just
before the quoted text says

   The submethods field is included so the user can give a hint of which
   actual methods he wants to use.

What if I added:  The client must not expect the server to take any
particular action based on the submethod--it's just a one-way hint.

> 2.  Explain why the language tag in the SSH_MSG_USERAUTH_INFO_REQUEST is 
> not deprecated, especially when they are deprecated in 
> SSH_MSG_USERAUTH_REQUEST.

oops, it should be deprecated.

> 3.  Section 3.4 seems problematic.  It says:
> 
>    Note that the responses are encoded in ISO-10646 UTF-8.  It is up to
>    the server how it interprets the responses and validates them.
>    However, if the client reads the responses in some other encoding
>    (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8
>    before transmitting.
> 
> If I read the author's intentions correctly, they mean to say that a server
> might use an authentication method that was functionally similar to
> case-insensitive passwords, and would thus treat the strings
> like "aCEddd8" and "AceDdd8" (encoded in UTF-8) as equivalent.  I don't 
> think it
> should be "up to the server" though, I think the method (or submethod)
> has to determine this; otherwise the interaction seems pretty hard to
> debug.
> 
> 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!

> The reference to UTF-8 should probably be updated.

Easy enough.  Should it be referred to as STD-63 or RFC-3629?

> 4.  Building on the previous comment, when I see a document that talks about
> using UTF-8 and reading stuff from keyboards I immediately think "where's
> the stringprep profile?" I didn't see one specified here -- isn't one needed?
> If not, why not?

I'll have to do some research here, but help is appreciated.

> COMMENT
> 
> 5.  I find the whole User Interface section grating.  It has two or three 
> visual models in
> mind and ignores a plethora of other possibilities.  I'd personally rather 
> they ripped
> it out, but this is probably rank prejudice, so take it as such.

It describes the most common interfaces.  Other interfaces are free to
implement whatever they need.  The point is to describe how one *might*
display the various fields, and to make it clear that the client is *not*
to add additional text to the prompts.  It's important (IMHO) to have an
example otherwise implementations will be awkwardly different.

> 6.  2nd to last paragraph of 3.1: Under what circumstances is an 
> SSH_MSG_USERAUTH_SUCCESS sent in response to an SSH_MSG_USERAUTH_REQUEST? 
> Some guidelines are given for when the other two possibilities (including 
> FAILURE and INFO_REQUEST) are sent. I assume it's only when no 
> authentication is needed for this particular user - when just asserting the 
> username is sufficient authentication. Could the case in which this makes 
> sense be stated explicitly here?

Good point, I will clarify.

> 7.  Nit, top of page 4 (section 3.1): "It is a a comma-separated list..."
> 
> 8.  Nit, second paragraph of page 4 (section 3.1): "which the user and the 
> server needs", should be "need"
> 
> 9.  Missing IPR section
> 
> 10.  RFC2279 (norm ref) is being updated, 2279bis is in RFC-Editor 
> queue.  Probably want to reference the new version.

Last 4 are covered.  So I need some feedback on points 1 (submethods)
and 3 (UTF-8) to make headway.

thanks
/fc

---

From: [email-masked] (Niels Möller)
Date: 02 Feb 2004 14:59:25 +0100

> 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