S4U2 security
Peter Mogensen
apm at mutex.dk
Thu Aug 2 11:54:20 EDT 2012
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
More information about the Kerberos
mailing list