A question about S4U2Self with MIT KDC

[Isaac Boukris]

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?