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

[Rick van Rein]

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.

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

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.

-Rick