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

[Benjamin Kaduk]

On Thu, 25 Aug 2016, Rick van Rein wrote:

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

You probably are nitpicking, yes, but I think the relevant key is the
session key that is contained in the TGT -- only KDCs would have the key
to decrypt the EncryptedData of the TGT (as opposed to the enc-part of the
AS-REP which is where the client gets it).

I assume that Simo is using "TGT" to mean "TGT and session key", as would
be in a user's ccache, and not in the strict protocol data structure
sense.

-Ben