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

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

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.

					- Bill

------- Forwarded Message

>From sommerfeld-request%east.sun.com@localhost Fri Oct 17 16:32:34 2003
Date: Fri, 17 Oct 2003 16:31:21 -0400
To: sommerfeld%east.sun.com@localhost
From: Russ Housley <housley%vigilsec.com@localhost>
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.

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.

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 reference to UTF-8 should probably be updated.

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?

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.

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?

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.


------- End of Forwarded Message