Subject: [kitten] CAMMAC and ticket server principal binding

From: Greg Hudson <[email-masked]>
Date: Fri, 08 Aug 2014 16:17:48 -0400

In the current CAMMAC draft, the KDC verifier binds the CAMMAC contents
to all the EncTicketPart fields, which includes the ticket client
principal, all of the timestamps, and the ticket session key, but not
the ticket server principal.  Sam pointed this out in
http://www.ietf.org/mail-archive/web/kitten/current/msg04774.html but I
wanted a thread to discuss the issue specifically.

With the current binding, a KDC cannot assume that the contents of a
CAMMAC originated from a KDC in a ticket issued for the claimed service.
The scope for potential tampering is narrow but extant.  Imagine that I
know the keys for two different services svc1 and svc2.  I receive a
ticket for svc1.  I can extract the CAMMAC from that ticket, then print
up a ticket for svc2 containing a CAMMAC with the same contents.  If the
new ticket uses the same session key, timestamps, and client principal,
then the kdc-verifier in the CAMMAC will appear valid to the KDC, even
though it originated in a ticket issued to svc1.  (The svc-verifier
would appear invalid if I simply copied it, but I can construct a valid
svc-verifier using my knowledge of svc2's key.)

As Sam noted, we have two options: we can add a ticket server binding,
or we can document that there isn't one.  Most of the people I have
talked to are in favor of documenting, for these reasons:

* All of the ways we could bind the ticket server add some additional
  complexity to the specification and to implementations.

* The types we have so far proposed to put inside CAMMAC only make
  statements about the client or the means of client authorization, not
  the relationship between the client and a specific service.

* The purpose of the kdc-verifier is to allow CAMMAC contents to be
  propagated to a ticket for a different service.  If the CAMMAC
  contains a hypothetical authdata type which talks about the
  relationship between the client and the old service, it would need to
  discarded or recomputed for the new service.

* A hypothetical authdata type which talks about the client-server
  relationship should probably bind to the service principal (perhaps
  just by naming it) independently of CAMMAC, in case a KDC ignorantly
  propagates it to a ticket for a different service.

Do other people have conflicting opinions?

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 15 Aug 2014 19:06:15 -0400 (EDT)

> talked to are in favor of documenting, for these reasons:
[...]
> Do other people have conflicting opinions?

[Just to get it in the archives] No; I am one of those in favor of
documenting.

-Ben

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 21 Aug 2014 20:53:19 -0400

> talked to are in favor of documenting, for these reasons:
=
>   complexity to the specification and to implementations.

It seems like it would be easy to add a binding, in the form of AD
(inside CAMMAC) containing the server name and realm.  A KDC wishing to
depend on AD making a statement about the server or client-server
relationship would need to compare the server name in the new AD element
with those in the outer part of the ticket.  Everyone else could simply
ignore the server-name AD.  Of course, one of the features of this
approach is that it can be adopted lazily, the first time a new AD type
is introduced for which such a binding is important.

>   propagated to a ticket for a different service.

Well, and also to allow the KDC to trust the CAMMAC contents in an
existing ticket for some other service (which may have been printed by
the service).

I have no objection to simply documenting the issue and moving on.

-- Jeff