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

[Rick van Rein]

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.

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

-Rick