Re: SSHv2 GSS spec issue wrt gss error tokens

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

On Mon, 18 Nov 2002, Nicolas Williams wrote:

> How do you propose to fix the problem at hand, that gsskeyex does not
> provide a method to send GSS error tokens, and therefore has no
> interoperable mechanism for conveying acceptor-side errors to
> initiators?  (forgive me, GSS-API demands that we speak of initiators
> and acceptors for what every other API/standard refers to as clients and
> servers - I'll use the terms interchangeably as SSHv2 clients will only
> be GSS initiators and so on).

Sorry; I guess I was unclear.  I have no problem with recommending that
the SSH_MSG_KEXGSS_CONTINUE message be used to send error back error
tokens, provided that the party sending the error token (which, I believe,
could be the initiator or acceptor) remembers that it is in an error state
and does not then allow key exchange to succeed.

I only oppose dropping the SSH_MSG_KEXGSS_ERROR message, which I believe
provides useful debugging information that may not be available any other
way -- particularly if the mechanism in use does not generate interesting
error tokens.

All of the relevant messages should be optional or recommended, and we
should be consistent about it.  See the last paragraph of the security
considerations section, in which we recommend that it be possible to
configure servers _not_ to send the error message, in order to avoid
giving an attacker information that may help him to break in.


> I think this is somewhat disingenuous.  The draft does not provide for
> sending of GSS error tokens, thus leaving SSH_MSG_KEXGSS_ERROR as the
> only, but inadequate alternative.  This leads me to suspect that the
> draft's authors failed to understand that GSS_Accept_sec_context()
> can produce an output token and a final error at the same time, thus the
> desire for an explicit error message that conveys the major/minor status
> code produced by GSS_Accept_sec_context().  Had the authors understood
> GSS error tokens I doubt they would have bothered to define
> SSH_MSG_KEXGSS_ERROR.  In any case, the draft says nothing about the
> message being for debug purposes or about minor status codes possibly
> being implementation specific.

You're right; we did fail to understand that.  We understand it now, and
we can certainly add text to address the issue of error tokens, since it
seems the right thing to do is not entirely obvious.  This is not
surprising, since the GSSAPI specs are notoriously difficult to fully
understand.

> Having SSH_MSG_KEXGSS_ERROR as a debug message is fine, but it will
> still only help when the client and server are of similar origins
> (meaning that they share definitions for the minor status codes of their
> supported mechanisms).  This limited utility makes SSH_MSG_KEXGSS_ERROR
> less than useful, and, given that sending GSS error tokens interoperably
> provides the relevant information to the client anyways I see no reason
> to bother with SSH_MSG_KEXGSS_ERROR and its userauth friend.

I disagree.  The intent was never that the client would attempt to
interpret the status codes, but that it would display them to the user
(possibly only if an appropriate debugging option is enabled).  When a
user says "I tried to ssh into your machine and it didn't work", being
able to get them to report the status codes can be quite useful --
especially given that users are likely to report a code accurately when
they would attempt to interpret the meaning of a message.



> > >  - SSH_MSG_KEXGSS_CONTINUE should continue to be used as specified in
> > >    the draft
> > >
> > >  - SSH_MSG_KEXGSS_CONTINUE should also be used to send any GSS "error"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >    tokens
> ^^^^^^^^^^^^^
>
> Do you object to this?  This is the actual, backwards compatible draft
> change needed to have interoperable communications about GSS errors.

For clarity:  No, I do not object to this.

-- Jeff