Ticket History #7858: SPNEGO server responds incorrectly to Microsoft krb5 mech type

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.

Properly reflect MS krb5 mech in SPNEGO acceptor

r25590 changed negotiate_mech() to return an alias into the acceptor's
mech set, with the unfortunate side effect of transforming the
erroneous Microsoft krb5 mech OID into the correct krb5 mech OID,
meaning that we answer with a different OID than the requested one.
Return an alias into the initiator's mech set instead, and store that
in mech_set field the SPNEGO context. The acceptor code only uses
mech_set to hold the allocated storage pointed into by internal_mech,
so this change is safe.

https://github.com/krb5/krb5/commit/8255613476d4c1583a5e810b50444f188fde871f
Author: Greg Hudson <ghudson@mit.edu>
Commit: 8255613476d4c1583a5e810b50444f188fde871f
Branch: master
src/lib/gssapi/spnego/spnego_mech.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)

Properly reflect MS krb5 mech in SPNEGO acceptor

r25590 changed negotiate_mech() to return an alias into the acceptor's
mech set, with the unfortunate side effect of transforming the
erroneous Microsoft krb5 mech OID into the correct krb5 mech OID,
meaning that we answer with a different OID than the requested one.
Return an alias into the initiator's mech set instead, and store that
in mech_set field the SPNEGO context. The acceptor code only uses
mech_set to hold the allocated storage pointed into by internal_mech,
so this change is safe.

(cherry picked from commit 8255613476d4c1583a5e810b50444f188fde871f)

https://github.com/krb5/krb5/commit/dc31efaeec2c10dfd87951b9298c187f4c65bb39
Author: Greg Hudson <ghudson@mit.edu>
Committer: Tom Yu <tlyu@mit.edu>
Commit: dc31efaeec2c10dfd87951b9298c187f4c65bb39
Branch: krb5-1.12
src/lib/gssapi/spnego/spnego_mech.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)