Re: [kitten] CAMMAC open issues

[Jeffrey Hutzelman <[e-mail]>]

On Mon, 2013-11-11 at 23:11 -0500, Benjamin Kaduk wrote:

> > IMHO, we should simply note that most already-deployed services will not
> > understand AD-CAMMAC, and specify that it SHOULD be enclosed in
> > AD-IF-RELEVANT unless it contains authorization data which is critical
> > with respect to the service or some principal named in other-verifiers.
> 
> Do we anticipate there ever being such critical data?  It seems like it 
> would be simpler if we could specify that it is always AD-IF-RELEVANT.

We're designing a generic container that allows the KDC to send
authenticated authorization data.  It seems to me that limiting that
container to supporting only non-critical authorization data is both
short-sighted and unnecessary.  As I recall, we got here because
AD-KDCissued turned out to not be sufficient for our needs, and we
decided to build a generic signed-AD container rather than another
narrowly-scoped hard-to-reuse one. 


> > Probably we should also indicate that AD-CAMMAC-BINDING SHOULD be
> > enclosed in AD-IF-RELEVANT unless the containing AD-CAMMAC is already so
> > wrapped, and modify the text so that an AD-CAMMAC whose first element is
> > an AD-IF-RELEVANT wrapping AD-CAMMAC-BINDING is permissible.
> 
> It's not immediately clear to me why, if the contents are just an OCTET 
> STRING.

The current definition of AD-CAMMAC-BINDING requires that it be the
first element of an AD-CAMMAC, if it is present at all.  Wrapping it in
an AD-IF-RELEVANT violates that.  However, this is moot -- on further
reflection, I realize there is no reason for
AD-CAMMAC(AD-IF-RELEVANT(AD-CAMMAC-BINDING)), since any implementation
that understands AD-CAMMAC must necessarily also recognize
AD-CAMMAC-BINDING, even though non-KDCs will never make use of it.  So,
I withdraw this comment.