Subject: updated MIC computation example text

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 07 Dec 2004 12:03:21 -0500

I've updated the text for the MIC computation example based
on comments received.   I reused some text from Tom Yu's
email from a couple of weeks ago to try and clarify how
each part is put together.

-Wyllys Ingersoll

=====
A.3  MechListMIC Computation Example
    The following is an example to illustrate how the MechListMIC field
    would be computed.

    The NegTokenInit sequence is constructed as follows:

       30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
       nn -- length

       -- contents of SEQUENCE are:
       A0 -- identifier octet for constructed [0]
       nn -- length

       -- contents of the constructed [0] are:
       30 -- identifier octet for constructed SEQUENCE
       nn -- length

       -- contents of the SEQUENCE are:
       06 -- identifier octet for primitive OBJECT IDENTIFIER
       09 -- length
       2A 86 48 86 F7 12 01 02 02 -- Kerberos V5 { 1 2 840 113554 1 2 2 }

    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:

       Contents of constructed [0] + contents of SEQUENCE:
       30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...

    Note that the identifier octet and length octet for constructed [0]
    (A0 nn) are not included in the MIC computation, just the contents.
    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: Sam Hartman <[email-masked]>
Date: Tue, 07 Dec 2004 13:12:42 -0500

Why does this example focus on the NegTokenInit instead of on the
MecListMIC?

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 07 Dec 2004 14:11:51 -0500

> Why does this example focus on the NegTokenInit instead of on the

The focus is supposed to be on the MechListMIC, but I felt that
it was more helpful to show the context surrounding the MechList
in order to clearly illustrate the bytes that the MIC would (and would
not) include.

Does anyone find the example helpful or does it just add more
confusion?

-Wyllys

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Dec 2004 18:02:43 -0500

>>>>> "Wyllys" == Wyllys Ingersoll <[email-masked]> writes:

    Wyllys> Sam Hartman wrote:
    >> Why does this example focus on the NegTokenInit instead of on
    >> the MecListMIC?

    Wyllys> The focus is supposed to be on the MechListMIC, but I felt
    Wyllys> that it was more helpful to show the context surrounding
    Wyllys> the MechList in order to clearly illustrate the bytes that
    Wyllys> the MIC would (and would not) include.

O, I see.  Concern withdrawn; I see both why I would find it confusing
and why I suspect most readers would not.

--Sam

---

From: Tom Yu <[email-masked]>
Date: Tue, 07 Dec 2004 20:10:54 -0500

>>>>> "Wyllys" == Wyllys Ingersoll <[email-masked]> writes:

Wyllys> A.3  MechListMIC Computation Example
Wyllys>     The following is an example to illustrate how the MechListMIC field
Wyllys>     would be computed.

Wyllys>     The NegTokenInit sequence is constructed as follows:

I would replace the above with

            The initial part of the DER encoding of NegTokenInit is
            constructed as follows (the "nn" are length encodings,
            possibly longer than one octet):

Wyllys>        30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
Wyllys>        nn -- length

Wyllys>        -- contents of SEQUENCE are:

replace above with

               -- contents octets of the SEQUENCE begin with
               -- DER encoding of "[0] MechTypeList":

Wyllys>        A0 -- identifier octet for constructed [0]
Wyllys>        nn -- length

Wyllys>        -- contents of the constructed [0] are:

replace above with

               -- contents of constructed [0] are
               -- DER encoding of MechTypeList (which is a SEQUENCE):

Wyllys>        30 -- identifier octet for constructed SEQUENCE
Wyllys>        nn -- length

Wyllys>        -- contents of the SEQUENCE are:

replace above with

               -- contents octets of the SEQUENCE begin with
               -- DER encoding of OBJECT IDENTIFIER:

Wyllys>        06 -- identifier octet for primitive OBJECT IDENTIFIER
Wyllys>        09 -- length
Wyllys>        2A 86 48 86 F7 12 01 02 02 -- Kerberos V5 { 1 2 840 113554 1 2 2 }

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

Wyllys>        Contents of constructed [0] + contents of SEQUENCE:

I really don't like the "contents of ..." phrasing, and would replace
the above with:

               DER encoding of MechTypeList:

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

Wyllys>     Note that the identifier octet and length octet for constructed [0]
Wyllys>     (A0 nn) are not included in the MIC computation, just the contents.

I would replace the above text with:

            Note that the identifier octet and lengh octet(s) for
            constructed [0] (A0 nn) are not included in the MIC
            computation.  The MIC is computed over the encoding of the
            MechTypeList which is enclosed in the constructed [0]
            encoding.

Wyllys>     The output token from gss_GetMIC would then be used as the
Wyllys>     mechTokenMIC field in subsequent token exchanges.

Hopefully that helps to make things a bit more clear.  Is there any
particular reason that there is not indentation of the different
levels of encodings?

---Tom

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 07 Dec 2004 20:58:52 -0500

Here is an update with Tom's (and others) comments
taken into consideration:

====

    The initial part of the DER encoding of NegTokenInit is constructed
    as follows (the "nn" are length encodings, possibly longer than one
    octet):

              -- contents of the constructed [0] are DER encoding
              -- of MechTypeList (which is a SEQUENCE):
              30 -- identifier octet for constructed SEQUENCE
              nn -- length

                 -- contents octets of the SEQUENCE begin with
                 -- DER encoding of OBJECT IDENTIFIER:
                 06 -- identifier octet for primitive OBJECT IDENTIFIER
                 09 -- length
                 2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
                                            -- {1 2 840 113554 1 2 2}

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

    Note that the identifier octet and lengh octet(s) for constructed [0]
    (A0 nn) are not included in the MIC computation.  The MIC is computed
    over the encoding of the MechTypeList which is enclosed in the
    constructed [0] encoding.  The output token from gss_GetMIC would
    then be used as the mechTokenMIC field in subsequent token exchanges.
====