SSHv2 GSS spec issue wrt gss error tokens

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

GSS_Accept_sec_context() can produce tokens when its major status code
is neither GSS_S_COMPLETE nor GSS_S_CONTINUE_NEEDED. RFC2743 doesn't
state this anywhere but by not prohibiting this it implies the
behaviour.

The Kerberos GSS mechanism (RFC1964) defines error tokens; it does not
state that gss_accept_sec_context() can produce these but strongly
implies it. RFC1964 also does not specify numeric forms of minor codes.

The MIT implementation of GSS-API and the Kerberos GSS mechanism *does*
produce error tokens in some circumstances.

The gsskeyex draft does not specify what to do with error tokens, though
it does provide an optional SSH_MSG_KEXGSS_ERROR message for transmitting
GSS error information to the client. The result of this and the fact
that RFC2743 does not specify major status codes for certain conditions
(leaving one to use GSS_S_FAILURE) is that there is no interoperable way
of communicating to the client certain GSS-API error conditions
occurring on the server side.

It turns out that sending the acceptor's major and minor status codes is
not an appropriate alternative to sending the actual error token to the
initiator. For one, RFC1964 does not define numeric forms of its minor
status codes (and MIT's implementations liberally uses codes not defined
in RFC1964 and not called KG_...). Second, in some cases the
major/minor codes produced by gss_accept_sec_context() may be different
from those produced by gss_init_sec_context() upon receipt of an error
token. GSS status codes, major and minor, are API-level concepts and
should really not be used on the wire - that's what the gss error tokens
are for, though, admittedly, if gss_accept_sec_context() returns an
error but produces no output token, then sending the major/minor codes
to the client is better than sending nothing at all.

I propose that the draft be modified to say that when GSS_Accept_sec_context()
returns an error but produces an output token, then the server MUST send
back a SSH_MSG_KEXGSS_CONTINUE message with the error token to the
client and it MUST continue to the next key exchange algorithm.

Alternatively we could add a new message for the server to indicate that
it had an error and in which to send the error token OR we could modify
the SSH_MSG_KEXGSS_ERROR message to include an optional error token.

RPCSEC_GSS (rfc2203) has a similar problem.

Cheers,

Nico
--