Here comes my comments on the draft.
> 3.1 Initial Exchange
...
> The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
> if the failure is based on the username or service; instead it SHOULD
> send a SSH_MSG_USERAUTH_INFO_REQUEST message requesting a password,
> and then send the failure message (after a suitable delay, as
> described below). This is to help limit certain types of attacks.
But that can be revealing as well. I suggest the following wording
instead:
The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
if the failure is based on the username or service; instead it SHOULD
send a SSH_MSG_USERAUTH_INFO_REQUEST message which looks just like the
one which would have been sent in cases where authentication should
proceed, and then send the failure message (after a suitable delay, as
described below). The goal is to make it impossible to find valid
usernames by just comparing the results when authenticating as
different users.
> 3.2 Information Requests
...
> byte SSH_MSG_USERAUTH_INFO_REQUEST
> string name (ISO-10646 UTF-8)
> string instruction (ISO-10646 UTF-8)
> int num-prompts
> string prompt[1] (ISO-10646 UTF-8)
> boolean echo[1]
> ...
> string prompt[num-prompts] (ISO-10646 UTF-8)
> boolean echo[num-prompts]
> string language tag (as defined in [RFC-1766])
I think it would be sligthly cleaner to move the language-tag to before
the prompts (possible it should be placed before name). IMHO it is cleaner
to have the "static" portions of a message first and the dynamic last.
> 3.3 User Interface
...
> A CLI client SHOULD print the name and instruction (if supplied),
> adding newlines. Then for each prompt in turn, the client MUST
> display the prompt and read the user input.
>
> A GUI client SHOULD present a dialog window, using the name (if
> supplied) as the title of the window, the instruction (if supplied)
> as a text message inside the dialog, and the appropriate number of
> entry fields with the prompts as labels. A GUI client SHOULD NOT
> present each prompt in a separate window. A GUI client MUST properly
> handle an instruction with embedded newlines. A GUI client MUST also
> be able to display at least 30 characters for the name and prompts.
> If the server presents names/prompts longer than 30 characters, the
> client MAY truncate these fields to the length it can display. If
Nowhere does the draft explain the terms CLI and GUI. Also a lot of the
restrictions placed on GUI-clients should also be applied to CLI-clients.
I would propose the following wording:
A text-based client SHOULD print the name and instruction (if
supplied), adding newlines. Then for each prompt in turn, the
client MUST display the prompt and read the user input.
A graphical user interface (GUI) client SHOULD present a dialog
window, using the name (if non-empty) as the title of the window,
the instruction (if non-empty) as a text message inside the dialog,
and the appropriate number of entry fields with the prompts as
labels. A GUI client SHOULD NOT present each prompt in a separate
window.
All clients MUST properly handle an instruction with embedded
newlines. They MUST also be able to display at least 30 characters
for the name and prompts. If the server presents names/prompts
longer than 30 characters, the client MAY truncate these fields to
the length it can display. If the client does truncate any fields,
there SHOULD be an obvious indication that such truncation has
occured.
> 3.4 Information Responses
...
>
> After obtaining the requested information from the user, the client
> MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message.
>
> The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as
> follows:
>
> byte SSH_MSG_USERAUTH_INFO_RESPONSE
> int num-responses
> string response[1] (ISO-10646 UTF-8)
> ...
> string response[num-responses] (ISO-10646 UTF-8)
>
> 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, and the server MUST convert the responses to the
> encoding used on that system that is needed to verify them.
>
> In the case that the server sends a `0' num-prompts field in the
> request message, the client MUST send a response message with a `0'
> num-responses field.
>
> After receiving the response, the server MUST send either a
> SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another
> SSH_MSG_USERAUTH_INFO_REQUEST message.
>
> If the server fails to authenticate the user (through the underlying
> authentication mechanism(s)), it SHOULD NOT send another request
> message(s) in an attempt to obtain new authentication data, instead
> it SHOULD send a failure message. The only time the server should
> send multiple request messages is if additional authentication data
> is needed (i.e., because there are multiple underlying authentication
> mechanisms that must be used to authenticate the user).
>
> If the num-responses field does not match the num-prompts field in
> the request message, the server MUST send a failure message.
I think this last paragraph should move up a bit and be placed after the
"Note that the responses..." paragraph.
> 6. References
...
> [SSH-ARCH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Protocol
> Architecture", Internet Draft, draft-ietf-secsh-architecture-00.txt
>
> [SSH-CONNECT] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
> Connection Protocol", Internet Draft, draft-ietf-secsh-connect-02.txt
>
> [SSH-TRANS] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Transport
> Layer Protocol", Internet Draft, draft-ietf-secsh-transport-02.txt
>
> [SSH-USERAUTH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
> Authentication Protocol", Internet Draft, draft-ietf-secsh-userauth-
> 02.txt
Perhaps we should update these references to be aginst the current versions
of the drafts:-)
/MaF
