Subject: [Ietf-krb-wg] Miscellaneous CAMMAC issues

From: [email-masked]
Date: Wed, 15 Feb 2012 12:54:31 -0500 (EST)

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-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 15 Feb 2012 13:10:39 -0500

>   issues during key rollovers.

Yes; I think we need to record which of a principal's keys was used
(kvno and enctype/cksumtype).

>   session key is open to other attacks, but I don't understand them.

I no longer remember what the issue was.  IIRC, there was some
disagreement between the specification and some implementations as to
whether AD-KDCISSUED should use the ticket session key or the service
key.  At least one problem with using the session key is that it is
known to the client, but as Sam points out, this shouldn't be a problem
as long as the KDC always uses fresh session keys (it should) and the
TGS doesn't use the TGT session key to validate AD-KDCISSUED in AD
contained in the incoming KDC-REQ (not in the ticket).

>   the CAMMAC.  The KDC signature is primarily needed for S4U2Proxy.

You keep saying that, but it is not true.  A service can print a ticket
for itself whenever it wants, not only when using S4U2Proxy.  A "normal"
TGS request is authenticated by a TGT, but a request to modify a ticket
is authenticated only by the ticket to be modified, which means that any
data signed by either the ticket session key or the service's long-term
key cannot be trusted by the KDC.

>   point to putting a KDC signature in a TGT's CAMMAC

Agree.

> , and a realm

Disagree; see above.

>   usage numbers for each place we're adding a checksum.

I think we've accepted that Kerberos effectively has cipher suites, and
that absent independent negotiation, the only checksum type that can
safely be used is the mandatory one for the enctype in question.  There
is the issue of multiple enctypes sharing the same sort of key, but I
think we've settled on never doing that again. :-)

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Feb 2012 13:20:42 -0500

I would prefer to use the session key rather than the long-term key.  If
the trusted service MAC covers either the KDC MAc or the service MAC we
get binding to a specific ticket anyway.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 15 Feb 2012 13:42:14 -0500

> key cannot be trusted by the KDC.

I hadn't considered renewal/validation of service tickets.  (Which is
rare, but probably not so rare that we can throw it away.)

If the KDC needs to re-sign CAMMACs during renewal/validation, then it
does need a way to verify that it originated them.  Otherwise the target
service could get the KDC to help it forge a trusted-svc-signature on
arbitrary authdata elements.

I'm not sure whether the current drafts require the CAMMAC to be
re-signed on renewal/validation.  Certainly, if the svc-signature uses
the session key and the trusted-svc-signature encompasses the
svc-signature (as Sam suggested) then re-signing would be necessary.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 15 Feb 2012 14:02:01 -0500

> rare, but probably not so rare that we can throw it away.)

The important thing is that it can be done at all.  Security can't
depend on the attacker never bothering to attack. :-)

> re-signed on renewal/validation.

Well, it'd have to be re-signed if its contents change.  And there's at
least some likelyhood it would need to be re-signed in this case if it
is anchored to the ticket.

-- Jeff

---

From: Simo Sorce <[email-masked]>
Date: Wed, 15 Feb 2012 14:41:37 -0500

>   issues during key rollovers.

Why do we need to care ?
I would think that normally the strongest available key should be used,
but if that failed the service could just as easily try all other keys
and see if one matches. Do you object to a try-and-match approach for
some reason ?

>   session key is open to other attacks, but I don't understand them.

The reason why I proposed to use the long term key is that I want to be
able to extract the CAMMAC and verify it independently. A session key
binds it to the ticket and that would require to expose the session key
if the internal validation service is separate from the receiving
service. 

>   the CAMMAC.  The KDC signature is primarily needed for S4U2Proxy.

Wouldn't it be needed also when we request a TGT for delegation ?

>   signatures in any CAMMACs.

The reason I made it not optional is that it was discussed that some
implementations unfortunately do alias all services keys to the host/
key. In these implementations the only way to validate the CAMMAC is by
creating a service on the KDC that can validate the KDC signature for
you, if you do not want to trust all services on the machine at the same
level. I guess you can make the same case that it should be optional
unless your realm is handling this specific case. But then the whole
CAMMAC is optional, is it worth adding the interpretation complexity
that making something optional introduces ?

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

Should they be called 'checksums' ?

>   (probably the realm of the ticket service).

good point.

>   it's optional is a property of how it's included in AD-CAMMAC, not

ok.

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

---

From: Simo Sorce <[email-masked]>
Date: Wed, 15 Feb 2012 14:48:14 -0500

> svc-signature (as Sam suggested) then re-signing would be necessary.

If AD-Id-ANCHOR is not modified you will need to chnge the expiration
time it stores and I think it would be reasonable to allow KDCs to
recompute AD-PAD-DATA too if they prefer. So yes, contents, changes, so
new signatures are needed, so verification is needed.
That, I think, makes the KDC checksum not optional.

Simo.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 15 Feb 2012 15:13:08 -0500

> and see if one matches. Do you object to a try-and-match approach for

1) It's inconsistent with what we do everywhere else in the protocol.
2) Depending on the algorithm, try-and-match could be _expensive_
3) You can't tell the difference between missing key and failed-cksum.

> Wouldn't it be needed also when we request a TGT for delegation ?

For a _TGT_ the KDC is the service; there's no need to do two checksums
with the same key.  But, see my comments about asking the TGS to modify
a non-TGT service ticket.

> Should they be called 'checksums' ?

Checksums computed using an RFC3961 checksum type should be called
"checksums"; that's the conventional terminology.

---

From: Simo Sorce <[email-masked]>
Date: Wed, 15 Feb 2012 15:19:56 -0500

> 3) You can't tell the difference between missing key and failed-cksum.

fair

> a non-TGT service ticket.

agreed

ok.

Simo.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Feb 2012 17:15:47 -0500

>>>>> "Simo" == Simo Sorce <[email-masked]> writes:

    Simo> The reason why I proposed to use the long term key is that I
    Simo> want to be able to extract the CAMMAC and verify it
    Simo> independently. A session key binds it to the ticket and that
    Simo> would require to expose the session key if the internal
    Simo> validation service is separate from the receiving service.

I want to strongly discourage extracting the CAMAC from the ticket.
Authorization validation should take the ap-req AD restrictions and all
AD into account.  This is particularly true in the GSS context where
you're trying to construct a name with all the appropriate name
attributes.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Feb 2012 16:22:54 -0600

> you're trying to construct a name with all the appropriate name

I agree.

The PAD will likely be the dominant item in terms of data size, so if
size is the issue, then I don't see the issue.

The other possible issue (that I can think of) driving Simo to pass
around a PAD sans Ticket would be mechanism-independence.  If this is
the case then what I recommend is that Simo use GSS exported composite
name tokens to pass around the PAD.  This makes it possible to use the
PAD without being too bound to Kerberos.  Or if that is not feasible
for whatever reason then I recommend that Simo pass around {PAD,
<mechanism-specific validation data>}, where the latter item is the
remainder of the Ticket in the Kerberos case.

Nico

---

From: Simo Sorce <[email-masked]>
Date: Wed, 15 Feb 2012 23:24:35 -0500

> you're trying to construct a name with all the appropriate name

Can you explain why you want to discourage that ?

Simo.