[kitten] Verified authorization data

Simo Sorce simo at redhat.com
Thu Jun 12 09:50:04 EDT 2014


On Thu, 2014-06-12 at 15:38 +0200, Peter Mogensen wrote:
> On 2014-06-12 15:23, Simo Sorce wrote:
> > The idea is to compute MAC on:
> >
> > 1) EncTicketPart w/o any Authorization Data (otherwise chicken-egg as
> > you are still computing AD data, CAMMAC is AD data itself)
> > +
> > 2) AD Data contained in CAMMAC (we want to protect data within the
> > CAMMAC, anything outside of it is not our business).
> >
> > Makes sense ?
> 
> Yes. And that's also the way I've read the draft and which is the basis 
> for what I wrote.
> 
> So, do you agree that the chicken-egg problem in 1) would also have been 
> solved if the kdc-verifier were placed in the ticket outside of the 
> EncTicketPart?
> 
> Are you saying that computing EncTicketPart w/o any Authorization Data + 
> computing the final EncTicketPart is simpler than just computing the 
> final EncTicketPart?
> 
> And is it correct that even though AD not in the CAMMAC is not our 
> business it doesn't make much difference whether it's included in the 
> kdc-verifier, since it can only be verified having that specific ticket 
> anyway?
> 
> In an ideal world I would have considered placing the kdc-verifier 
> outside of EncTicketPart more intutive.
> 
> Anyway... I guess my primary grief is not the kdc-verifier, but the 
> svc-verifier and that just adding a small piece of data in AD-CAMMAC to 
> a ticket will increase its size from 400-500 bytes (AFAIR) to >600. 
> About 20%. That's a problem if you try to squeeze several tickets into 1 
> IP packet. ... and it seems like only necessary because of the rule that 
> the client can add anything to authorization-data. Otherwise the data 
> would already have been protected by the service-key once.

We have to work within the framework of RFC 4120 I am afraid, so it is
what it is.

Simo.

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



More information about the krbdev mailing list