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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
