Re: Miscellaneous CAMMAC issues

On Wed, 2012-02-15 at 12:54 -0500, [email protected] wrote:

>   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.

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


> * 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.

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 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.

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.


> * The KDC signature should probably be optional.  There's never a
>   point to putting a KDC signature in a TGT's CAMMAC

Agree.



> , and a realm
>   which has no interest in supporting S4U2Proxy doesn't need KDC
>   signatures in any CAMMACs.

Disagree; see above.


> * 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.

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. :-)



_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg