Re: SSHv2 GSS spec issue wrt gss error tokens

["Nicolas Williams [RU-CENTRAL]" <Nicolas.Williams%sun.com@localhost>]

On Sun, Nov 10, 2002 at 08:41:12AM -0500, Jeffrey Hutzelman wrote:
> On Tue, 5 Nov 2002, Nicolas Williams wrote:
> 
> > 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
> 
> So far, so good.  I'll have to think about the semantics of that; we
> would want to make sure that once the server has gotten an error, the key
> exchange cannot succeed.

IIRC GSS-API basically guarantees that if the acceptor sends an error
token to the initiator then the initiator's gss_init_sec_context() will
also return an error.  A misbehaved initiator may insist on sending
additional tokens, but wouldn't fool the acceptor, who should proceed to
terminate the key exchange immediately upon GSS_Accept_sec_context()
returning an error, thus leading to failure of the connection,
regardless of any further actions on the part of the client.

>  and it MUST continue to the next key exchange algorithm.
> 
> There is no "next key exchange algorithm".  If key exchange fails, the
> connection is aborted.  There is no second chance.

Ah, yes, sorry.  This does apply to the GSS userauth part of the draft
however.

> > 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.
> 
> I'm not sure which of the three approaches is best.  But I do agree the
> problem should be solved...

Technically speaking no major/minor codes should ever be sent - the
fact that a token is sent and the subsequent result codes of processing
said token is all that is required for both sides to know what comes
next. I.e., if GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED
the acceptor doesn't have to tell the initiator, just sending the output
token (and there must be one, IIRC) should suffice.

If, otoh, GSS-API allows a mechanism's initiators and acceptors to get
out of sync, then exchanging GSS_S_CONTINUE_NEEDED/COMPLETE/FAILURE
clearly becomes necessary.  But it is clear to me that this is not the
case, otherwise GSS-API would explicitly require that such status codes
be sent along with GSS tokens or in their stead when none are produced.

But sending GSS_S_CONTINUE_NEEDED/COMPLETE/FAILURE does not hurt and I
see no reason to break backwards compatibility by revising the draft in
such a way as to exchange only tokens, not tokens and status codes,
particularly given that at least one implementation of this draft, to my
knowledge, has been widely deployed.

If the existing messages are not replaced and backwards compatibility is
preserved, then the minor status code field should be deprecated and the
major status code field should be constrained to carry only these three
status codes: GSS_S_CONTINUE_NEEDED, GSS_S_COMPLETE and GSS_S_FAILURE
(for backwards compatibility, but otherwise the major status code field
should be ignored by clients); and the SSH_MSG_KEXGSS_ERROR message
should be deprecated.  Similarly for GSS userauth.

Cheers,

Nico
--