Subject: [kitten] CAMMAC review comments

From: Greg Hudson <[email-masked]>
Date: Wed, 23 Jul 2014 13:28:36 -0400

Shawn asked for more review of the CAMMAC draft.  Here are my comments.
All but one is a minor wording issue, and none of them are intended to
be blocking.

* "The svc-verifier element of the CAMMAC is equivalent to the
   ad-checksum element of AD-KDC-ISSUED" is true in the sense that
   svc-verifier has the same functional and security properties as
   ad-checksum, but is false in the sense of being precisely equivalent.
   svc-verifier uses the ticket encryption key, while ad-checksum uses
   the session key(*).

* "The KDC thus avoids recomputing all of the authorization data" seems
  vague.  I suggest adding "... for the issued ticket."

* "A Verifier-MAC where the key is that of the local Ticket-Granting
  Service (TGS)" is phrased as if the local TGS only has one key.
  "... where the key is a long-term key of the local..." would be more
  correct.

* "... and it is very difficult to have two such authorization data
  types coexist" would be more correctly phrased as "and it is very
  difficult for two such authorization data types to coexist."  It also
  might be worth mentioning the non-standard authdata type we're
  thinking of (SignedPath) instead of just asserting that one exists.

* Right now kdc-verifier is mandatory and svc-verifier is optional.  I
  can foresee situations where kdc-verifier isn't needed:

  - If the KDC knows that all KDCs in its realm implement AD-CAMMAC, and
    therefore will filter out CAMMACs from authdata requested by
    clients, then it doesn't need any verifier at all for local TGTs.

  - If the KDC knows that the target service does not or cannot use
    S4U2Proxy, then it doesn't need to include a kdc-verifier.  The
    svc-verifier is sufficient for ticket modification requests (such as
    renewals) which target the same server.

  If we do decide to make kdc-verifier optional, we probably need to add
  text saying that the KDC MUST NOT re-sign CAMMAC authdata unless it
  has a kdc-verifier, except in one of the above cases: a CAMMAC in a
  local TGT with configured assumptions about the other KDCs in the
  realm, or a CAMMAC with a valid svc-verifier in a ticket modification
  request.

  It would certainly be simpler, and therefore safer, to require a
  kdc-verifier in all cases.  But ticket sizes are sometimes an issue,
  and unneeded checksums can contribute noticeably.

(*) RFC 4120 is contradictory on what key ad-checksum should use, but
all implementations use the session key as far as I know.

---

From: Tom Yu <[email-masked]>
Date: Wed, 30 Jul 2014 17:14:18 -0400

>   and unneeded checksums can contribute noticeably.

Thanks, Greg.  I think making kdc-verifier optional is a useful and
reasonable change to consider.  Does anyone else agree?

---

From: Simo Sorce <[email-masked]>
Date: Wed, 30 Jul 2014 18:45:27 -0400

> >     clients, then it doesn't need any verifier at all for local TGTs.

So here we are relying on the fact the AD data is encrypted with the
krbtgt key and therefore implicitly validated, right ?

> reasonable change to consider.  Does anyone else agree?

I think the kdc-verifier could be made optional, though I am not sure
why anyone would go through the trouble of disabling it using complex
heuristics to save a few bytes unless the CAMMAC payload is very small.

Simo.

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