Re: CAMMAC extensibility options

On Wed, 2012-02-15 at 13:14 -0500, [email protected] wrote:
> 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.

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 {
  verifiers  [0] SEQUENCE OF CAMMACVerifier,
  elements   [1] AuthorizationData
}

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

_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg