Subject: SPNEGO and MechListMIC field

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 09 Nov 2004 11:01:40 -0500

If I recall correctly (and from looking at my own code), in order to 
interoperate
with Microsoft's SPNEGO implementation, the MIC must never be sent by an
initiator nor should it be expected or processed by an acceptor.

If this is the case, then I don't think we risk breaking backwards 
compatibility
by including the reqFlags in the MIC calculation for the new spec.   It 
would
obviously be incompatible with the current spec, but the risk of breaking
deployed implementations is very small.

So, someone remind me again, why not put reqFlags in the MIC ?

-Wyllys

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Martin Rex <[email-masked]>
Date: Tue, 9 Nov 2004 18:14:57 +0100 (MET)

Wyllys Ingersoll wrote:
> interoperate with Microsoft's SPNEGO implementation, the MIC must
> never be sent by an initiator nor should it be expected or processed
> by an acceptor.

I have no experience with Microsoft's SPNEGO implementation, so I'm
curious:

The situation that an initiator would be required to send a mechListMIC
would only happen for an odd number of context establishment tokens,
accompanying the final context establishment token from initiator
to target.

For rfc-1964 this would affect target-only authentication (i.e. when
"mutual" authentication is not requested), and for Microsoft's Kerberos SSP
it would also affect the proprietary user2user authentication (which is
quite difficult to avoid when the KDC is a W2K3 AD in W2K3 native mode).

The absence of the mechListMIC token is equivalent to *NO* protection of
the negotiation.  As the purpose of the protection is primarily to prevent
a downgrade attack on a mechanism List that includes weak mechanisms,
there shouldn't be a problem when the strongest available choice
is Kerberos and the negotiation result is Kerberos, even when the
mechListMic is absent.

There will be a problem when stronger mechanisms (or stronger variants
of Kerberos) are added.

In the original SPNEGO spec, the mechListMIC was a MUST.  How much
of the must can we retain in the successor spec, i.e. how tightly can
we identify the interop scenarios with broken SPNEGO implementations
so that we can actually retain the "P" of SPNEGO.

Keep in mind that the many of PKI-based gssapi mechanisms have an
odd number of security context tokens in the handshake!

I would prefer when we could keep the MUST send mechListMIC, but document
the precise interop scenarios for a particular broken implementation, so
any SPNEGO that negotiate and starts a handshake with a non-rfc1964
(and non-microsoft-user2user?) mechanism MUST send the mechListMIC
as the original spec required.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 09 Nov 2004 14:16:26 -0500

FYI, we had a discussion with Larry over lunch and he convinced us
that his negotiation rules are reasonable and always provide
protection for a new implementation.

--Sam