Re: SSHv2 GSS spec issue wrt gss error tokens

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

Ok, one more go around:

On Mon, Nov 18, 2002 at 04:01:49PM -0500, Jeffrey Hutzelman wrote:
> > 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

Why is this optional?  (To provide for error obfuscation?)  It should be
recommended, not merely optional.

BTW, GSS-API ought to provide a feature for error token obfuscation.
Better to let the mechanism determine what error information to send
than to let the GSS application get away with not sending error tokens.

In the meantime, I'd agree to making SSH_MSG_KEXGSS_CONTINUE w/ error
tokens optional, but recommended - SHOULD, in fact, and the error code
shrouding rationale should be described in the security considerations
section, say.

That brings up another question: do the various SSHv2 drafts
consistently provide for error code obfuscation where errors are sent on
the wire?  Should GSS-keyex be consistent with the other SSHv2 drafts on
this?

> - 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).

Ok.

> > 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.

Thanks.


> -- Jeff
> 

Thanks,

Nico