Re: SSHv2 GSS spec issue wrt gss error tokens

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

[BTW, I will not be attending this week's IETF.]

Jeff,

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

This issue does affect the user experience.  Take OpenSSH w/ Simon
Wilkinson's patches + krb5, for example, and slightly misconfigure
Kerberos on the server side, so that it cannot accept GSS/Kerberos key
exchange, then run the client (with valid Kerberos credentials
available) and see what happens: the one and only message the client
will have for the user is "Connection closed."

(One need not even have to misconfigure Kerberos - if the server is
multi-homed, with multiple canonical hostnames [one for each set of
interfaces] then gsskeyex will work only when user against the
interfaces whose canonical hostname matches the host's "nodename".  This
is because the existing open source implementations of GSS/Kerberos do
not support the better GSS_C_NO_CREDENTIAL semantics in
GSS_Accept_sec_context().  This scenario happens every day in at least
one environment that I know of, so it is not far-fetched; having useful
error messages for this and other scenarios would be great and sending
the acceptor's error token is the correct way to achieve that.)

At my previous job I wrote patches to implement SSH_MSG_KEXGSS_ERROR
with OpenSSH and Simon's patches.  This sure helped the situation, but,
as you know, the minor status codes are specific to the side where they
are produced, and may not be appropriate for the other side ("wrong
acceptor cred" on the acceptor side may be "wrong acceptor name" on the
client side; BTW, RFC1964 explicitly does not constrain implementations
to the list of minor status codes listed therein, nor is MIT's
implementation so constrained).  Sending the GSS error token truly fixes
the problem and does so in a way that is in keeping with the spirit of
RFC2743 and the letter of RFC2744.

The draft modifications that I propose would fix this problem in a
backwards compatible way (except where clients have broken GSS-API
implementations which cannot properly deal with GSS error tokens, of
which I know not one).  Alternatively the draft could be modified in a
non-backwards compatible manner, but I believe it's too for that.

More comments below.

On Mon, Nov 18, 2002 at 11:07:34AM -0500, Jeffrey Hutzelman wrote:
> On Mon, 11 Nov 2002, Nicolas Williams [RU-CENTRAL] wrote:
> 
> > Ugh, there are no major and minor status field in any messages other the
> > ones I think should be deprecated, so please ignore that part of the
> > below.
> >
> > So, to rework this:
> >
> >  - The SSH_MSG_KEXGSS_ERROR message should be deprecated
> 
> No.  I think you misunderstand the purpose of this message, and the reason
> it was added to the document.  The reason for sending this message is not
> to signal to the client that there was an error, or to provide the client
> with status codes that it can use to decide how to proceed -- as you note,
> the status code values are implementation-dependent and not standardized.
> Rather, it is there to allow the server to provide status codes and/or a
> textual error message to the user which may be useful in determining why
> key exchange failed and correcting the problem.  It was added specifically
> because we have discovered in the past that not having this information
> significantly impedes debugging when something breaks.
> 
> If the document is unclear on this issue, we could add some clarifying
> text.

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.

Having implemented SSH_MSG_KEXGSS_ERROR before (see above) I know I too
missed the significance of GSS error tokens, even their existence, for
some time.  RFC2743 is not explicit about GSS error tokens at all, and
RFC2743 being more general than RFC2744 (the C-bindings of RFC2743) one
would not expect RFC2744 to be explicit about them either (but it is).
Thus it would seem that it is not uncommon to find this misunderstanding
of the GSS-API - and it has occurred in other protocols that ustilize
the GSS-API as well.

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.

That said, it is not absolutely necessary that SSH_MSG_KEXGSS_ERROR be
deprecated and I am not wedded to its deprecation as a practical matter
(i.e., the message is optional already), only as a matter of principle
(why send the client infomartion it may not be able to decode).

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

This fix is interoperable because as soon as the client processes any
GSS error token sent by the server the client will fail gsskey ex just
as the server knows to fail it as well - SSH_MSG_KEXGSS_CONTINUE may
seem inappropriate for this purpose, but only because of its name; given
the need for a backwards compatible solution this additional use of
SSH_MSG_KEXGSS_CONTINUE is just fine.

> >  - SSH_MSG_KEXGSS_COMPLETE should continue to be used as specified in
> >    the draft
> >
> >  - similarly for the SSH_MSG_USERAUTH_GSSAPI_* messages (why are they
> >    not named in a manner consistent with the SSH_MSG_KEXGSS_* messages?)
> 
> They are named in a manner consistant with the names used in the core SSH
> drafts.  I believe this is appropriate and should not be changed.

How do you propose that GSS error tokens be sent back?  Or do you
propose that they not be sent back at all?

> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA


Cheers,

Nico
--