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

From: "Wachdorf, Daniel R" <[email-masked]>
Date: Fri, 30 Jan 2004 09:41:26 -0700

Darren,

I have been doing some testing and I noticed a problem with the server
implementation of GSSAPI authentication within the open ssh snapshot
(openssh-SNAP-20040124.tar.gz).  

The draft (draft-ietf-secsh-gsskeyex-07) states:

   Since the user authentication process by its nature authenticates
   only the client, the setting of the mutual_req_flag is not needed for
   this process.  This flag SHOULD be set to "false".

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. 

-dan

-----Original Message-----
From: Darren Tucker [mailto:[email-masked]] 
Sent: Wednesday, January 21, 2004 6:46 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: OpenSSH Devel List
Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes

(I hope this message is appropriate for these lists.  If not, please 
tell me and I won't do it again.)

Hi All.
	There will be a new release of OpenSSH in a couple of weeks.  This 
release contains Kerberos and GSSAPI related changes that we would like 
to get some feedback about (and hopefully address any issues with) 
before the release.

	I encourage anyone with an interest in Kerberos/GSSAPI support in 
OpenSSH to try a snapshot [1] and send feedback.

Changes in OpenBSD's OpenSSH and -Portable:
    - [email-masked] 2003/11/17 11:06:07
      replace "gssapi" with "gssapi-with-mic"; from Simon Wilkinson;
      test + ok jakob.
    - [email-masked] 2003/12/23 16:12:10
      implement KerberosGetAFSToken server option. ok markus@, beck@
    - [email-masked] 2003/11/02 11:01:03
      remove support for SSH_BUG_GSSAPI_BER; simon at sxw.org.uk

Changes in -Portable only
  - (dtucker) Only enable KerberosGetAFSToken if Heimdal's libkafs
    is found.  with jakob@	
  - (dtucker) [configure.ac] Use krb5-config where available for
    Kerberos/GSSAPI detection, libs and includes.  ok djm@

Additionally, as a side effect of the last change, the test for libkafs 
is now independant of the Heimdal test, so should a version that works 
with MIT Kerberos be available it will be used.

All but the last are in the 20040122 snapshot, and the last will be in 
20040123 and up.

Please follow-up to the OpenSSH devel list (cc: the Kerberos lists if 
you consider it appropriate).

[1] ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ or 
one of the mirrors listed at http://openssh.com/portable.html#mirrors

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

_______________________________________________
krbdev mailing list             [email-masked]
https://mailman.mit.edu/mailman/listinfo/krbdev

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 30 Jan 2004 16:43:51 -0500

On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R" 
<[email-masked]> wrote:

> 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):
>
>             (*flags & GSS_C_INTEG_FLAG))) && (ctx->major ==
> GSS_S_COMPLETE)) {

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: Nicolas Williams <[email-masked]>
Date: Fri, 30 Jan 2004 16:48:25 -0600

> text indicating the server MUST NOT do this?

For completeness' sake, yes.  The client (SHOULD NOT | MAY) set
GSS_C_MUTUAL for gssapi-with-mic, but the server MUST ignore the state
of the GSS_C_MUTUAL flag for gssapi-with-mic.

> GSS_C_INTEG_FLAG must be tested.

Right.  Further, the text should say that the server MAY always reject
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE since there's no generic
interface for determining whether a context doesn't have the GSS_C_INTEG
flag set because the client left it off or because the mechanism doesn't
support GSS_C_INTEG.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Sat, 31 Jan 2004 12:12:53 -0500

I'd prefer client MAY mutual auth rather than client SHOULD NOT mutual
auth.

If the server does not implement gss-keyex then a sufficiently clever
client can get some of the benefits of gss-keyex in some situations by
requesting mutual.