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