OK; I _think_ we may actually have concensus this time. So, here's a
concrete proposal for what the changes to the spec should look like.
Hopefully this will be enough for people to comment on and implement
from, until I can post some real text and submit a draft...
* In section 3 of the -06 document, which describes "gssapi" userauth:
- Rename the mechanism from "gssapi" to "gssapi-with-mic"
- When calling GSS_Init_sec_context, the client MUST set integ_req_flag
- If integ_avail is false, send SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE
- If integ_avail is true, send SSH_MSG_USERAUTH_GSSAPI_MIC (see below).
- The server MUST reject the authentication if it gets the wrong message.
- The server MAY reject authentication anyway if integ_avail is false.
The SSH_MSG_USERAUTH_GSSAPI_MIC message looks like this:
byte SSH_MSG_USERAUTH_GSSAPI_MIC
string MIC
The MIC is the result of calling GSS_GetMIC on the following:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service
string "gssapi-with-mic"
The message number for SSH_MSG_USERAUTH_GSSAPI_MIC is 66.
I know this is a little different from what Joseph proposed -- what I
describe actually involves using a different message depending on
whether integrity is available, rather than sending the same message
with a possibly empty MIC string. I did this to try to make life easier
for people who are also implementing "gssapi" -- except for the method
name, the exchange for "gssapi" is exactly the same as for
"gssapi-with-mic" when integrity is not supported. That should make it
easier to implement both with common code, if desired, and it also
retains some semblance of documentation of the old method in the
document. If people would rather see
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE go away completely, we can use
the empty-MIC-string approach instead.
* Section 4, describing external-keyx, is replaced entirely. The new
mechanism is called "gssapi-keyex", and consists of a single message:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service
string "gssapi-keyex"
string MIC
The MIC is computed by calling GSS_GetMIC using the context from
_initial_ key exchange. The context from a rekey is never used; if the
initial key exchange was not GSSAPI-based, then this method cannot be
used. The MIC is computed over the following:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service
string "gssapi-keyex"
Reasonable?
-- Jeff