Subject: MechListMIC example text

From: Wyllys Ingersoll <[email-masked]>
Date: Mon, 06 Dec 2004 12:47:16 -0500

I'm proposing the following text as an example of how the MechListMIC
is computed.  I tried to keep it simple and just focus on the computation
of the MIC (as opposed to talking about the SOMIC rules and how
they would or would not appy).

-Wyllys

=====
A.3  MechListMIC Computation Example

    The following is an example to illustrate how the MechListMIC field
    would be computed.

    The initiator sent the following mechanisms (in order of preference):
    NTLMSSP (1.3.6.1.4.1.311.2.2.10) and Kerberos V5
    (1.2.840.113554.1.2.2).

        mechTypes:      a0 15 30 13 0A 2B 06 01 04 01 82 37 02 02 0A
                        09 2A 86 48 86 F7 12 01 02 02
        ReqFlags:       ...
        mechToken:      ...
        mechTokenMIC:   (not included in initial token)

    If a mechlistMIC needs to be generated (according to the rules in
    section 5), it is computed by using the DER encoding of the type
    MechTypeList field from the initiator's NegTokenInit token as input
    to the gss_GetMIC function.  In this case, the MIC would be computed
    over the following bytes:

        30 13 0A 2B 06 01 04 01 82 37 02 02 0A
        09 2A 86 48 86 F7 12 01 02 02

    Note that the identifier octet and length octet for constructed [0]
    (A0 15) are not included in the MIC computation.  The output token
    from gss_GetMIC would then be used as the mechTokenMIC field in
    subsequent token exchanges.

=====

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

---

From: Martin Rex <[email-masked]>
Date: Mon, 6 Dec 2004 19:16:25 +0100 (MET)

I'm confused.

Is there really a difference between what goes into signature
and what goes onto the wire?

As I wrote in my Email to the list on Nov 23th, the mech list in
a Microsoft SPNEGO token looks like this:

:
: 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

>         09 2A 86 48 86 F7 12 01 02 02

I think that your length field is incorrect, but also that the OID tags
should be there.  I would have expected:
          30 17 06 0A 2B 06 01 04 01 82 37 02 02 0A
          06 09 2A 86 48 86 F7 12 01 02 02

-Martin

---

From: Wyllys Ingersoll <[email-masked]>
Date: Mon, 06 Dec 2004 13:42:17 -0500

>           06 09 2A 86 48 86 F7 12 01 02 02

You are correct, I forgot the OID tag (0x06) in my example.
I will fix it and resend the text after I get more comments.

thanks,
    Wyllys

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 06 Dec 2004 13:43:10 -0500

On Monday, December 06, 2004 19:16:25 +0100 Martin Rex <[email-masked]> 
wrote:

> : an initial context token when requesting the "Negotiate" SSP on W2K3
> IA64: :
> : a0 24 30 22

I think you're right here.  Wyllys's example is missing the type-and-flags 
octet on both OID's, and undercounts the total length by a total of two.

-- Jeff