Love <lha%stacken.kth.se@localhost> writes:I've pointed out this to the authors privatly, so I'll repeat this publicly. I consider gss userauth to be broken since it doesn't verify the session id (using either mic or a channel bindings (like in CCM)).So I would like to propose adding the following text (marked with !) in 3.5 in draft-ietf-secsh-gsskeyex. I knowlingly break backward compability because I think the problem is important enough to (possibly) break backward compability. I've had a long chat with Jeff Hutzelman, and the solution that he and Sam Hartmans are talking about might be better then mine. I'm proposing this for a simple alternative solution to the problem.
I actually have two potential proposals. The first is a modification of what Love just described, which could allow it to be deployed in a backwards-compatible manner. However, it depends on existing server implementations behaving properly when sent messages they don't understand (i.e. they send SSH_MSG_UNIMPLEMENTED and otherwise do nothing). Unfortunately, I think we've already demonstrated that we may not be able to depend on existing implementations to handle this correctly in all cases. I do find it saddening that even when we go out of our way to provide a proper extensibility mechanism, it turns out to be pretty useless.
That said, I'm going to describe the solution that Love makes reference to above. This idea was originally proposed by Sam Hartman; I've filled in a few details and made some minor changes. Love thinks I should post some actual text as it might appear in the draft; I'll try to do that later, but I wanted to get the discussion rolling on this. I'd like to come to some concensus on how to address this issue in the near future, so that it can be incorporated in the next version of the draft.
The basic idea is to define a new userauth method, which for the sake of this discussion we'll call "gssapi-mic" (I know Joseph Galbraith just used this name to describe something else, but I chose it first, so too bad). The new method would consist of a single request message, containing the usual method-independent fields and a MIC resulting from gss_getmic:
byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-mic" string context-id string MIC MIC is obtained by calling gss_getmic over the following: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-mic" string context-idIn these messages, context-id is a string identifying the particular GSSAPI context to be used with gss_getmic and gss_verifymic to generate and verify the MIC. For now, the string "userauth" means that the context used is that established during the most recent exchange using the "gssapi" userauth method which terminated with SSH_MSG_USERAUTH_FAILURE with the partial success flag set. I'll describe another possible value later.
A "new" server desiring to support GSS userauth with session id binding should first advertise "gssapi" as a valid userauth method, as before. Upon receiving the SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE message at the end of a successful exchange, the server should return SSH_MSG_USERAUTH_FAILURE with the partial success flag set, and include "gssapi-mic" in the set of acceptable methods. A client supporting the new protocol can then complete the authentication process using the gssapi-mic method.
This method provides complete compatibility between new clients and old servers; with an old server, the gssapi method will simply return SSH_MSG_USERAUTH_SUCCESS. It also allows new server implementations to support old clients, by behaving as an old server would (return complete success instead of partial success). A new server can also decide which behaviour to use based on whether integrity is supported by the context; this means it is possible to require the MIC with those GSSAPI mechanisms which can support it, but still allow the use of mechanisms which do not.
There is also an additional advantage to this approach, which is that the same "gssapi-mic" userauth method can be used as an enhanced version of the "external-keyx" method which provides better binding of the user's identity to the session. In this usage, the context-id would be the string "keyexchange", indicating that the GSSAPI context to be used is that resulting from the successful gss-* key exchange used to establish the session.
-- Jeff