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

[Simo Sorce]

On Thu, 2016-08-25 at 01:09 +0200, Rick van Rein wrote:
> Hey,
> 
> >> To be clear, the whole point of what I'm proposing is that the
> client
> >> would have ZERO dependencies. Being able to do proper auth and then
> >> get a TLS session that uses the crypto context established during
> auth
> >> instead of traditional certificate would be a big deal.
> 
> The general idea of IAKERB is that client-KDC traffic can travel over
> an unprotected link, which might involve the server.  It is still
> important however, to have the long-term secret (the "password")
> established between client and KDC to base the trust on.  That is not
> the pre-shared key scheme that I thought you were heading for.
> 
> >> I don't see why giving the server access to the TGT would be any
> >> different from delegation. It could be "constrained" to just the
> HTTP
> >> server(s), Sharepoint, or whatever stuff requires impersonation.
> >
> > Constrained delegation can be done without forwarding one's TGT.
> 
> 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.

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

Simo.

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