Re: SSHv2 GSS spec issue wrt gss error tokens

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

> I don't think not sending a GSS error token should be optional, under
> any circumstance, unless the alternative is to close the connection
> without further ado.

Effectively, that is the alternative.  If there is an error, the server
sends up to three messages:

- optional SSH_MSG_KEXGSS_CONTINUE with the error token
- optional SSH_MSG_KEXGSS_ERROR with error status and message
- recommended SSH_MSG_DISCONNECT with SSH_DISCONNECT_KEY_EXCHANGE_FAILED.
- close the connection


For user auth the exchange is slightly different:
- optional SSH_MSG_USERAUTH_GSSAPI_TOKEN with the error token
- optional SSH_MSG_USERAUTH_GSSAPI_ERROR with error status and message
- required SSH_MSG_USERAUTH_FAILURE

Once the client receives SSH_MSG_USERAUTH_FAILURE, it aborts the GSSAPI
exchange and may either close the connection or try again.

> Why couldn't this be accomplished with debug messages on the server
> side? Or with the server sending debug messages to the client? (there's
> no debug messages during key exchange, are there?)

I don't see anything specific that prohibits debug messages during key
exchange.  However, the use of a separate "error" message makes it clear
that we are describing the reason for an error, which could have an effect
on whether the client displays the result to the user (for example, the
client may choose to try multiple user auth methods, and only display the
error information if all fail).

> Regardless, the draft should be clear that the minor status code is
> implementation specific and that the client should not attempt to
> interpret it (the message in question has a field for a human readable
> error message string anyways).

Yes, I agree we should add some clarifying text.

-- Jeff