Constrained Delegation and PAC : Realm crossover

Simo Sorce simo at redhat.com
Sun Oct 18 14:23:13 EDT 2015


On 18/10/15 04:44, Rick van Rein wrote:
> 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?

No, constrained delegation never forwards the TGT, it's the whole point 
of constrained delegation not to.

>>> 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?

I am sorry, but it is not clear to me what your intention is. In any 
case the service's KDC has full powers over what's in the MS-PAC, it can 
forge one if it wants to, but that's fine given the service's KDC is 
inherently trusted by that service.

> 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?

I guess I need to ask you for a detailed example of a transaction to 
understand what you are aiming to.

Simo.


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


More information about the Kerberos mailing list