Parsing a Negotiate header is sort of a tedious exercise as it's built using ASN.1 DER.
That said, you may not necessarily need to decode this however to make a good assumption about the payload. While there is a mechanism in GSSAPI for NTLM (more on that below), in my experience clients do not actually use it, they simply send NTLM headers. In my (admittedly strictly controlled) environment, if I see Authorization: NTLM ...
then this is guaranteed to be NTLM. If I see Authorization: Negotiate ...
then this is guaranteed to be Kerberos.
Strictly speaking, you should look at the mechanism list in the header to determine whether the mechanism was NTLM or Kerberos. I would recommend either using an off-the-shelf ASN.1 decoder, or looking at Microsoft's decoding example. You're going to want to look for the SPNEGO OID (1.3.6.1.5.5.2
), then look for the mechanism type sequence within that. The first mechanism in the sequence corresponds to the response token payload, so you can look at that OID to determine the mechanism. Some known OIDs for Kerberos are:
1.2.840.113554.1.2.2 (Kerberos 5)
1.2.840.48018.1.2.2 (Microsoft Kerberos 5)
1.3.5.1.5.2 (Kerberos 5 OID 2)
To my knowledge, the only OID for NTLM is (referenced from this blog):
1.3.6.1.4.1.311.2.2.10 (NLMP NTLM)