Pending OpenSSH release: contains Kerberos/GSSAPI changes

[Jeffrey Hutzelman]

On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R" 
<drwachd at sandia.gov> wrote:

> The client sets this to true, not really a problem.  Our modified f-secure
> client does the same thing.  However, if GSS_C_MUTUAL_FLAG is not set,
> then the open ssh server rejects the connection.  The following line of
> code (from gss-serv.c):
>
>         /* Now, if we're complete and we have the right flags, then
>          * we flag the user as also having been authenticated
>          */
>
>         if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) &&
>             (*flags & GSS_C_INTEG_FLAG))) && (ctx->major ==
> GSS_S_COMPLETE)) {
>                 if (ssh_gssapi_getclient(ctx, &gssapi_client))
>                         fatal("Couldn't convert client name");
>         }
>
>
> This requires the client to set GSS_C_MUTUAL, which conflicts with the
> draft.

Indeed, it does.  The server is not supposed to check the state of the 
mutual_flag of a context accepted for gssapi-with-mic user auth.  I know 
the draft is not entirely clear on this point; would it help if there were 
text indicating the server MUST NOT do this?


Also, I've not actually read this code, other than what's quoted above, but 
I hope that's not the only place that flags are checked.  I'm assuming the 
openssh code actually implements -07 and 'gssapi-with-mic'.  In the new 
method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or 
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether 
GSS_C_INTEG_FLAG is set.  The server is REQUIRED to fail the authentication 
if the client sends the wrong message; this means the value of 
GSS_C_INTEG_FLAG must be tested.


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