Miscellaneous CAMMAC issues

Here are some issues we didn't have time to discuss in the interim
meeting, in descending order of importance:

* Phrases like "the krbtgt key" and "the service long term key" are
  imprecise, since principals in a KDB have multiple keys.

  We can either add kvno and enctype fields to identify which key
  (these would be present in an EncryptedData but are not present in a
  Checksum), or we can specify algorithmically how a key should be
  chosen from a {kvno,enctype}->key map.  The latter presents some
  issues during key rollovers.

* The svc-signature is specified as using the service long-term key.
  AD-KDCISSUED uses the ticket session key.  Using the session key
  means the receiving service can verify that the KDC produced the
  AD-CAMMAC for that particular ticket, and not just for that service.
  (But the same guarantee would not be available to the "trusted
  service," so maybe we need another way to ensure that anyway.)
  jhutz has mentioned a couple of times that he thinks using the
  session key is open to other attacks, but I don't understand them.

* The justification for the existence of the KDC signature is invalid.
  In a TGS request, the service of the presented ticket is the realm's
  krbtgt service, so the svc-signature is be sufficient to validate
  the CAMMAC.  The KDC signature is primarily needed for S4U2Proxy.

* The KDC signature should probably be optional.  There's never a
  point to putting a KDC signature in a TGT's CAMMAC, and a realm
  which has no interest in supporting S4U2Proxy doesn't need KDC
  signatures in any CAMMACs.

* Where the draft says "checksum type TBD," it's normal practice to
  use the mandatory checksum type of the key being used.  (I would
  argue that this ought to be a MUST, although Sam has disagreed with
  me about that in the past.)  However, we also need to assign key
  usage numbers for each place we're adding a checksum.

* The draft probably should move away from calling MACs signatures.

* Section 3 uses the phrase "a receiving client".  I believe RFC 4120
  calls this a server.

* OPT-Checksum includes a PrincipalName.  The RFC 4120 PrincipalName
  does not include a realm.  Maybe this is intended; if so, the draft
  should be explicit about what realm the trusted service is in
  (probably the realm of the ticket service).

* The ASN.1 identifier OPT-Checksum seems a little off; the fact that
  it's optional is a property of how it's included in AD-CAMMAC, not
  what it is.
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg