IESG comments on draft-ietf-secsh-auth-kbdinteract-05.txt
Russ Housley <housley@vigilsec.com> Fri, 17 October 2003 20:31 UTC
Date: Fri, 17 Oct 2003 16:31:21 -0400
To: sommerfeld@east.sun.com
From: Russ Housley <housley@vigilsec.com>
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
X-Message-ID:
Message-ID: <20140418100914.2560.34356.ARCHIVE@ietfa.amsl.com>
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
- IESG comments on draft-ietf-secsh-auth-kbdinterac… Russ Housley