Re: Constrained Delegation and PAC : Realm crossover
Hi Simo / others, >>> What I'm left wondering is, if the client's KDC knows what delegations >>> are permitted, as is the case with FreeIPA, is it not simpler to pass on >>> the additional tickets for smtp/ and imap/ in an AD structure in the >>> webmail ticket? >> This is a potential optimization I have been thinking about before, but >> requires clients that understand how to extract these tickets and put >> them in their ccache. Perfectly doable though. I worked out a solution to be configured / implemented in the client's KDC, and not needing any involvement from the client's libkrb5. It's the service that would need to unpack the credentials in the name of the client. It's not very pretty, but possible. It's easy enough to add a KRB-CRED structure into a Ticket using a new ad-type AD-BACKEND-TICKETS. These tickets can be requested by the client's KDC by producing a TGT on behalf of the client, and using that to send TGS-REQ for the backend services. This can even be done recursively (backend services have their own backend services). What I think is not pretty, is that the client's KDC must AFAIK respond with the annotated ticket falling under its own realm [1]. So a service ticket is obtained by the client's KDC and renamed to one under the client's realm. The client will not see the service's realm, because the KDC renames the ticket. The server must then re-rename the ticket to its own realm before it can do its local keytab lookup. [1] or it might first redirect, but not to the service's realm, as that is not to be trusted in general. Still, it's better than sending over a FORWARDED TGT plus its session key as is done with S4U2Proxy. This approach offers much more control, and requires no client changes. Only the KDC and service must be setup to match each other's expectations. -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Constrained Delegation and PAC : Realm crossover
Hi Simo, > I guess I need to ask you for a detailed example of a transaction to > understand what you are aiming to. Gladly, thanks :) An example of use I have in mind is a party owning a domain name, based on externally hosted components from online providers, all secured and linked together through Kerberos. The domain name may provide basic mechanisms such as web, IMAP and SMTP. The domain's KDC is either included in the domain package or taken in from an externally hosted service, or perhaps this is the one component hosted under own control (maybe using a dedicated Raspberry Pi distribution). To assert his online identity, the domain owner can take in externally hosted services like XMPP and SIP. And a Kerberos-protected WebMail may be taken in because of its user interface. This WebMail service is interesting, because it requires access to IMAP and SMTP. Since this WebMail is an external service, it should not be permitted more access than what it needs to function though. I am wondering if constrained delegation can help the domain's clients to safely use the external WebMail service, with constrained delegation to limit the access from WebMail to IMAP and SMTP and nothing more. Sorry if I'm not very good at reverse-engineering the security architecture from the MS-SFU, -KILE and -PAC documentation. I also didn't find a HOWTO-styled instruction for this facility with an open source Kerberos. Thanks! -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Constrained Delegation and PAC : Realm crossover
Hi, > There are 2 different approaches for Constrained Delegation, one where > Access control is applied at the KDC level, and one that relies on the > receiving service to apply access control. > > When using an MS-PAC you have an AD element that tells you whether the > ticket is the result of delegations, or is a ticket that has been > release directly to the owner of the TGT. > > So services can always check that. > > In FreeIPA however we added actual access control, so that service > HTTP/webmail.example.com can be allowed to only ever get delegated > tickets for imap/imap.example.net and nothing else. > That's what I was hoping to find, indeed. > It's up to the imap service admins and the EXAMPLE.NET KDC admins to > decide what to use and what to enforce. > What I'm left wondering is, if the client's KDC knows what delegations are permitted, as is the case with FreeIPA, is it not simpler to pass on the additional tickets for smtp/ and imap/ in an AD structure in the webmail ticket? This might even work recursively, that is if imap/ needed further privileges to afs/ or so. I wouldn't want smtp/ to get to that ticket but imap/ should. I must still be missing why S4U2Proxy works the way it does. It may be that it was designed with more flexibility in mind though, that probably suits the mindset of its inventors. > (it seem you sent this to me privately, was that intentional ? If not > feel free to forward my reply to the list on reply, if needed) > Not intended. I've resent my message, and am now forwarding your full comments inline to the list. Thanks for your explanations, Simo! -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Constrained Delegation and PAC : Realm crossover
On 20/10/15 05:03, Rick van Rein wrote: > Hi, > > >> There are 2 different approaches for Constrained Delegation, one where >> Access control is applied at the KDC level, and one that relies on the >> receiving service to apply access control. >> >> When using an MS-PAC you have an AD element that tells you whether the >> ticket is the result of delegations, or is a ticket that has been >> release directly to the owner of the TGT. >> >> So services can always check that. >> >> In FreeIPA however we added actual access control, so that service >> HTTP/webmail.example.com can be allowed to only ever get delegated >> tickets for imap/imap.example.net and nothing else. >> > That's what I was hoping to find, indeed. > >> It's up to the imap service admins and the EXAMPLE.NET KDC admins to >> decide what to use and what to enforce. >> > What I'm left wondering is, if the client's KDC knows what delegations > are permitted, as is the case with FreeIPA, is it not simpler to pass on > the additional tickets for smtp/ and imap/ in an AD structure in the > webmail ticket? This is a potential optimization I have been thinking about before, but requires clients that understand how to extract these tickets and put them in their ccache. Perfectly doable though. > This might even work recursively, that is if imap/ > needed further privileges to afs/ or so. I wouldn't want smtp/ to get > to that ticket but imap/ should. > > I must still be missing why S4U2Proxy works the way it does. It may be > that it was designed with more flexibility in mind though, that probably > suits the mindset of its inventors. S4U2Proxy is built this way because in the Microsoft implementation it is the receiving service that enforces access control. IIRC the KDC does not, it just either always allow proxy for any target or for none. >> (it seem you sent this to me privately, was that intentional ? If not >> feel free to forward my reply to the list on reply, if needed) >> > Not intended. I've resent my message, and am now forwarding your full > comments inline to the list. > > Thanks for your explanations, Simo! > > > > -Rick > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Constrained Delegation and PAC : Realm crossover
Hi, >> What I'm left wondering is, if the client's KDC knows what delegations >> are permitted, as is the case with FreeIPA, is it not simpler to pass on >> the additional tickets for smtp/ and imap/ in an AD structure in the >> webmail ticket? > > This is a potential optimization I have been thinking about before, but > requires clients that understand how to extract these tickets and put > them in their ccache. Perfectly doable though. I'm wondering about this for the design of TLS-KDH. I have a couple of flags in mind that request for ticket properties, and I'm wondering if S4U2Proxy should be added as a flag. S4U2Proxy is not an IETF standard, another is that it also lacks a number of quality signs -- such as exchangeable ciphers, portability and I have security concerns about concatenating strings without separator marks. So my tendency is not to specify such a flag (but leave it open for extensions by others) in TLS-KDH, but instead consider having a flag to request this ticket-carrying AD. That is a New Thing, but at least it is absolutely clear and downright simple. Especially if the AD contains the standardised KRB-CRED message; the MIT krb5 API has krb5_rd_cred() to easily decode that, and I assume Heimdal has something similar. Do tell me if I'm thinking silly thoughts :) >> I must still be missing why S4U2Proxy works the way it does. It may be >> that it was designed with more flexibility in mind though, that probably >> suits the mindset of its inventors. > > S4U2Proxy is built this way because in the Microsoft implementation it > is the receiving service that enforces access control. IIRC the KDC does > not, it just either always allow proxy for any target or for none. Yes, that also matches with what the S4U2Self approach does; it also grabs control based on things that scare me. I suppose the implicit assumption is that it functions within a realm, which makes it less usable for more general use when TLS-KDH gets to crossover to foreign realms. Thanks, -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Constrained Delegation and PAC : Realm crossover
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
Re: Constrained Delegation and PAC : Realm crossover
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
Re: Constrained Delegation and PAC : Realm crossover
On 15/10/15 08:00, Rick van Rein wrote: > Hello, > > Does anyone on this list have S4U2Proxy or "Constrained Delegation" > experience? Yes > 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. > 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. > The client provides a Forwarded TGT along with the session key on it, so > I presume it is the client's KDC who applies policy (to avoid that a > webmail service uses more than imap and smtp backend services). Both KDCs are involved. > Don't worry about pointing me to specs (or sections therein) if I missed > the hints. Since I don't use Windows I'm already getting at this from > the "outside", reading specs, but it's not easy to see the whole picture. Documetns you may want to read: MS-KILE: https://msdn.microsoft.com/en-us/library/cc233855.aspx MS-PAC: https://msdn.microsoft.com/en-us/library/cc237917.aspx -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
