Hi, I'm trying to figure out the security implications for the S4U2 extension.
Section 5.1 of MS-SFU wisely states: "The S4U2proxy extension allows a service to obtain a service ticket to a second service on behalf of a user. When combined with S4U2self, this allows the first service to impersonate any user principal while accessing the second service. This gives any service allowed access to the S4U2proxy extension a degree of power similar to that of the KDC itself. This implies that each of the services allowed to invoke this extension should be protected nearly as strongly as the KDC and should be limited to those that the implementer knows to have correct behavior." However, needing to protect "service 1" as strongly as the KDC is (AFAICS) not really desirable in most scenarios. So what's really the issue here is that if the KDC trusts service1 to always tell the truth when it uses S4U2proxy and says "I've just authenticated user X, give me a service ticket for X to service2", then a compromise of the service1 server would gain access to any service service1 is allowed to delegate to - right? And to protect against this the KDC has to check some part of the service-ticket for X to service1 to be authentic and not forged by service1. On windows this is done by checking the PAC and on MIT/Heimdal it can be done by checking KRB5SignedPathPrincipals as described in http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation - right? But this requires an authentic service ticket for service1 actually issued to X based on the real TGT of X and not one that service1 just got issued based on PA-FOR-USER - right? If service1 could just do a S4U2self request with PA-FOR-USER and get a ticket with a properly signed PAC/KRB5SignedPathPrincipals, then anyone compromising service1 could impersonate any user to other services that service1 could delegate to. So this makes we wonder - what's the use of PA-FOR-USER anyway, if it doesn't at least do something to prove that service1 actually did authenticate the user? If the intent is that you should be able to authenticate to service1 in a non-kerberos way and then backend services would still be able to use kerberos, when why does the S4U2self req. not contain any options to actually prove that the named user has been authenticated, like - in the most simple case, like HTTP Basic Auth - just embed the user/pass in the PA data send along with the S4U2self req. ? If you already have a service using something like HTTP Basic auth, then any one compromising that service would have access to the passwords of users logging in anyway, so this would AFAICS only improve security for users not logging in after the compromise. I might have overlooked something, but it seems to me that allowing services to do S4U2self with only PA-FOR-USER is practically useless unless you want to extend the strong protection of the KDC to thoses services. /Peter ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
