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+%cmu.edu@localhost> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA