Subject: [kitten] CAMMAC ASN.1 module issues

From: Greg Hudson <[email-masked]>
Date: Sat, 25 Oct 2014 12:49:25 -0400

While working on creating test vectors for CAMMAC using asn1c, I noticed
into three issues with the ASN.1 module.  Two are just matters of form,
but the third will affect the encoding if we decide to change it.  I
believe we're at a slightly awkward stage of the workflow for this
draft, but at least we are still before IETF last call.

1. The ASN.1 module needs IMPORTS declarations for the RFC 4120 types it
uses.  I have submitted a pull request to Tom's github repository with
the necessary import statements.

2. There is no OID in the module declaration.  I don't know how
important this is in practice, but all of the other Kerberos-related
ASN.1 modules I looked at have OIDs.

3. Verifier is defined as an untagged CHOICE with just one initial
choice:

   Verifier             ::= CHOICE {
         mac            Verifier-MAC,
         ...
   }

The last time we used this kind of extensibility was PA-FX-FAST-REQUEST
in RFC 6113:

   PA-FX-FAST-REQUEST ::= CHOICE {
       armored-data [0] KrbFastArmoredReq,
       ...
   }

While armored-data has an explicit [0] context tag, Verifier's mac field
does not.  Therefore, the Verifier-MAC will appear in the DER encoding
of Verifier with just its usual sequence tag (universal 0x10).

On the positive side, the lack of a context tag here typically saves
four bytes per CAMMAC (two for each Verifier).  If we never add
additional choices to Verifier, the unused extensibility costs us
nothing on the wire; the DER encoding looks just like it would if we had
directly used Verifier-MAC within AD-CAMMAC.

But if we do add additional Verifier choices, there is an implementation
constraint.  We would likely use context tags for subsequent choices, as
it would be an ASN.1 violation to simply add another field with a
sequence type.  The ASN.1 decoder for Verifier would need to be able to
process either a context tag or universal sequence tag.  The current MIT
krb5 ASN.1 implementation can handle this (we don't make assumptions
that choices use context tags; we just match the tag we read against the
expected tag of each choice in turn), but I don't know about other
implementations.

My current preference is to leave this alone, but I wanted to make sure
it was discussed explicitly in the working group and doesn't just slip
through.  Apologies if we discussed this before.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 26 Oct 2014 17:19:06 -0400 (EDT)

> draft, but at least we are still before IETF last call.

Thanks for bringing these up.

> ASN.1 modules I looked at have OIDs.

What OID arc(s) could we use?

> through.  Apologies if we discussed this before.

Do we have any data about whether the Heimdal and Microsoft decoders could
handle this situation?

It would feel aesthetically unclean to end up in a future situation where
a CHOICE has one choice without a context tag and the rest do, but I am
as-yet undecided just how bad that is.

-Ben

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sun, 26 Oct 2014 14:33:08 -0700

> 26 okt 2014 kl. 14:19 skrev Benjamin Kaduk <[email-masked]>:
> 

Heimdal compiler handles this fine, the first tag/element needs to be unique though for the old c-code backend, the new template behaves like MIT (try to parse each branch of the CHOICE).

Love

---

From: Tom Yu <[email-masked]>
Date: Mon, 27 Oct 2014 11:19:02 -0400

> as-yet undecided just how bad that is.

I think we might have talked about this, but am not certain.  I think
omitting a context tag on the first branch of the CHOICE is probably
harmless and saves some bytes in the encoding in the common case.

---

From: Tom Yu <[email-masked]>
Date: Mon, 27 Oct 2014 17:02:25 -0400

> the necessary import statements.

Thanks.  I'll incorporate this in the next revision, if the chairs think
it's acceptable to make this change at this point in the process.

> ASN.1 modules I looked at have OIDs.

I think it varies; if the specification provides an ASN.1 module (as
opposed to a fragment of a module), it seems that there is often a
module OID.  Interestingly enough, the RFC 6113 module OID conflicts
with the OID of the module that I'm using to register OIDs under the
IETF KerberosV5 arc, so I would want to check for other potential
conflicts before assigning an OID to the module for CAMMAC.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Oct 2014 17:43:24 -0400 (EDT)

> it's acceptable to make this change at this point in the process.

Please go ahead.

> conflicts before assigning an OID to the module for CAMMAC.

Thanks for doing the investigation.

-Ben

---

From: Tom Yu <[email-masked]>
Date: Fri, 31 Oct 2014 15:54:22 -0400

> ASN.1 modules I looked at have OIDs.

http://oid-info.com/get/1.3.6.1.5.2.4

shows several conflicts and squats.  It seems that maybe 7 is the next
unused one?  What do people think?

---

From: Greg Hudson <[email-masked]>
Date: Sat, 01 Nov 2014 00:25:19 -0400

> unused one?  What do people think?

I agree that 1.3.6.1.5.2.4.7 looks unused, based on that page and some
Google searches.