Re: Miscellaneous CAMMAC issues

On Wed, 2012-02-15 at 12:54 -0500, [email protected] wrote:
> 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.

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 ?

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

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

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

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 ?

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

Should they be called 'checksums' ?

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

good point.

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

ok.

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

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