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