Re: SSHv2 GSS spec issue wrt gss error tokens

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

On Mon, Nov 18, 2002 at 01:36:33PM -0500, Jeffrey Hutzelman wrote:
> On Mon, 18 Nov 2002, Nicolas Williams wrote:
[...]
> 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.

Ah.  Good.  Then there is no disagreement.  See below.

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

My reading of the GSS-API RFCs is that both sides of a context setup
token exchange should be "synchronized," as it were, in that neither
side should produce an output token-less status when the other side
still expects a token (i.e., had GSS_S_CONTINUE_NEEDED).  The specs do
allow for one side to complete and then receive an unexpected error
token from the other side that was not expected (thus the spec provides
GSS_Process_context_token()).

Nothing else makes sense.

It would not be good for both sides to both produce GSS_S_CONTINUE_NEEDED
but both also produce no output tokens, for example.  I don't think that
the protocol using GSS-API ought to send messages saying "[still] waiting
for your token" unless GSS-API explicitly allowed for such deadlocks
which could then only be detected and broken with "waiting for your
token" messages defined by the application using GSS-API.

So I think that we should never see a situation, no matter what the
mechanism, where GSS_Init_sec_context() returns GSS_S_CONTINUE_NEEDED
and GSS_Accept_sec_context() returns a failure and no output error
token, as this should generally lead to the initiator "hanging."
Consider the gss-sample that comes with MIT krb5.  (Gotta go check the
SPKM/LIPKEY mech RFCs...).

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

I do agree that SSH_MSG_KEXGSS_ERROR should be optional, if it even
exist.  The complete/continue_needed messages must be required though.

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

I agree. E.g., see above - I'm not sure I can "prove" my contention that
GSS mechs must be "synchronized" internally, not anymore than I could
"prove" that GSS error tokens exist...  If those RFCs are ever updated
there's several items that need clarification - here we have two.

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

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

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

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

Cool.  Problem solved.


> -- Jeff
> 


Thanks,

Nico
--