S4U2 security

Simo Sorce simo at redhat.com
Thu Aug 2 16:52:28 EDT 2012


On Thu, 2012-08-02 at 22:14 +0200, Peter Mogensen wrote:
> On 2012-08-02 21:21, Simo Sorce wrote:
> > On Thu, 2012-08-02 at 17:54 +0200, Peter Mogensen wrote:
> >> 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.
> 
> Ah yes... of course... silly me. Too simple a case.
> But then say the web server used HTTP Digest with a nonce and computed 
> hash result provided by the KDC.
> Then the password (and access to requesting TGTs) would still only be 
> shared by the user and KDC.

Then you need to have a way to share the digest with the KDC, that's not
easy.

> >
> > What you overlooked, I think, is that you are seeing s4u2self and
> > 24u2proxy used in conjunction as the main use case. It is not.
> 
> You're probably right. I saw this promoted somewhere as a way to let 
> non-kerberos client into a kerberos infrastructure.
> Men I concluded that the price of having to protect a (say) webserver as 
> strongly as the KDC was making it not that great an idea.
> 
> > 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.
> 
> Ok... makes sense.
> 
> > 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.
> 
> Yes, That was my conclusion. And it seems like to high a price to pay in 
> many scenarios.

I leave that consideration to admins.
Sometimes it is better to trust just one service with the keys to the
kingdom than to trust many clients with the same :-)

> > 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.
> >
> 
> Thanks for the explanation. I agree it's still useful.

You are welcome.
Simo.

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



More information about the Kerberos mailing list