Re: [kitten] Verified authorization data

[Simo Sorce <[e-mail]>]

On Thu, 2014-06-12 at 14:55 +0200, Peter Mogensen wrote:
> On 2014-06-12 14:47, Simo Sorce wrote:
> > On Thu, 2014-06-12 at 09:12 +0200, Peter Mogensen wrote:
> >> Sure... any solution to the S4U2proxy use case would require protecting
> >> the ticket and attached authdata, which the KDC has to trust against
> >> service tampering.
> >
> > Sorry, no, the binding to the specific ticket is not a requirement for
> > s4u2proxy. The only requirement there is the KDC MAC which could be done
> > the same way as the SVC MAC.
> 
> 
> Doesn't that depend on what any authdata plugin at the KDC might need to 
> do with any authdata in the evidence ticket when processing the 
> S4U2proxy TGS?

Yes, but we could as well have added just the principal name and the
expiration time of the authdata owner as an AD inside the CAMMAC, and
that was considered. But in the end we found more useful to just add all
the data from EncTicketPart as it included all the above and
additionally bind to the ticket.

> Such authdata in the evidence ticket could be something which the KDC 
> would be in a position to verify in the principal database and issue a 
> fresh copy.

Yes there are plans see the old draft about PAD which we put on hold
until CAMMAC was ready, that is an example of what you say.

> But it could also be that the KDC had to trust the authdata in the 
> evidence ticket at copy that information into the issued ticket.
> In that case, you would need to protect against a service inserting 
> authdata from another ticket into the evidence ticket.

Yes, we decided to combine this protection with ticket binding in one
single operation by using EncTicketPart in the MAC calculation, makign
the CAMMAC *simpler* to build.

Simo.

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