Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
RFC 4256

Note: This ballot was opened for revision 07 and is now closed.

(Steven Bellovin) Discuss

Discuss (2003-10-14 for -** No value found for 'p.get_dochistory.rev' **)
This sentence:

   The actual names of the submethods is something which the user and
   the server needs to agree upon.

is unacceptable, since there can't be any standards-based interoperability of submethods.  These need to be specified by RFC -- standards-track? -- and listed in an IANA registry.

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

(Ned Freed) (was No Objection) Discuss

Comment (2003-10-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Building on Ted's discuss comments, 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,
and if not, why not?

(Russ Housley) Yes

(Harald Alvestrand) No Objection

(Randy Bush) No Objection

(Margaret Cullen) No Objection

Comment (2003-10-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Deleted my comment, as it was fully resolved in discussion with Russ.

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

Comment (2003-10-15)
No email
send info
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.

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

Comment (2005-03-22)
No email
send info
Ned's old discuss issue appears to be addressed with the reference to SASLPREP.

(Thomas Narten) No Objection

(Jon Peterson) No Objection

Comment (2003-10-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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?

Nit, top of page 4 (section 3.1): "It is a a comma-separated list..."

Nit, second paragraph of page 4 (section 3.1): "which the user and the server needs", should be "need"

(Bert Wijnen) No Objection

Comment (2003-10-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
NITS:
- missing IPR section
- RFC2279 (norm ref) is being updated, 2279bis is in RFC-Editor queue
  probably want to refrence the new version

(Alex Zinin) No Objection