Subject: [abfab] An oops: we stomped on reserved RFC 4121 token types

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Nov 2013 08:46:51 -0500

We use token types 06 01 and 06 02 for initial context tokens.

However, RFC 4121 section 4.4 reserves token ID 06 01 through 06 ff in
order that you can unambiguously distinguish ASN.1 wrapped framing from
other framing.

Luke, was this an oops or was something more clever going on.

In the specific case of draft-ietf-abfab-gss-eap, section 5 requires all
our context tokens have the ASN.1 framing.  So, testing the first octet
for 06 to determine if ASN.1 framing is present is still a fine test so
long as you don't do it recursively.

  I think we have a couple options:

1) Change the token types we use.  I don't know if this is a viable
option: I need to contact the moonshot community and figure out if
people are willing to invalidate all existing deployments.  My suspicion
is There would  be moderate  to infinite push back on this.

2)  Register 06 01 and 06 02, reserve 06 00 and 06 03 through 06 ff.

I think option 2 is acceptable because  our mechanism always happens to
use ASN.1 framing.

---

From: Tom Yu <[email-masked]>
Date: Mon, 18 Nov 2013 16:43:54 -0500

> order that you can unambiguously distinguish ASN.1 wrapped framing from

RFC 4121 Section 4.4 reserves 60 00 through 60 FF.  The BER identifier
octet for "Application tag 0 (constructed)" is 0x60, not 0x06.  (0x06
would be "Universal tag 6 (primitive)", also known as "OBJECT
IDENTIFIER".)

---

From: [email-masked] (Martin Rex)
Date: Mon, 18 Nov 2013 22:54:31 +0100 (CET)

> would be "Universal tag 6 (primitive)", also known as "OBJECT

Correct.  0x60 will be the first byte of a "generic framing" as it
must be present on the initial context token as described in
rfc2743, Section 3.1  Mechanism-independent token format (bottom of page 81)

 http://tools.ietf.org/html/rfc2743#page-81

      1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that
      -- constructed form, definite length encoding follows.

The Kerberos rfc1964 gssapi mechanism decided to (re-)use that generic
framing on all context-level tokens, plus on all per-message tokens.

rfc4121 dropped the generic framing on the per-message token,
and the quoted rule (and exemption for token IDs (60 00 -- 60 ff)
is to enable a cheap heuristic to recognize whether a generic
framing is present on a Kerberos per-message token.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Nov 2013 10:00:06 -0500

Yes.
I clearly was not awake yesterday and transposed the digits.
Thanks Tom and martin for pointing that out.

If only I hadn't also been equally alert while refactoring code
yesterday morning.
I did eventually get that fixed too:-)