Subject: | Negotiating NTLM with SPNEGO against Windows Server 2003 doesn't work |
https://bugzilla.redhat.com/show_bug.cgi?id=1122324 refers to a
situation where:
* An NTLM mech is loaded.
* The user has initial tickets.
* A service ticket cannot be obtained for the server (say, because its
IP address was used).
* The application server implements an old variant of SPNEGO without
mechlistMIC support.
In this scenario, we never try regular krb5 because we can't get a
service ticket. But we do try IAKERB, which only requires an initial
ticket. We would like the negotiation to fall back to NTLM, but it
can't, because the server doesn't respond with REQUEST_MIC and
init_ctx_reselect requires that it does.
We have several options for making this scenario work:
* Provide a way to disable IAKERB via configuration. (A client
application can already do this with gss_set_neg_mechs, but in this case
the client is a web browser and is probably not interested in mucking
around with mech OIDs.)
* Provide a way to load a mechanism such that it is ordered between krb5
and IAKERB.
* Relax the requirement for a MIC exchange when a non-preferred
mechanism is selected. This is David Woodhouse's suggestion, but it
essentially removes RFC 4178's downgrade protection.
* Relax the requirement for a MIC exchange when a non-preferred
mechanism is selected, unless the negotiated mech context is "new
enough" to indicate that the peer ought to support RFC 4178. Heimdal
appears to do this via the GSS_C_PEER_HAS_UPDATED_SPNEGO
inquire_sec_context_by_oid query.
See also:
http://mailman.mit.edu/pipermail/krbdev/2014-July/012085.html
situation where:
* An NTLM mech is loaded.
* The user has initial tickets.
* A service ticket cannot be obtained for the server (say, because its
IP address was used).
* The application server implements an old variant of SPNEGO without
mechlistMIC support.
In this scenario, we never try regular krb5 because we can't get a
service ticket. But we do try IAKERB, which only requires an initial
ticket. We would like the negotiation to fall back to NTLM, but it
can't, because the server doesn't respond with REQUEST_MIC and
init_ctx_reselect requires that it does.
We have several options for making this scenario work:
* Provide a way to disable IAKERB via configuration. (A client
application can already do this with gss_set_neg_mechs, but in this case
the client is a web browser and is probably not interested in mucking
around with mech OIDs.)
* Provide a way to load a mechanism such that it is ordered between krb5
and IAKERB.
* Relax the requirement for a MIC exchange when a non-preferred
mechanism is selected. This is David Woodhouse's suggestion, but it
essentially removes RFC 4178's downgrade protection.
* Relax the requirement for a MIC exchange when a non-preferred
mechanism is selected, unless the negotiated mech context is "new
enough" to indicate that the peer ought to support RFC 4178. Heimdal
appears to do this via the GSS_C_PEER_HAS_UPDATED_SPNEGO
inquire_sec_context_by_oid query.
See also:
http://mailman.mit.edu/pipermail/krbdev/2014-July/012085.html