Re: Miscellaneous CAMMAC issues

On Wed, 2012-02-15 at 14:41 -0500, Simo Sorce wrote:
> 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 ?

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.


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

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.


> > * 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' ?

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




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