Constrained Delegation and PAC : Realm crossover

[Rick van Rein]

Hi Simo / others,

Thanks for your reply.  I found KILE and PAC from SFU, but am having a
hard time figuring out what goes where, and whose responsibilities lie
where.  That's not really obvious from these specs :-S

>> I know that the security is based on a PAC, but it is unclear where it
>> is enforced -- in the benevolent service, or in the KDC.
>
> Can be either, however according to MS specs the KDC is vouching for the 
> contents, and can (should) apply SID filtering (for example), to remove 
> unwanted Identifiers, from another domain.

I would like a situation where the client KDC can constrain the powers
of the service, which might be running in its own realm.  That would
help to reliably use services from remote realms, including "free"
online services that I would prefer to grant only the access that it
needs to function.

AFAIK, this should be possible under S4U2Proxy, at least when we provide
the initial Kerberos credentials.

My reasoning is that the service would always need to start asking at
the client's KDC, and that this KDC may reply with a TGT or resolve the
service ticket and return it (under the client's realm).  In the latter
case, the client's KDC continues to be the only source of tickets in the
name of the client.  The client's KDC can recognise S4U2Proxy tickets
(it is FORWARDED TGT), so it is can constrain delegation.

Am I correct?
>> And, if it is the KDC, which one if client and service realms differ?
>
> The client's KDC produces it, the service's KDC inspects it, perhaps 
> changes it and then re-signs it therefore approving its use.

I'm not sure I understand this...  but AFAIK it can't impact the story
above, right?


Another design approach to the same matter: If the client's KDC has a
policy for Constrained Delegation, it can usually iterate over what
backend services underpin a frontend service --AFAIK this is true for
FreeIPA at least-- so the client's KDC could just as well supply a
service ticket with AuthorizationData carrying all the backend services
are supported, and all these certificates could be in the name of the
client.  No FORWARDED TGT required, let alone its contained session key!

I'm wondering if that angle would be a nicer one to consider for
TLS-KDH, instead of putting effort into the support of S4U2Proxy. 
Perhaps both approaches should be possible.  What do you think?

Thanks,
 -Rick