Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

[Simo Sorce]

On Thu, 2016-08-25 at 20:38 +0200, Rick van Rein wrote:
> Hi Simo,
> 
> >> Careful though -- constrained delegation as done by Microsoft's
> >> S4U2Self / S4U2Proxy can only be used within one realm -- because the
> >> server is supposed to confine itself to the limitations setup (but not
> >> enforced) by the client realm.  This IMHO is a severe limitation on
> >> that particular model of constrained delegation.
> >
> > Can you be more specific about what limitation you see ?
> > S4U2Proxy can be enforced (and is in the FreeIPA case at least) in the
> > target service realm.
> 
> I hope I'm pulling this from the top of my head correctly; do let me
> know if I'm wrong though...
> 
> I'm thinking of realm crossover situations, where the realms fall
> under different control, and not necessarily with full mutual trust
> in each other's machines.
> 
> Consider a client in one realm, access a service in another.  The
> client's KDC supplies a TGT with enclosed PAC, and it is up to the
> service to use this only within the client KDC's intentions.  The
> TGT however, has been provided for the service's realm, and it is
> that realm that now enforces use and misuse according to the PAC.
> In short, the client realm relies on the service realm to be
> behaving properly.

Why would the client realm care what another realm does? The other realm
can make any info up the way it wants anyway ...

> This is the gist of what I've understood.  I hope I'm not messing
> up the details in how I wrote it down.  I do remember the clear
> conclusion that S4U2Self / S4U2Proxy do not enforce Constrained
> Delegation in a manner that is suitable for realm crossover.

I do not think this is true, the main problem you have is the service
realm can only trust any authorization data information from the client
realm in a limited way, because a crossover trust is not a situation in
which you want to fully trust what the client says in general.

But you do not have to, and I do not see anything in constrained
delegation that would be invalidated by this lack of trust.

S4u2self is just about getting a ticket in the client name to yourself.
The only thing you may want to do is to prevent a service in a random
realm to perform this operation to avoid information disclosure, but
that's about it.

S4U2Proxy between services of the same realm is perfectly fine
regardless of the client realm.

Now cross-realm s4u2proxy may be a little trickier, but again, assuming
proper access control and proper validation I do not see that it can't
be used across realm trusts, even crossover trusts conceptually.
You may want to add an AD to limit it for some uses cases, and you
probably want fine grained KDC enforcement of s4u2proxy (acls in the
kdc, we have them in freeipa).

> >>> Forwarding a TGT is bad because it is unbounded impersonation.
> >> Only when the corresponding key is supplied alongside!  [I hope I'm
> >> not taking anything out of context by saying that, I'm not sure about
> >> that but will probably be corrected if I am.]
> >
> > The TGT is all you need. It gives you access to all the resources the
> > "real owner" has access to with no limitations. You do not need the long
> > term key at all (until the TGT expires of course).
> The TGT is a Ticket, holding EncryptedData.  That encrypted portion
> must be decrypted to get hold of the EncryptionKey contained in it.
> Passing a TGT verbatim does not release this information, right?

Usually you delegate the decrypted TGT, just sending around the
encrypted TGT as obtained in the AS reply would be rather useless.

> In user-to-user Kerberos, it is also possible to pass a TGT from the
> service back to the client, and the client passes that verbatim without
> being able to make heads or tails of it.  That is what I meant.  But I
> may have been nitpicking, sorry about that.

user-to-user is a different protocol, it's not delegation, so I do not
understand how it relates.

Simo.

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