Re: SSHv2 GSS spec issue wrt gss error tokens

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

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.

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

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