openssh unix dev - Jan 2004 - 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:
    - markus at cvs.openbsd.org 2003/11/17 11:06:07
      replace "gssapi" with "gssapi-with-mic"; from Simon
Wilkinson;
      test + ok jakob.
    - jakob at cvs.openbsd.org 2003/12/23 16:12:10
      implement KerberosGetAFSToken server option. ok markus@, beck@
    - markus at cvs.openbsd.org 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.

> Changes in -Portable only
>   - (dtucker) Only enable KerberosGetAFSToken if Heimdal's libkafs
>     is found.  with jakob@	
I see a potential for circular depend confusion: I need OpenSSL
installed to get some libraries that Heimdal needs and I need Heimdal
installed to get some libraries that OpenSSL needs? Has anyone tested
this on a clean system?

Harald.

Paliminary results of testing with MIT krb5-1.3.2-beta2, OpenSSL-0.9.7c
on sun4x_57 with gcc. 

Problem 1:

We are using using Simon's current mods with the "gssapi" method. 
The new code implements the "gssapi-with-mic". I don't see a
transition
stratagy to get from using "gssapi" to get to using
"gssapi-with-mic",
other then to update all clients and servers at the same time. 
(The SecurtCRT for Windows, does appear to work with either.)

I know we want to get to using only gssapi-with-mic, but need
some time to convert. I would like to see the server offer both
and the client work with both "gssapi-with-mic" and "gssapi"
either
 by #ifdef, or a sshd_config flag, or testing the peer's version string.  

I am willing to write this mod if needed. 


Problem 2:

Since kafs.h is not defined in MIT Kerberos, I change the #ifdef
to match the #ifdef used with the code that needed kafs.h.

--- ,session.c  Tue Jan 20 18:00:46 2004
+++ session.c   Thu Jan 22 08:40:34 2004
@@ -58,7 +58,7 @@
 #include "session.h"
 #include "monitor_wrap.h"
 
-#ifdef KRB5
+#if defined(HEIMDAL) && defined(AFS)
 #include <kafs.h>
 #endif

We have AFS, and call another routine to get the PAG and token.
It does not rely on the AFS libraries, but issues a syscall for
the PAG and fork/exec aklog to get the token. I will be looking 
at how to get this local mod out as well, and use kafs.h and the 
calls you provide.


-- 

 Douglas E. Engert  <DEEngert at anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

> There is no transition strategy in the OpenSSH code, nor do I think
 > there should be one.

Why not?

On Thu Jan 22 16:03:15 MST 2004, Simon Wilkinson wrote:
> On Thu, 22 Jan 2004, Douglas E. Engert wrote:
> 
>> We are using using Simon's current mods with the "gssapi"
method.
>> The new code implements the "gssapi-with-mic". I don't
see a transition
>> stratagy to get from using "gssapi" to get to using
"gssapi-with-mic",
>> other then to update all clients and servers at the same time. 
>> (The SecurtCRT for Windows, does appear to work with either.)
> 
> There is no transition strategy in the OpenSSH code, nor do I think there 
> should be one. 
> 
> I will probably provide _for this release only_ patches which allow sites 
> to enable 'gssapi' authentication for backwards compatibility.
Those sites
> will generally have been using my patches anyway, so I don't see any 
> problem with this existing outside the main code base.
> 
> Cheers,
> 
> Simon.

At 9:07 PM +0100 1/22/04, Harald Barth wrote:
>  > I think that OpenSSL != OpenSSH.
>
>Correct. I got the install order wrong. The right order is OpenSSL,
>Heimdal, OpenSSH.
>
>Harald.
OK, so how do you install OpenSSL with RFC 2712 support enabled?
-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu

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:dtucker at zip.com.au] 
Sent: Wednesday, January 21, 2004 6:46 PM
To: kerberos at mit.edu; krbdev at mit.edu; heimdal-discuss at sics.se
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:
    - markus at cvs.openbsd.org 2003/11/17 11:06:07
      replace "gssapi" with "gssapi-with-mic"; from Simon
Wilkinson;
      test + ok jakob.
    - jakob at cvs.openbsd.org 2003/12/23 16:12:10
      implement KerberosGetAFSToken server option. ok markus@, beck@
    - markus at cvs.openbsd.org 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             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

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:jhutz at cmu.edu] 
Sent: Friday, January 30, 2004 2:44 PM
To: Wachdorf, Daniel R; 'Darren Tucker'; kerberos at mit.edu; krbdev at
mit.edu;
heimdal-discuss at sics.se
Cc: OpenSSH Devel List; ietf-ssh at NetBSD.org
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes

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

Ben,

This will break GSSAPI_WITH_MIC if clients don't do GSS_C_MUTUAL as outlined
by the standard.  Ie - follow the standard and it wont work.  So I guess
that means it's broke.

I can get a patch to you, what version of the source should I patch, a
nightly snapshot?

