[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