Subject: [kitten] I-D Action: draft-ietf-kitten-cammac-02.txt

From: [email-masked]
Date: Mon, 09 Mar 2015 15:59:24 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

        Title           : Kerberos Authorization Data Container Authenticated by Multiple MACs
        Authors         : Simo Sorce
                          Tom Yu
                          Thomas Hardjono
	Filename        : draft-ietf-kitten-cammac-02.txt
	Pages           : 10
	Date            : 2015-03-09

Abstract:
   This document specifies a Kerberos Authorization Data container that
   supersedes AD-KDC-ISSUED.  It allows for multiple Message
   Authentication Codes (MACs) or signatures to authenticate the
   contained Authorization Data elements.  The multiple MACs are needed
   to mitigate shortcomings in the existing AD-KDC-ISSUED container.
   This document updates RFC 4120.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-cammac/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-kitten-cammac-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Greg Hudson <[email-masked]>
Date: Mon, 09 Mar 2015 21:05:04 -0400

> http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-cammac-02

I'm not sure the new wording is quite right.  The new draft contains:

   A KDC SHOULD only make verbatim copies of CAMMAC contents to a new	
   CAMMAC when it has authenticated the CAMMAC as originating from a	
   local realm KDC [...]

   When a KDC makes verbatim copies of CAMMAC contents to a new CAMMAC	
   without having authenticated the first CAMMAC as originating from a	
   local realm KDC, it SHOULD NOT apply a kdc-verifier to the new	
   CAMMAC.

The first recommendation doesn't contain an exception for ticket
modification requests, where it is safe to copy a CAMMAC with only an
svc-verifier as long as the new CAMMAC also contains only an
svc-verifier.  The second recommendation is confusing because it seems
to apply only to a situation where the KDC is already violating the
first SHOULD.

   One possible exception is when a realm's policy allows a KDC	
   to make a verbatim copy of CAMMAC contents from a cross-realm TGT	
   from designated "fully-trusted" remote realms.  The local realm KDC	
   can safely apply a kdc-verifier to a new CAMMAC based on the cross-	
   realm TGT, because the client realm name in the resulting new ticket	
   will be that of the remote realm.  The presence of a remote client	
   realm name allows the local realm KDC to identify the originator of	
   the CAMMAC contents as being a remote realm.

I agree with the first sentence but not the other two.  I don't think
the client principal communicates the origin of all CAMMAC assertions.
For example, the authorization data in a CAMMAC might assert something
like "this client principal is a member of the wheel group," where the
client principal is in a foreign realm and "wheel" is in a group
namespace applying to the server realm.  Such an assertion should
hopefully come from, or be explicitly vetted by, the server realm's KDC,
not the foreign client realm.  The KDC might have a policy which says
that the foreign realm is higher-privilege and uses the same group
namespace, but that would be a deliberate decision to trust the foreign
realm, not a safe decision based on how the resulting CAMMAC will be
interpreted.

Also, a typo: "KDCM AY" should be "KDC MAY".

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Mar 2015 17:24:06 -0400 (EDT)

> to apply only to a situation where the KDC is already violating the

I'm not sure that we need to be in the business of saying when the KDC
SHOULD make verbatim copies at all.

What if we instead come at it from something along these lines:

========

The presence of a CAMMAC in a ticket indicates that the contents of the
CAMMAC have been validated and are certified by the KDC.  During TGS
processing, this validation may take the place of merely checking that the
existing CAMMAC was issued by a KDC in the local realm; this is the case
when any of the criteria below are true.  In this case the KDC just makes
a verbatim copy of the existing CAMMAC with no validation other than the
issuer validation.

[include 1, 2, and 3 from the -02]

This validation can also take the place of confirming that a foreign-realm
KDC has issued the existing CAMMAC in a cross-realm TGT.  Local policy may
grant certain foreign realms privileged status and allow verbatim copying
of CAMMACs issued by KDCs from those realms.  In other cases, local policy
may require filtering of the CAMMAC contents (e.g., to remove group
membership information) from cross-realm TGTs issued by foreign-realm
KDCs.  The nature of such filtering is entirely a matter of local policy.

The validation can also take the place of ensuring that the scope of the
generated CAMAMC is limited to the same or narrower scope than the entity
which generated the existing CAMMAC.  This is the case for a CAMMAC
containing a svc-verifier but no kdc-verifier, when the target service of
the containing ticket does not use the S4U2Proxy extension or realm policy
disallows the use of S4U2Proxy by that service, because the only entity
other than the KDC which could have generated the existing CAMMAC is that
target service, and the generated CAMMAC would only be usable by that same
target service.  It is safe to make a verbatim copy of the CAMMAC and
generate a new svc-verifier, but no kdc-verifier.  Note that in this
situation, adding a kdc-verifier to the generated CAMMAC would increase
the scope of the certification, since the kdc-verifier certifies that the
CAMMAC was validated by the KDC, but the input CAMMAC could have been
generated by the target service.  A kdc-verifier MUST NOT be included in
the generated CAMMAC in this case, in the absence of explicit policy
configuration (such as for cross-realm TGTs).

========

We would probably still need to say something about omitting the
kdc-verifier when all the KDCs in the local realm filter out
client-submitted CAMMACs.

-Ben