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

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Mon, 22 Nov 2004 22:15:32 -0800

Tom, thanks, choice (b) is clearly what we intended.

Thanks, Larry 

-----Original Message-----
From: Tom Yu [mailto:[email-masked]] 
Sent: Monday, November 22, 2004 8:56 PM
To: [email-masked]
Cc: Liqiang(Larry) Zhu; [email-masked]
Subject: What is SPNEGO mechlistMIC computed over? (was Re:
SPNEGO-bis...)

>>>>> "lukeh" == Luke Howard <[email-masked]> writes:

>> 9) The computation of mechlistMIC is further clarified.

lukeh> What was the rationale for not including the tag and length of 
lukeh> the encoded MechTypeList as input to GSS_GetMIC()?

lukeh> I ask only as Heimdal presently does include the tag and length 
lukeh> when computing the mechlistMIC. I would be interested to know if 
lukeh> you surveyed other implementations.

In response to the above, and to some private email from Larry, I will
attempt to clarify the nature of the confusion.  Fundamentally, the
confusion results from imprecision in the terminology used by the
document for referring to details of ASN.1 encodings.

I apologize for the length of this reply, as I include some necessary
tutorial information about ASN.1 encoding rules and about certain
ASN.1 concepts.

The draft-zhu-spnego-2478bis-01 document has:

    4.1  Mechanism Types

[...]

           MechType ::= OBJECT IDENTIFIER

[...]

           MechTypeList ::= SEQUENCE OF MechType

[...]

    4.2.1  negTokenInit

           NegTokenInit ::= SEQUENCE {
               mechTypes       [0] MechTypeList,
               reqFlags        [1] ContextFlags  OPTIONAL,
               mechToken       [2] OCTET STRING  OPTIONAL,
               mechListMIC     [3] OCTET STRING  OPTIONAL,
               ...
           }

[...]

    5.  Processing of mechListMIC

[...]

       a) The mechlistMIC token (or simply the MIC token) is computed
          through 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 "value" portion, omitting the tag and
length, of
          the ASN.1 encoding for that field is included).

It is not very useful to speak of the encoding of a _field_ of an
ASN.1 structure in isolation from the encoding of the complete
structure.  It is only really meaningful to speak of the encoding of an
ASN.1 _type_.  This is a _very_ _important_ concept.

When the document says "input message is the mechTypes field in the
initial negotiation message", there is an ambiguity about which ASN.1
_type_ is meant.  "mechTypes" is _not_ the name of an ASN.1 type.
(Recall that case is lexically significant in ASN.1.) "mechTypes" is the
name identifying a component of a SEQUENCE type.  The _type_ of the
component named "mechTypes" is "[0] MechTypeList".  What might be meant
instead is that the MIC must be computed over the encoding of the type
"MechTypeList" rather than over the encoding of the type "[0]
MechTypeList".

Additionally, X.690 describes BER encodings as consisting of "identifier
octets", "length octets", and "contents octets".  The word "value" is
not used to refer to the "contents octets", since the ASN.1
specifications typically use the word "value" to refer to the _abstract_
value of a type, which is an _input_ to the encoding process.

The initial fragment of a NegTokenInit would look like:

(with each level of contents indented, and where "nn" are some length
encodings, possibly longer than one octet each)

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 -- { 1 2 840 113554 1 2 2 }

         -- ... other OBJECT IDENTIFIER values ...

Which of the following does the document mean for the MIC to be computed
over?

(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 ...

    This is probably what is actually intended, as it makes very
    little sense to encode the additional tag for MIC purposes.

(c) Only the _contents_ of type "MechTypeList", i.e.:

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

    noting that the encoding is no longer self-delimiting without the
    id+length octets for the surrounding SEQUENCE encoding (which in
    my opinion is a _bad_ idea)

(d) Something else entirely?

For some reason, I get the strange feeling that we've had this
discussion before.

---Tom

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

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 23 Nov 2004 07:58:29 -0500

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