[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478

David Woodhouse dwmw2 at infradead.org
Fri Jul 25 06:42:30 EDT 2014

From: David Woodhouse <David.Woodhouse at intel.com>

Servers running Windows 2003 and earlier do not send a negState of
request-mic in their initial reply when the first mechanism is
declined. That's because they implement (roughly) RFC2478, which
predates the addition of the request-mic state.

A server conforming to RFC4178 MUST send request-mic there, but it
is equally clear that on the client side, we should deal with its
absence. For example, the language in §5 (c) is as follows:
    "if the negState was request-mic in the first reply from the
     target, a mechlistMIC token MUST be included; otherwise..."

In the MIT implementation as it stands, there is no "otherwise".
Because we already overzealously aborted the negotiation.

Other language in RFC4178 which supports this interpretation includes
the whole of Appendix C, which explains the changes since RFC2478.

Looking at that, in fact it seems that the addition of request-mic on
the wire was done specifically to allow interoperability with older
implementations which don't set it. If not for that consideration,
and if we were only ever communicating between RFC4178-compliant
implementations, we could always have just behaved as if request-mic
were set — and there would be no need to *say* so on the wire.

On a practical note, the potential vulnerability which is permitted
by failing to use a MIC is described in §7, and exists anyway when
the selected mechanism doesn't support integrity protection:

   "In order to produce the MIC token for the mechanism list, the
   mechanism must provide integrity protection.  When the selected
   mechanism does not support integrity protection, the negotiation is
   vulnerable: an active attacker can force it to use a security
   mechanism that is not mutually preferred but is acceptable to the

So the vulnerability is that a hypothetical attacker can trick us into
selecting a mechanism that both client and server were prepared to use
anyway, and which the server *would* have accepted if we'd happened to
try it first.

In practice, the viable fallback mechanism is almost always going to be
NTLMSSP. And in the case of HTTP and many other protocols, our
hypothetical attacker would have a much easier way of making the client
use NTLM — just mangle the 'WWW-Authenticate: Negotiate' in the 401
response so that my client only sees the 'WWW-Authenticate: NTLM', and
no need to screw around with SPNEGO packets at all.

(Note: If I could just disable IAKERB, or install the GSS-NTLMSSP plugin
with a sufficiently high priority that it's the first thing we offer to
this server, that would also suffice for me to avoid this problem. As
long as I offer GSS-NTLMSSP first and not IAKERB (which never works in
my environment and only serves to exacerbate other issues such as this
one), I'd be OK.)

 src/lib/gssapi/spnego/spnego_mech.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/lib/gssapi/spnego/spnego_mech.c b/src/lib/gssapi/spnego/spnego_mech.c
index 2aa6810..9721cad 100644
--- a/src/lib/gssapi/spnego/spnego_mech.c
+++ b/src/lib/gssapi/spnego/spnego_mech.c
@@ -831,17 +831,17 @@ init_ctx_reselect(OM_uint32 *minor_status, spnego_gss_ctx_id_t sc,
 	sc->internal_mech = &sc->mech_set->elements[i];
-	 * Windows 2003 and earlier don't correctly send a
-	 * negState of request-mic when counter-proposing a
-	 * mechanism.  They probably don't handle mechListMICs
-	 * properly either.
+	 * A server conforming to RFC4178 MUST set REQUEST_MIC here
+	 * but Windows 2003 and earlier implement (roughly) RFC2478
+	 * instead, and send ACCEPT_INCOMPLETE.
-	if (acc_negState != REQUEST_MIC)
+	if (acc_negState != REQUEST_MIC &&
+	    acc_negState != ACCEPT_INCOMPLETE)
 	sc->mech_complete = 0;
 	sc->mic_reqd = 1;
-	*negState = REQUEST_MIC;
+	*negState = acc_negState;
 	*tokflag = CONT_TOKEN_SEND;

David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20140725/2a92d0a3/attachment.bin

More information about the krbdev mailing list