Return-Path: Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (Postfix) with ESMTP id 4DFE53DED4; Wed, 19 May 2010 16:51:38 -0400 (EDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o4JKpcax020704; Wed, 19 May 2010 16:51:38 -0400 Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o4JKn85G020360 for ; Wed, 19 May 2010 16:49:08 -0400 Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id o4JKkaNd021696 for ; Wed, 19 May 2010 16:49:08 -0400 X-Auditid: 1209190e-b7b82ae000005260-67-4bf44ec3632b Received: from sh2.exchange.ms (sh2.exchange.ms [64.71.238.64]) by dmz-mailsec-scanner-3.mit.edu (Symantec Brightmail Gateway) with SMTP id 51.89.21088.3CE44FB4; Wed, 19 May 2010 16:49:08 -0400 (EDT) Received: from outbound.mse3.exchange.ms (unknown [10.0.25.203]) by sh2.exchange.ms (Postfix) with ESMTP id 6BFEA3D80F8 for ; Wed, 19 May 2010 16:45:51 -0400 (EDT) X-Mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: SPNEGO doesn't interoperate with Windows 2000 Date: Wed, 19 May 2010 16:46:20 -0400 Message-ID: <23447137FA0DAA4D95EF535FF356BE46047EDAF6@mse3be2.mse3.exchange.ms> X-MS-Has-Attach: X-MS-Tnef-Correlator: Thread-Topic: SPNEGO doesn't interoperate with Windows 2000 Thread-Index: Acr3lFYgy7623DrXQtyvXneK1YTgeA== From: "Arlene Berry" To: X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o4JKn85G020360 X-Mailman-Approved-At: Wed, 19 May 2010 16:51:36 -0400 X-Beenthere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: krb5-bugs-incoming-bounces@PCH.mit.edu Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu X-RT-Original-Encoding: us-ascii Content-Length: 1492 The problem is Windows 2000 returns a second copy of the mechanism response token as the mechListMIC. We saw this with Windows 2000 Server. We worked around the problem by changing get_negTokenResp which parses out the SPNEGO token components to detect the duplicate token and not return it as a mechListMIC. This prevents subsequent errors when attempting to parse the duplicate response as a mechListMIC and was enough for it to work. The decision as to whether a mechListMIC is required happens elsewhere and is unchanged. Index: src/lib/gssapi/spnego/spnego_mech.c =================================================================== --- src/lib/gssapi/spnego/spnego_mech.c (revision 40750) +++ src/lib/gssapi/spnego/spnego_mech.c (revision 40751) @@ -3111,6 +3111,19 @@ *mechListMIC = get_input_token(&ptr, REMAIN); if (*mechListMIC == GSS_C_NO_BUFFER) return GSS_S_DEFECTIVE_TOKEN; + + /* Handle Windows 2000 duplicate response token */ + if (*responseToken && + ((*responseToken)->length == (*mechListMIC)->length) && + !memcmp((*responseToken)->value, (*mechListMIC)->value, + (*responseToken)->length)) + { + OM_uint32 tmpmin; + + gss_release_buffer(&tmpmin, *mechListMIC); + free(*mechListMIC); + *mechListMIC = NULL; + } } return GSS_S_COMPLETE; #undef REMAIN