Subject: [Ietf-krb-wg] CAMMAC extensibility options

From: [email-masked]
Date: Wed, 15 Feb 2012 13:14:25 -0500 (EST)

With the pubkey-signature field removed, AD-CAMMAC looks like:

    AD-CAMMAC                   ::= SEQUENCE {
          kdc-signature         [0] Checksum,
          svc-signature         [1] Checksum,
          trusted-svc-signature [2] OPT-Checksum OPTIONAL,
          elements              [3] AuthorizationData
    }

In the interim meeting, we determined that we want to be able to add
new verifiers somehow.  Here are the basic options I can see:

1. Put a ", ..." at the end of that sequence.  Then we can add new
fields through standards action, one at a time.

Aesthetically, it's a little weird to have some verifiers before the
elements and some after, so maybe we'd move the elements to the front.

2. Tom raised the preference that we have verifiers (including ones
added later) before elements, so that one could compute the checksums
over the elements in one pass over the DER encoding.  I can't really
conceive of a scenario where someone would want streamy processing of
authorization data, but if this is a requirement, we would need
something like:

    AD-CAMMAC                   ::= SEQUENCE {
          verifiers             [0] CAMMACVerifiers,
          elements              [1] AuthorizationData
    }

    CAMMACVerifiers             ::= SEQUENCE {
          kdc-signature         [0] Checksum,
          svc-signature         [1] Checksum,
          trusted-svc-signature [2] OPT-Checksum OPTIONAL,
          ...
    }

3. Simo and Tom both raised the idea of creating a number space of
verifier types, which might result in something like like:

    AD-CAMMAC                   ::= SEQUENCE {
          verifiers             [0] SEQUENCE OF CAMMACVerifier,
          elements              [1] AuthorizationData
    }

    CAMMACVerifier              ::= SEQUENCE {
          verifier-type         [0] INTEGER,
          [something goes here]
    }

(kdc-signature and svc-signature might remain broken out ahead of
verifiers.)  I think it's too heavyweight to create a number space and
typed hole for this purpose, though.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Feb 2012 12:21:42 -0600

> elements and some after, so maybe we'd move the elements to the front.

You could have two extensibility markers, but yes, I'd rather not use
extensibility markers for this.

>          trusted-svc-signature [2] OPT-Checksum OPTIONAL,

I prefer this, (2).

Someone said something about needing to have a kvno field, right?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 15 Feb 2012 14:23:01 -0500

> typed hole for this purpose, though.

All of the verifiers we currently have are Checksums done with some key,
which is either the session key or the key of some principal.  However,
we are at least contemplating introducting a type of verifier which is a
public key signature, and even if we choose not to do so now, the fact
that we have suggests we might return to it in the future.  I wonder if
it isn't worth separating the notion of the type of a verifier from the
identity of its creator.  So, we'd end up with something like...

AD-CAMMAC ::= SEQUENCE {

CAMMACVerifier ::= SEQUENCE {
  verifier-type  [0] INTEGER,
  creator        [1] OCTET STRING OPTIONAL,
  data           [2] OCTET STRING
}

So for verifier-type 0, creator contains a Realm and Principal, or is
missing in the session key case.  One might later introduce type 1, in
which creator is an X.509 certificate and data is a signature.

I'm not thrilled with creating a number space that only ever contains
one or possibly two types.  But...

1) I think it's important to be able to introduce public-key.
2) If public-key signatures are used for things like CAMMACs signed by
   intermediate KDCs, then there might be an arbitrary number of them.
3) I'm not sure I like the idea of pre-determining which principals'
   keys might be used.  But then, I'm also not entirely sure I don't.

I suppose we could create a number space without creating one:

CAMMACVerifier ::= SEQUENCE {
  cksum          [0] CAMMACChecksumVerifier OPTIONAL,
  pubkey         [1] CAMMACPublicKeyVerifier OPTIONAL
}

CAMMACChecksumVerifier ::= SEQUENCE {
  creator-realm  [0] Realm OPTIONAL,
  creator-princ  [1] Principal OPTIONAL,
  kvno           [2] INTEGER OPTIONAL,
  cksumtype      [3] INTEGER,
  checksum       [4] Checksum
}

CAMMACPublicKeyVerifier ::= SEQUENCE {
  certificate    [0] OCTET STRING,   -- creator's X.509 cert
  signature      [1] OCTET STRING    -- something from CMS
}

-- Jeff