A question about S4U2Self with MIT KDC

[Alexander Bokovoy]

On to, 07 helmi 2019, Isaac Boukris wrote:
> On Thu, Feb 7, 2019 at 3:41 PM Alexander Bokovoy <ab at samba.org> wrote:
> > On to, 07 helmi 2019, Isaac Boukris via samba-technical wrote:
> > > On Thu, Feb 7, 2019 at 1:49 PM Alexander Bokovoy <ab at samba.org> wrote:
> > > >
> > > > 3.2.5.1.2 is clear:
> > > >
> > > > -----
> > > >
> > > > If the KDC supports the Privilege Attribute Certificate Data Structure
> > > > [MS-PAC], the KDC, when populating the KERB_VALIDATION_INFO Structure
> > > > ([MS-KILE] section 3.3.5.6.4.1), MUST NOT include the
> > > > AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY SID ([MS-DTYP] section
> > > > 2.4.2.4) in the ExtraSids field and SHOULD add the
> > > > SERVICE_ASSERTED_IDENTITY SID ([MS-DTYP] section 2.4.2.4) instead.
> > > >
> > > > -----
> > >
> > > This doesn't say anything on verifying the original PAC.
> > It does (3.2.5, above all the cases):
> >
> > -----
> >
> > If the KDC supports the Privilege Attribute Certificate Data Structure [MS-PAC], the SFU KDC MUST
> > copy the populated fields from the PAC in the TGT to the newly created PAC and, after processing all
> > fields it supports, the SFU KDC MUST generate a new Server Signature ([MS-KILE], section
> > 3.3.5.6.4.3) and KDC Signature ([MS-KILE], section 3.3.5.6.4.4) which replace the existing signature
> > fields in the PAC, as discussed in the sections that follow.
> >
> > -----
> 
> That's the exact section I can't make sense of. It sounds like the PAC
> is copied from the TGT, processed and then re-signed. But this cannot
> possibly be true for the case I talk about (say in-realm s4u2self), as
> it would mean that we copy the authorization data of the service to
> the PAC of the impersonate principal, no?
I think we can ask the dochelp about it to clarify the language of the
spec.

-- 
/ Alexander Bokovoy