Re: [kitten] Verified authorization data

[Simo Sorce <[e-mail]>]

On Thu, 2014-06-12 at 15:19 +0200, Peter Mogensen wrote:
> On 2014-06-12 15:01, Simo Sorce wrote:
> > 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.
> 
> I must have misunderstood something fundamental then.
> 
> The draft says:
> "the KDC computes the MAC in the kdc-
>        verifier over the ASN.1 DER encoding of the EncTicketPart of the
>        surrounding ticket, *but* where the AuthorizationData value in the
>        EncTicketPart contains the AuthorizationData value contained in
>        the CAMMAC instead of the AuthorizationData value that would
>        otherwise be present in the ticket."
> 
> (My emphasis)
> 
> So it's not the actual EncTicketPart which is used for the MAC. It's 
> another version with different AuthorizationData. You have to compute 
> both versions.
> Compared to simply just placing the kdc-verifier outside of the 
> EncTicketPart and using the actual EncTicketPart for computing the MAC.
> ... which I know can give compatability problems, but just so we 
> understand what each other is talking about.
> 
> I would intuitively think it was simpler to just sign the entire actual 
> EncTicketPart with the kdc-verifier. Of course, that will then bind to 
> also any other authdata in the ticket.

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 ?

Simo.

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