S4U2 security

[Simo Sorce]

On Thu, 2012-08-02 at 17:54 +0200, Peter Mogensen wrote:
> 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 have a username/password you can simply use them to perform an AS
request and get a user TGT, s4u2self would be useless in that case.

> 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.


What you overlooked, I think, is that you are seeing s4u2self and
24u2proxy used in conjunction as the main use case. It is not.
In general s4u2self is used on AD machines to get the user MS-PAC so
that local authorization can be done, but generally those services are
not allowed to also do s4u2proxy.
S4u2proxy should be used instead when a real user connects to a service
that need to access a 3rd service on its behalf, this is where the
evidence ticket comes in play.

Of course you can configure your realm so that a service can both do a
s4u2self operation *and* s4u2proxy operation. It would be better for you
to have proper access control in the KDC in that case in order to be
able to limit which user the service is allowed to perform s4u2self as
and which services it is allowed to get a ticket for with s4u2proxy, but
yeah such a service can basically impersonate any allowed user to any
allowed service w/o real authentication, so you better make sure it is
not compromised.

In the end s4u2proxy is generally *a lot* better than forwarding TGTs if
your KDC support ACLs as then you can limit what other services a
potentially compromised service can get access to.

s4u2self is generally best used in very trusted service or only to fetch
authorization data in the form of a MS-PAC in AD environments and not
much else.

In the end these are very useful tools, is how you use/combine them that
makes them more or less powerful and or risky.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York