Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Subject: SPNEGO server responds incorrectly to Microsoft krb5 mech type
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1608

Microsoft's SPNEGO implementation erroneously uses 1.2.840.48018.1.2.2 
as the krb5 mech OID.  If an initiator sends a SPNEGO token with an 
optimistic mech token of this erroneous OID and the acceptor uses this 
token, the acceptor must respond with the erroneous OID in the 
supportedMech field of the NegTokenResp message, per [MS-SPNG].

Since 1.10 we have been responding with the real krb5 mech OID 
(1.2.840.113554.1.2.2) in supportedMech, due to a combination of two 
changes:

* In r21361 (which was part of the mskrb5-integ branch and went into 
1.7), Luke added explicit code to match the Microsoft krb5 mech OID in 
negotiate_mech_type, so that we would look for the real krb5 mech in 
supported_mechSet.  It is not clear why this is needed since we have a 
mech definition for the Microsoft krb5 mech OID, but it didn't cause any 
problems because the sender's mech OID was copied to create the mech 
OID.

* In r25590 (which was pulled up to 1.10), I changed the SPNEGO context 
to contain a list of mechs and an alias into that list for 
internal_mech.  The intent of the change was only to affect the behavior 
of the initiator, but negotiate_mech_type was renamed to negotiate_mech 
and changed to return an alias to the element we found in supported 
rather than a copy of the element we chose from the sender.  Because of 
this, when the sender uses the MS krb5 mech OID, we respond with the 
real one.

The acceptor code doesn't use mech_set field except to hold the memory 
pointed to by internal_mech, so we can safely change it to store the 
initiator's mech list and an alias into it.