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 PROTECTED] Sent: Friday, January 30, 2004 4:11 PM To: Wachdorf, Daniel R Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 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 domutual 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.
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 PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
