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

[Frank Cusack <fcusack%fcusack.com@localhost>]

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 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.

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