Subject: LAST CALL COMMENT: Section 5 (was RE: Last word on MechListMIC encoding)

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Thu, 2 Dec 2004 15:12:44 -0800

I agree with you and the understanding below is correct, perhaps we
should provide an example encoding to demonstrate what is included? That
will make it easier for casual readers who might not understand the
rather obscure ASN.1 terminology.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wyllys Ingersoll
Sent: Thursday, December 02, 2004 6:50 AM
To: [email-masked]
Subject: Last word on MechListMIC encoding

The latest draft  submitted (-02) specifically states how the
MechListMIC is to be encoded:
Section 5, item 'a' says:
        [...] only the DER encoding of the type MechTypeList is
included.

I interpret this to mean the following in the case where the MechList
contains the Kerberos OID (as an example):
       30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...

This is acceptable to me (even though it breaks our current
implementation, which I seriously doubt that anyone is interoperating
with anyway since its not yet released).

Is everyone else in agreement about the definition of how to encode the
MIC  and with the text as it is written?

-Wyllys Ingersoll

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

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

---

From: Tom Yu <[email-masked]>
Date: Fri, 03 Dec 2004 12:55:06 -0500

>>>>> "lzhu" == Liqiang\(Larry\) Zhu <Liqiang> writes:

lzhu> I agree with you and the understanding below is correct, perhaps we
lzhu> should provide an example encoding to demonstrate what is included? That
lzhu> will make it easier for casual readers who might not understand the
lzhu> rather obscure ASN.1 terminology.

    5.  Processing of mechListMIC
[...]
       a) The mechlistMIC token (or simply the MIC token) is computed by
          invoking GSS_GetMIC(): the input context_handle is the established
          mechanism context, the input qop_req is 0, and the input message
          is the mechTypes field in the initial negotiation message (only
          the DER encoding of the type MechTypeList is included).

The above text still uses the term "mechTypes field" in an ambiguous
way, and relegates the important details to a parenthetical comment.
I reiterate my view that it is ambiguous to speak of the encoding of a
field; complete ASN.1 encodings are of _types_.

I would change the text to something like:

       a) The mechlistMIC token (or simply the MIC token) is computed by
          invoking GSS_GetMIC(): the input context_handle is the established
          mechanism context, the input qop_req is 0, and the input message
          is the DER encoding of the value of type MechTypeList which is
          contained in the "mechTypes" field of the NegTokenInit.  The input
          message is NOT the DER encoding of the type "[0] MechTypeList".
          (Previous versions of this document were ambiguous about which
          ASN.1 type was to be DER-encoded for the MIC.)

The wording could be cleaned up some more, but I thought it was
important to get this correction out quickly.

---Tom

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Dec 2004 14:21:51 -0600

>           ASN.1 type was to be DER-encoded for the MIC.)

I like that.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 03 Dec 2004 15:46:14 -0500

>>          ASN.1 type was to be DER-encoded for the MIC.)

I agree, I also think this is a good change.

I was also going to write some text to try and illusrate this in an
example, does anyone think that is necessary or is this new text
good enough?

-Wyllys

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Dec 2004 16:26:56 -0500

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

    Wyllys> Nicolas Williams wrote:
    >>> a) The mechlistMIC token (or simply the MIC token) is computed
    >>> by invoking GSS_GetMIC(): the input context_handle is the
    >>> established mechanism context, the input qop_req is 0, and the
    >>> input message is the DER encoding of the value of type
    >>> MechTypeList which is contained in the "mechTypes" field of
    >>> the NegTokenInit.  The input message is NOT the DER encoding
    >>> of the type "[0] MechTypeList".  (Previous versions of this
    >>> document were ambiguous about which ASN.1 type was to be
    >>> DER-encoded for the MIC.)

    Wyllys> I agree, I also think this is a good change.

    Wyllys> I was also going to write some text to try and illusrate
    Wyllys> this in an example, does anyone think that is necessary or
    Wyllys> is this new text good enough?

Based on comments on this list and the confusion, I will insist on an
example during AD review.  It would be great if we already had text
for one.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 03 Dec 2004 16:49:15 -0500

> example during AD review.  It would be great if we already had text

OK, I'll write some up and submit it to the list early next week.

-Wyllys

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 03 Dec 2004 17:25:49 -0500

> example, does anyone think that is necessary or is this new text

Given the incompatibilities and confusion between 2478 and this protocol
revision, I believe an example is absolutely necessary.

I consider the addition of such an example an editorial change to the
document.

Jeffrey Altman