Subject: Re: [kitten] CAMMAC open issues

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 11 Nov 2013 16:51:32 -0500

On Thu, 2013-11-07 at 10:56 -0500, Tom Yu wrote:
> Here are what I think are the remaining open issues for CAMMAC.
> 
> Wrapping of CAMMAC:
> 
> Do we recommend enclosing a CAMMAC inside an AD-IF-RELEVANT?  RFC 4120
> says that authorization data are critical, i.e., an implementaiton
> must reject unrecognized authorization data.  Alternatively, we could
> require that CAMMAC be enclosed in an AD-KDCIssued, and drop the
> consequently redundant "svc-verifier" from CAMMAC.

I fail to see how these are alternatives.  As a wrapper, AD-IF-RELEVANT
has special semantics which nullify the criticality of the element it
wraps.  AD-KDCIssued does not have this property.

-- Jeff

---

From: Greg Hudson <[email-masked]>
Date: Mon, 11 Nov 2013 17:46:15 -0500

> wraps.  AD-KDCIssued does not have this property.

My reading of RFC 4120 section 5.2.6.2 is that AD-KDCIssued authdata are
implicitly non-critical.  The text isn't as precise as I would like, but:

* "The KDC-issued ad-data field is intended to provide a means for...
positive authorization...".

* "Elements encapsulated with in the KDC-issued element MUST be ignored
by the application server if this 'signature' is not present."

* "This element and the elements it encapsulates MAY safely be ignored
by applications, application servers, and KDCs that do not implement
this element."

* Earlier in section 5.2.6, "If an unknown authorization data element
type is received by a server either in an AP-REQ or in a ticket
contained in an AP-REQ, then, unless it is encapsulated in a known
authorization data element amending the criticality of the elements it
contains, authentication MUST fail.  Authorization data is intended to
restrict the use of a ticket."

---

From: Tom Yu <[email-masked]>
Date: Mon, 11 Nov 2013 17:51:15 -0500

> wraps.  AD-KDCIssued does not have this property.

I think there is implied non-criticality of the enclosed elements (RFC
4120 5.2.6.2):

   This element and the elements it encapsulates MAY safely be ignored
   by applications, application servers, and KDCs that do not
   implement this element.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 11 Nov 2013 18:20:58 -0500

> positive authorization...".

Not relevant.

> by the application server if this 'signature' is not present."

I'm not even sure what this means, since the 'signature' is contained in
a non-optional field; if it's not present, the AD won't parse.

> by applications, application servers, and KDCs that do not implement

I somehow missed this.  In which case, yes, wrapping in AD-KDCIssued
would indeed obviate the need to wrap in AD-IF-RELEVANT.  However, that
means that wrapping in AD-KDCissued is not a substitute for using the
svc-verifier, since the former carries semantics affecting criticality.
If we drop svc-verifier, then there is no way to issue credentials
containing AD that is both authenticated and critical!

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.

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.

Incidentally, it's not clear that wrapping AD-CAMMAC in AD-IF-RELEVANT
automatically confers full non-criticality on all of the wrapped
elements!  The definition of AD-IF-RELEVANT in RFC4120 5.2.6.1 is
ambiguous in this respect.  It may be desirable to clarify that if a
particular AD-CAMMAC is wrapped in AD-IF-RELEVANT, the non-criticality
applies to all of its elements.

-- Jeff

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 11 Nov 2013 23:11:13 -0500 (EST)

>> positive authorization...".

It seems relevant in a circumstantial way, in that there is not a security 
risk from ignoring unknown positive authorization data in the way that 
there is for ignoring unknown negative authorization data.

> 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.

> 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.

> ambiguous in this respect.  It may be desirable to clarify that if a

Ugh.

-Ben

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Nov 2013 01:05:24 -0500

> 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. 

> It's not immediately clear to me why, if the contents are just an OCTET 

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.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 12 Nov 2013 08:28:00 -0500

On 11/12/2013 01:05 AM, Jeffrey Hutzelman wrote:
> short-sighted and unnecessary.

In reality, we cannot create critical authdata because some (all?)
implementations ignore unrecognized authdata in violation of RFC 4120,
so the concept of critical authdata more of a standards-process nuisance
than anything else.

We could treat CAMMAC as an opportunity to change this, but it's only a
weak opportunity.  We could trust that implementors of CAMMAC will treat
CAMMAC-wrapped authdata as critical if the CAMMAC is not itself wrapped
in an AD-IF-RELEVANT.  But unless (1) everyone implements CAMMAC, and
(2) enough time has passed that everyone has upgraded to versions
implementing CAMMAC, some implementations would still ignore
CAMMAC-wrapped supposedly-critical authdata elements.