Subject: Re: What is SPNEGO mechlistMIC computed over? (was Re: SPNEGO-bis...)

From: "Frank Balluffi" <[email-masked]>
Date: Tue, 23 Nov 2004 10:06:23 -0500

I do not fully understand what Larry means by "my code", but would just add that I have always received (a) from IE. The actual octets I have seen are:

A0 24 30 22                             mechTypes
   06 09 2A 86 48 82 F7 12 01 02 02       1.2.840.48018.1.2.2 (Kerberos V5 Legacy)
   06 09 2A 86 48 86 F7 12 01 02 02       1.2.840.113554.1.2.2 (Kerberos V5 GSS-API mechanism)
   06 0A 2B 06 01 04 01 82 37 02 02 0A    1.3.6.1.4.1.311.2.2.10 (Microsoft SPNEGO sub-mechanism)

Frank

                      Wyllys Ingersoll                                                                                                  
                      <wyllys.ingersoll@        To:       "Liqiang(Larry) Zhu" <[email-masked]>                             
                      sun.com>                  cc:       [email-masked]                                                               
                      Sent by:                  Subject:  Re: What is SPNEGO mechlistMIC computed over? (was    Re:   SPNEGO-bis...)    
                      kitten-bounces@lis                                                                                                
                      ts.ietf.org                                                                                                       

                      11/23/2004 07:58                                                                                                  
                      AM                                                                                                                

Liqiang(Larry) Zhu wrote:
> Tom, thanks, choice (b) is clearly what we intended.
>

  (a) The DER encoding of the type "[0] MechTypeList", i.e.:

      A0 nn 30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...

  (b) The DER encoding of the type "MechTypeList", i.e.:

      30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...

 From looking at my code, it appears that I interpreted
the original document to mean A), but if the consensus is
that B is correct, I can make the adjustment without much
pain since MICs are not used at all in situations where we
are interoperating with MS anyway.

-Wyllys

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 23 Nov 2004 10:45:56 -0500

> I do not fully understand what Larry means by "my code", but would just add that I have always received (a) from IE. The actual octets I have seen are:

It was me (Wyllys Ingersoll), not Larry, who wrote about "my code".  I was referring to
a SPNEGO mechanism that I wrote which will be included in Solaris 10.
I wrote one that interoperates with  MS but that has a configurable option
to be RFC 2478 compliant (and not interop with Microsoft). In the latter
case, the MIC was computed across the DER encoding of "[0] MechTypeList"
which is choice "a" from Tom Yu's earlier post on the topic.

Whatever you received from IE or IIS in the past during SPNEGO negotiation should
have been ignored because it was completely wrong and wasn't even a MIC at all, it
was a copy of one of the other fields.

-Wyllys

---

From: Martin Rex <[email-masked]>
Date: Tue, 23 Nov 2004 19:23:10 +0100 (MET)

I was a little confused by your description (of OIDs and descriptions of
those OIDs) therefore I rechecked quickly.  Here's what I get inside
an initial context token when requesting the "Negotiate" SSP on W2K3 IA64:

a0 24 30 22
  06 09 2a 86 48 82 f7 12 01 02 02       unknown OID (MS Kerberos bug?)
  06 09 2a 86 48 86 f7 12 01 02 02       Kerberos rfc-1964 gssapi
  06 0a 2b 06 01 04 01 82 37 02 02 0a    Microsoft non-IETF NTLM SSP mechanism

It would be incorrect to include a "negotiation" mechanism OID,
like the one of SPNEGO itself in that list.

However what I'm missing in this list is actually the OID that is
used for Microsoft's proprietary user2user extension:

  06 0a 2a 86  48 86 f7 12 01 02 02 03

The context tokens which you undocumentedly get when passing the
"ISC_REQ_USE_SESSION_KEY" context attribute to InitializeSecurityContext
(or which if forced upon you if someone was crazy enough to upgrade his
 Active Directory to Windows 2003 and switch it to Windows 2003 native mode).

-Martin