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

From: "Wachdorf, Daniel R" <[email-masked]>
Date: Fri, 30 Jan 2004 16:25:34 -0700

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:[email-masked]] 
Sent: Friday, January 30, 2004 4:11 PM
To: Wachdorf, Daniel R
Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; [email-masked]; [email-masked];
[email-masked]; [email-masked]; 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 30 Jan 2004 21:57:42 -0500

On Friday, January 30, 2004 16:25:34 -0700 "Wachdorf, Daniel R" 
<[email-masked]> wrote:

> 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
>
> Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; OpenSSH
> Devel List

For some reason, I'm not seeing Ben's messages.  Perhaps the mail path from 
him to me is just really long.

In any case...

The spec says clients SHOULD set mutual_req to "false", which means not 
requesting mutual authentication.  I know of no mechanisms which will do 
mutual auth (and produce a context with mutual_flag set) if the client sets 
mutual_req to "false".

What this means is that a compliant client is _likely_ not to work with the 
openssh server as it stands.  It is possible to be compatible with openssh 
and still be compliant (SHOULD means approximately "do this unless you have 
a good reason not to"); however, not all compliant clients will be 
compatible with openssh.  Note that the openssh client is an example of a 
client that interoperates with the openssh server (AFAIK) and is compliant 
(at least, with respect to this issue).

The spec does not specifically prohibit openssh's current behaviour, but it 
is likely to cause interop problems.  IMHO, the fact that this is not 
specified more clearly is an oversight -- the spec does not provide enough 
information to write interoperable clients and servers.  Thank you both for 
finding this; I'll be addressing the issue in the next version.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 30 Jan 2004 22:08:42 -0500

(Just to pick nits...  Note that this is not yet an RFC.  Hopefully that 
will change sometime in the next few months, but at the moment it's still 
an internet-draft.)

> cannot connect.  I can't test this because Kerberos-gssapi uses integrity.

This is legitimate behaviour.  See the last paragraph of section 3.6, at 
the top of page 15:

   It is a site policy descision for the server whether or not to permit
   authentication using GSSAPI mechanisms and/or contexts which do not
   support per-message integrity protection.  The server MAY fail the
   otherwise valid gssapi-with-mic authentication if per-message
   integrity protection is not supported.

Note the use of the word "MAY", which means "do whatever you want".  We 
actually expect that most server operators will want to accept 
gssapi-with-mic only in cases where integrity is supported,  There was a 
fairly length discussion of this issue on the ietf-ssh list last October or 
so.