[prev in list] [next in list] [prev in thread] [next in thread] 

List:       krbdev
Subject:    Re: [kitten] Verified authorization data
From:       Simo Sorce <simo () redhat ! com>
Date:       2014-06-12 13:50:04
Message-ID: 1402581004.22737.39.camel () willson ! usersys ! redhat ! com
[Download RAW message or body]

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

_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
[prev in list] [next in list] [prev in thread] [next in thread]