-dan

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] 
Sent: Friday, January 30, 2004 3:47 PM
To: Wachdorf, Daniel R
Cc: 'Jeffrey Hutzelman'; kerberos at mit.edu; krbdev at mit.edu;
heimdal-discuss at sics.se; ietf-ssh at NetBSD.org; OpenSSH Devel List
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes


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:
> 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:jhutz at cmu.edu]
> Sent: Friday, January 30, 2004 2:44 PM
> To: Wachdorf, Daniel R; 'Darren Tucker'; kerberos at mit.edu;
krbdev at mit.edu;
> heimdal-discuss at sics.se
> Cc: OpenSSH Devel List; ietf-ssh at NetBSD.org
> Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes
>
> 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
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>

Well,

It could be a problem. If someone has implemented a client and doesn't do
mutual auth (as the standard says they should), they could be broken.  

The fix is easy.  Just remove:

(*flags & GSS_C_MUTUAL_FLAG) &&
            (*flags & GSS_C_INTEG_FLAG))

from the if statement.  

I have already tested this out, it works fine.  I will make a diff if
someone tells me what to base if off of.

-----Original Message-----
From: Sam Hartman [mailto:hartmans at mit.edu] 
Sent: Friday, January 30, 2004 3:54 PM
To: Ben Lindstrom
Cc: Wachdorf, Daniel R; 'Jeffrey Hutzelman'; krbdev at mit.edu;
ietf-ssh at NetBSD.org; kerberos at mit.edu; heimdal-discuss at sics.se; OpenSSH
Devel List
Subject: Re: Pending OpenSSH release: contains Kerberos/GSSAPI changes
>>>>> "Ben" == Ben Lindstrom <mouring at
etoh.eviladmin.org> 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.

On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:
> Well,
>
> It could be a problem. If someone has implemented a client and doesn't
do
								^^^^^^^^^^
> mutual auth (as the standard says they should), they could be broken.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This right here is the key to me.  If someone is not following the RFC.
Then I say let them complaint to their vendor.

Again I ask.. As the code stands are *WE* in RFC compliance?  If not we
need it fixed.

As for what to base it off of.  Pick a recent snapshot.  Not as if the
GSSAPI-WITH-MIC code has drasticly changed in the last few days.

- Ben

No.

1 - RFC states GSS_C_MUTUAL_FLAG SHOULD not be used.  The current open ssh
server requires that it be used.

2 - RFC also allow for gss mechanisms that don't have GSSAPI integrity.
Servers can then choose to disallow it. As far as I can tell from the code,
any client which doesn't (or cant) have the GSS_C_INTEG_FLAG set cannot
connect.  I can't test this because Kerberos-gssapi uses integrity.

-dan

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] 
Sent: Friday, January 30, 2004 4:11 PM
To: Wachdorf, Daniel R
Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; krbdev at mit.edu;
ietf-ssh at NetBSD.org;
kerberos at mit.edu; heimdal-discuss at sics.se; OpenSSH Devel List
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes



On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:
> Well,
>
> It could be a problem. If someone has implemented a client and doesn't
do
								^^^^^^^^^^
> mutual auth (as the standard says they should), they could be broken.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This right here is the key to me.  If someone is not following the RFC.
Then I say let them complaint to their vendor.

Again I ask.. As the code stands are *WE* in RFC compliance?  If not we
need it fixed.

As for what to base it off of.  Pick a recent snapshot.  Not as if the
GSSAPI-WITH-MIC code has drasticly changed in the last few days.

- Ben

Here is a patch.  it was based of the 2004-12-24 snapshot (I had trouble
getting todays to compile).

*** ../openssh/gss-serv.c       Mon Nov 17 04:18:22 2003
--- gss-serv.c  Fri Jan 30 16:35:24 2004
***************
*** 117,124 ****
         * 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");
        }
--- 117,123 ----
         * we flag the user as also having been authenticated
         */

!       if(ctx->major == GSS_S_COMPLETE) {
                if (ssh_gssapi_getclient(ctx, &gssapi_client))
                        fatal("Couldn't convert client name");
        }

-dan

-----Original Message-----
From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] 
Sent: Friday, January 30, 2004 4:11 PM
To: Wachdorf, Daniel R
Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; krbdev at mit.edu;
ietf-ssh at NetBSD.org;
kerberos at mit.edu; heimdal-discuss at sics.se; OpenSSH Devel List
Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes



On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote:
> Well,
>
> It could be a problem. If someone has implemented a client and doesn't
do
								^^^^^^^^^^
> mutual auth (as the standard says they should), they could be broken.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This right here is the key to me.  If someone is not following the RFC.
Then I say let them complaint to their vendor.

Again I ask.. As the code stands are *WE* in RFC compliance?  If not we
need it fixed.

As for what to base it off of.  Pick a recent snapshot.  Not as if the
GSSAPI-WITH-MIC code has drasticly changed in the last few days.

- Ben


-------------- next part --------------
A non-text attachment was scrubbed...
Name: gss-patch-snap-20040124.diff
Type: application/octet-stream
Size: 647 bytes
Desc: not available
Url :
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040130/222717f7/attachment.obj