Subject: Re: SPNEGO implementation issues

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 03 Dec 2002 14:03:29 -0500

Richard -

Thank you for the detailed and informative explanation.  Most
of this is sort of what I had suspected.

This is something we could test and debug together at the
connectathon (http://www.connectathon.org) in a couple of months.
I know we will have several people from our Kerberos team
there to work on Krb5 and GSSAPI interop issues (Nico will be
there).   It would be great to have someone from MS there to
test with.

Anyway, thanks again for responding.
-Wyllys

Richard B. Ward wrote:
> There were two key flaws in the implementation of SPNEGO in Windows
> 2000, and they pretty much scope what you are seeing.  Between Beta 3
> and RC1 of Windows 2000, we incorporated two significant changes to our
> implementation of SPNEGO.  First, we switched to a different library for
> ASN/DER support.  Second, SNEGO was dropped in favor of SPNEGO.
> 
> First, the oid for kerberos (your issue #2 below).  The previous library
> had a limit of 16 bits on any value in the oid.  We had some code that
> was working around that, and that did not get updated at the same time
> (the correct OID for kerberos is 1.2.840.113554.1.2.2, and 113554 ==
> 0x1bb92; the incorrect OID that is sent around is 1.2.840.48018.1.2.2,
> with 48018 == 0xbb92).  Since at the time there were no other
> implementations of SPNEGO to test against, and we were self-consistent,
> this was not detected until after Windows 2000 shipped.  This was fixed
> in Windows XP and was fixed in a service pack for Windows 2000 (at least
> SP2 and later), as is evidenced by the correct OIDs showing up in the
> init message.  However, this is the first that we have heard of a
> problem when using the correct OID.  We will check into this right now.
> 
> Second, the mechList (your issue #1).  At the time we switched from
> SNEGO (Simple Negotiate) draft to the SPNEGO (Simple Protected
> Negotiate) RFC, the ASN.1 description that we created to use for sending
> into our ASN compiler was incorrect, and used the wrong PDU value for
> the negTokenTarg.  This ended up causing the mechanism token being
> encoded with the wrong value and sent across the wire.  This was
> detected before Windows 2000 was released, but the compatibility
> requirements between pre-release and final required us to support the
> token being in either field (accepting the token in the mechListMIC
> field in order to accept connections from pre-release Win2k machines,
> and sending the token in both fields in order to connect to pre-release
> machines).  Unfortunately, this was, as you determined, the mechListMIC
> field, and that made it impossible to generate signatures reliably in
> the Windows 2000 timeframe.  
> 
> As Nicolas mentioned in a separate response, while the mechListMIC field
> is marked as OPTIONAL in the ASN.1 language in the RFC, the rules for
> when it must be present or can be omitted are defined by the state of
> the actual protocol that was negotiated and the capabilities of the
> actual protocol.  Since this is potentially a tricky area to get right,
> this seems like a great opportunity for a bake-off of sorts to test it
> out.
> 
> This leads to the answer for your issue #3 - since we're not invoking
> the get_mic on the mechList, the sequence numbers won't be what you
> expect.  Again, this seems like a chance to test out interop.  We do
> take interop seriously, and try to fix bugs such as these.
> 
> -Rich
> 
> -----Original Message-----
> From: Wyllys Ingersoll [mailto:[email-masked]] 
> Sent: Monday, December 02, 2002 12:25 PM
> To: [email-masked]
> Subject: SPNEGO implementation issues
> 
> 
> 
> Recently, I've been working on an SPNEGO implementation as described by
> RFC 2478  that interoperates with Microsoft (Win2k Server).    I've come
> across some
> problems/issues and was wondering if anyone else has tried to
> interoperate with MS SPNEGO successfully or knows of these issues.
> 
> [ I raise these issues in this forum because it relates to RFC 2478
> compliance
>    and I think the CAT WG is dead, so this seems like the most
> appropriate forum.
>    My apologies if its too far off-topic ]
> 
> Test Environment:
>     * GSSAPI sample applications running in Solaris using SEAM software
> and native
>        Solaris GSSAPI implementation (i.e. NOT using MIT KRB5 GSS
> stuff).
>     * Microsoft's SSPI GSS client/server applications running on Windows
> 2000
>        server.
> 
> Problems Discovered:
> #1 - (Unix gss-client, Win2K gssserver) - All NegTokenTarg tokens sent
> from the SSPI
>      based server include a field tagged as if the MechListMIC were
> present, but
>      the data in that position is actually an exact copy of the
> 'responseToken'
>      field, not a MIC of the original mech list that the client sent to
> the  server.
>      In order to interoperate with MS as a GSS/SPNEGO client, the SPNEGO
> module
>      must ignore the mechListMIC field in the response from the server,
> it cannot
>      be verified since its not a valid MIC of anything.  This seems very
> wrong and
>     will make interoperating with both MS *and* anyone elses
> implementation that
>     actually includes a proper MIC difficult without some ugly hacks.
> The RFC says
>     the MIC field is optional, but including data in that field that is
> not a
>     real MIC is clearly wrong.
> 
> #2 - (Unix gss-server, Win2K gssclient) -  When the "Negotiate" package
> is specified
>     in the SSPI clients call to 'AcquireCredentialsHandle', the client
> sends a
>     'NegTokenInit' packet with a list of possible SSPI mechanisms.    On
> my
>     Win2K server (and probably most others) the OIDs for Kerberos and
>     NTLMSSP are sent.
>       1.2.840.48018.1.2.2
>       1.2.840.113554.1.2.2
>       1.2.840.113554.1.2.2.3
>       1.3.6.1.4.1.311.2.2.10
> 
> The first OID sent is a unique Microsoft OID for Kerberos V5.  In order
> to interoperate correctly (and use Kerberos V5), the Unix gss-server
> SPNEGO
> code must use this bogus OID value.   If the server chooses to respond
> to the
> client and indicate that the selected mechanism is the "correct" OID for
> Krb5 (1.2.840.113554.1.2.2), the MS client will complain - "Cannot
> contact the
> LSA".   If the server responds to the client and uses the bogus
> Microsoft
> KRB5 OID (1.2.840.48018.1.2.2), the client will accept this and continue
> the conversation.     This is very odd.  If it can talk to the LSA for
> the wrong
> OID, why can't it talk to the LSA when the correct OID is used,
> specially considering that the "correct" OID was one of the values
> advertised by the SSPI client in the first place ?
> 
> This seems badly broken, in order to interoperate, all non-MS GSS SPNEGO
> implementations must understand that this bogus OID is supposed to be
> treated the same as the correct KRB5 OID (1.2.840.113554.1.2.2) and make
> the proper substitution in the NegTokenTarg packet generation (if
> Kerberos is to be selected).
> 
> #3 - (Unix gss-server, Win2K gssclient) - SSPI seems to completely
> ignore the
>       contents of the MechListMIC field in the NegTokenTarg token.  This
> causes
>       a problem with the GSS sequence numbering.   An RFC 2478 compliant
> server
>      will call 'gss_get_mic' on the original mechListMIC in order to
> include the MIC
>      in the response to the NegTokenInit packet (following the  RFC).
> This
>      increments  the internal GSS sequence number used when generating
> MICs
>      within the KRB5 GSS mechanism.
> 
>       Later, after the SSPI client has successfully sent its actual data
> to the
>      GSSAPI server,  the gss-server must send back a MIC of the message
> to the SSPI
>      gssclient as a final verification that the data was transferred OK.
> This 
> causes
>      the sequence number to be incremented again. The problem is that
> because the
>      SSPI code never verified the MIC in the NegTokenInit packet, it is
> not 
> expecting
>      the sequence number to be incremented when the MIC of the final
> data is sent
>      and an "incorrect sequence number" error occurs when the SSPI
> client tries to
>      verify the final signature.
>      Workaround - dont generate or sent a MechListMIC to Microsoft
> clients.
> 
> So, if you want to interoperate with MS, dont bother creating or sending
> MechListMIC fields in either the initiator or target packets.  This
> would seem to weaken the whole negotiation process since there is no way
> to verify that the originally desired list of mechanisms was not
> altered.
> 
> Of course, one could say that a MechListMIC is useless when the list
> contains mechanisms that do not support integrity protection (e.g
> NTLMSSP) since its not possible to generate a MIC if one of those mechs
> is chosen.  However, it seems that if the chosen mechanism does support
> integrity (like Kerberos V5), then the MIC should be generated just to
> be safe.
> 
> Anyway, if anyone has any comments or can shed some light on these
> issues it would be appreciated.
> 
> -Wyllys Ingersoll
>   Sun Microsystems.
> 
> 
> 
> 
> 
>

---

From: [email-masked]
Date: Tue, 3 Dec 2002 10:40:30 -0800

<[email-masked]>
Thread-Topic: SPNEGO implementation issues
Thread-Index: AcKaRDN4DnLkBs27QeSCgp/bKuISHgAB+47A
From: "Richard B. Ward" <[email-masked]>
To: "Wyllys Ingersoll" <[email-masked]>, <[email-masked]>
X-OriginalArrivalTime: 03 Dec 2002 18:40:31.0089 (UTC) FILETIME=[750A8E10:01C29AFB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by atalanta.ctd.anl.gov id MAA27369
Sender: [email-masked]
Precedence: bulk

-Rich

-----Original Message-----
From: Wyllys Ingersoll [mailto:[email-masked]] 
Sent: Monday, December 02, 2002 12:25 PM
To: [email-masked]
Subject: SPNEGO implementation issues

Test Environment:

Problems Discovered:

-Wyllys Ingersoll
  Sun Microsystems.

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 Dec 2002 22:52:16 +0100 (MET)

> problem when using the correct OID.  We will check into this right now.

To bad that Microsoft puts such a large amount of Mony into end-user
tests and marketing and ZERO into API-level testing.  All of the
bugs I've found in Microsoft's APIs could have been found by
using tools like "Purify", using a freely available test tool that
has been previously used to find and report errors or by single
stepping (function granularity) through the code once...

> the Windows 2000 timeframe.  

So instead of fixing the limited amount of "evaluation pre-release"
installation which is designed to time-bomb anyway, you prefered to
create a large installed broken base that will create interop problems
and thousands of support calls.

You should have shipped **CORRECT** implementations that would
tolerate&participate the incorrect behaviour, but timebomb on
incorrect behaviour at most 180 days after W2K finally shipped. 
i.e. when a the client sends a correct mechListMIC the server
should have acted and responded as the SPNEGO spec requires,
but according to Wyllys, it doesn't.

So if you're fixing the first bug (your counting), then make sure
that at least for such negotiations the CORRECT SPNEGO handshake is
performed, i.e. correct Kerberos-5 OID is used should result in
correct mechListMIC handling, since your broken implementations
don't seem to work with the correct Kerberos-5 OID anyway.

> this seems like a great opportunity for a bake-off of sorts to test it

Implementing SPNEGO *correctly* should be fairly easy (once you master
the ASN.1 stuff).  Devising interoperability with badly broken
implementations might be somewhat tricky.  But the coincidental
simultaneous breakage with the Kerberos OID might proove helpful
in guessing about the peers bugs...

> take interop seriously, and try to fix bugs such as these.

API-level testing and visual inspection of the emitted on-the-wire
protocols often help in spotting such problems long before you have
implementations available for interop testing.

Having descriptive language and actual data dumps/sample data in a
spec greatly facilitates this task and provides the necessary
redundancy info for redundancy checks.  

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 3 Dec 2002 16:59:09 EST

> redundancy info for redundancy checks.  

Helping to fund open source implementations of significant core
protocols would also help in your interop testing.

- Jeff

 Jeffrey Altman * Volunteer Developer      Kermit 95 2.1 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 [email-masked]               OpenSSL.