S4U2 security

[Peter Mogensen]

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