Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes

From: "Wachdorf, Daniel R" <[email-masked]>
Date: Fri, 30 Jan 2004 14:52:12 -0700

No, there is another place in the code where GSS_C_INTEG_FLAG is checked.
It then either verifies the MIC or processes an EXCHANGE_COMPLETE message.

-dan

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Friday, January 30, 2004 2:44 PM
To: Wachdorf, Daniel R; 'Darren Tucker'; [email-masked]; [email-masked];
[email-masked]
Cc: OpenSSH Devel List; [email-masked]
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes

On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R" 
<[email-masked]> 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) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Ben Lindstrom <[email-masked]>
Date: Fri, 30 Jan 2004 16:46:41 -0600 (CST)

I need someone to look at this and get back to us ASAP in regards to if
this will break GSSAPI-WITH-MIC.

If this does break something.  GET US A PATCH NOW or live with broke
GSSAPI-WITH-MIC support for 6 months.

If it is just a "clean up" thing that can be handled after 3.9 release.
Fine, but I don't want to listen to 6 months of whining if it is. <weak
smile>

- Ben

On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:

> _______________________________________________
> openssh-unix-dev mailing list
> [email-masked]
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>

---

From: Sam Hartman <[email-masked]>
Date: Fri, 30 Jan 2004 17:54:27 -0500

>>>>> "Ben" == Ben Lindstrom <[email-masked]> writes:

    Ben> I need someone to look at this and get back to us ASAP in
    Ben> regards to if this will break GSSAPI-WITH-MIC.

It may make some conforming clients break but does not create a
security problem.

Some client implementers may choose to introduce an extra round trip
(which is what setting the mutual required flag does) in order to
interoperate with OpenSsh if the code is released in the current
state.

Really, that's probably OK if it happens.

I'd class this as a minor conformance issue, but not a huge deal.