Skip to main content

Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
draft-ietf-secsh-auth-kbdinteract-07

Discuss


Yes

(Russ Housley)

No Objection

(Alex Zinin)
(Bill Fenner)
(Harald Alvestrand)
(Randy Bush)
(Sam Hartman)
(Thomas Narten)

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

Ned Freed Former IESG member
(was No Objection) Discuss
Discuss (2003-10-16) Unknown
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?
Steven Bellovin Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2003-10-14) Unknown
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.
Russ Housley Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection (2003-10-16) Unknown
NITS:
- missing IPR section
- RFC2279 (norm ref) is being updated, 2279bis is in RFC-Editor queue
  probably want to refrence the new version
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection (2003-10-16) Unknown
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"
Margaret Cullen Former IESG member
No Objection
No Objection (2003-10-16) Unknown
Deleted my comment, as it was fully resolved in discussion with Russ.
Randy Bush Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection (2005-03-22) Unknown
Ned's old discuss issue appears to be addressed with the reference to SASLPREP.
Ted Hardie Former IESG member
(was Discuss) No Objection
No Objection (2003-10-15) Unknown
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.
Thomas Narten Former IESG member
No Objection
No Objection () Unknown