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
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
