Subject: [kitten] Comments on draft-ietf-krb-wg-camac-08

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Jul 2014 12:23:01 -0400

Section 4:
I expect advice on whether this should be contained in ad-if-relevant
and on how an implementation that does understand this element should
process contained elements that it does not understand.

I believe this comment needs to be addressed prior to publication.

Section 5/6:

This document registers a new authorization data container but does not
provide a way to use that container.  Any authorization data designed to
fit within that container would require action from this working group
either to publish a document describing that authorization data or a
document establishing an IANA registry for authorization data.

I think that publishing a new authorization data container without a way
to legitimately use it dis not in the IETF's interest.  Either it won't
get used until we publish some document, in which case we're better off
holding off until that document is published and gaining implementation
experience with both.  Alternatively, it will get used by someone
squatting on a number, which is bad.

My recommendation is that we move the authorization data registry from
Kerberos IANA to section 6 here and remove section 5.
I feel reasonably strongly that publishing this document without either
an IETF consumer or an IANA registry is bad.

Section 7:

We only bind to the encrypted ticket part.  A KDC knows from the MAC
verification that it issued a ticket with the given encrypted part, but
has no confidence from that information what service key it encrypted
that ticket in nor the service name in the outer ticket.

How is a KDC supposed to make sure this authorization container was
issued to the service that claims to have received it.
At one level, you could argue that's a general issue with s4u and
similar.  At another level, we're introducing those mechanisms into the
IETF here, so I think we need to discuss that issue here.
we could either solve it in this document by including the principal
name to which the ticket is issued in something covered by the KDC MAC.
The obvious solution there would be to define an authorization data
element for an interested KDC to include.
Alternatively we could include an octet-string for KDC internal usage
that is covered by the MAC.

If we establish an IANA registry for authorization data types with
expert review or more liberal of a registration policy, then we could
document the issue without providing an explicit solution.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 29 Jul 2014 13:37:38 -0400

> process contained elements that it does not understand.

My preference is to:

* Advise that CAMMACs be put inside AD-IF-RELEVANT.

* Specify that authdata contained within a CAMMAC should be considered
non-critical.  (That is, you don't have to wrap everything inside a
CAMMAC in AD-IF-RELEVANT.)  RFC 4120 already does this for AD-KDC-ISSUED
(section 5.2.6.2, last paragraph), presumably under the assumption that
it is used for positive rather than negative authdata.

> provide a way to use that container.

I'm not sure I agree with your reasoning, but improving the authdata
registry would be a good thing, so I don't mind if we do what you
suggest here.

> that ticket in nor the service name in the outer ticket.

To read the CAMMAC, the KDC had to decrypt the ticket it came from using
a key for the purported service principal.  Is the concern here about
principal entries with multiple names?  I'm not sure there are any
interesting attacks here, since all of the names refer to the same
principal.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 Jul 2014 21:50:57 -0400 (EDT)

> it is used for positive rather than negative authdata.

It looks like we discussed the AD-IF-RELEVANT situation back in November, 
but the discussion fizzled out without reaching a real conclusion.
Jeff's point in 
http://www.ietf.org/mail-archive/web/kitten/current/msg04425.html that 
we're designing a generic container because the previous generic container 
wasn't good enough, so we should probably make sure this one is generic 
enough seems pretty compelling on first re-read.  On the other hand, 
Greg's reply to that message is also pretty compelling, namely, that de 
facto we cannot create any critical authdata and expect them to be 
actually treated as critical.  It would probably be good for people to 
review that thread.

-Ben

---

From: Simo Sorce <[email-masked]>
Date: Wed, 30 Jul 2014 07:46:10 -0400

> actually treated as critical.  It would probably be good for people to 

I thought we concluded that CAMMAC does not need to be wrapped in
AD-IF-RELEVANT because it has the same properties by definition and
therefore is always non critical as well, but I would not mind
specifying it has to be wrapped in AD-IF-RELEVANT for best
compatibility.

Perhaps I convinced myself we addressed the issue and then failed to
make it really explicit in the text, thanks Sam for being thorough, we
certainly need to add language similar to the AD-KDC-ISSUED text to make
it clear.

Also I do not think we need to create any specific registry with the
CAMMAC specification, the intention is that the CAMMAC can contain the
same AD data you would put in AD-IF-RELEVANT, just that the data is
"certified" by the KDC.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 30 Jul 2014 11:02:09 -0400 (EDT)

> specifying it has to be wrapped in AD-IF-RELEVANT for best

I had some memories of coming to this conclusion as well, but don't see 
anything in the list archive or meeting minutes.  Maybe it was from 
discussion on one of the krb5 development conference calls.

-Ben

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 31 Jul 2014 16:12:35 -0400

> discussion on one of the krb5 development conference calls.

Well, I'm glad my opinion today is more or less consistent with my
opinion of almost a year ago...

I think we only have two reasonable choices:

1) Accept that implementations don't treat unrecognized auth-data as
   critical and will never be fixed sufficiently well to be depended
upon,
   and give up on ever being able to have critical AD.

2) Attempt to build a protocol suite which, if implemented correctly,
allows
   a KDC or client to place critical constraints on the use of a ticket.

If we choose (1), then we should say so.  New containers such as
AD-CAMMAC should (always) be wrapped in AD-IF-RELEVANT, for
compatibility, and the data they wrap should be considered non-critical,
not as a result of the definition of the new container but because we've
given up on AD ever being critical.

If we choose (2), then being able to have authorization data which is
both critical and authenticated seems fairly important, and having
AD-CAMMAC imply non-criticality of the wrapped elements would prevent
that.  So, it shouldn't do that.  However, it seems reasonable for
AD-IF-RELEVANT(AD-CAMMAC(...)) to indicate that both the AD-CAMMAC and
everything it wraps are non-critical(*).

Regardless of which option we choose, the authorization data contained
within AD-IF-RELEVANT(AD-CAMMAC(...)) is non-critical.  In fact,
regardless of which option we choose, AD-CAMMAC does not affect the
criticality (or lack thereof) of the things it wraps.

So really, this just boils down to whether we are ready to make a
statement that Kerberos doesn't really have critical authorization data
after all.

-- Jeff

(*) Note that this is _not_ the same as AD-IF-RELEVANT implying
non-criticality for everything contained within it down to every depth.
In particular, it is possible to imagine a container which can safely
ignored in its entirety, but for which ignoring individual contained
elements produces the wrong effect.

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Jul 2014 18:00:48 -0500

We might never get around to doing anything with critical AD.  That
doesn't mean we should close the door on it.

Nico
--