On Wed, 2017-03-22 at 11:23 +1300, chen dong wrote: > I am not sure that my statement is right here. If I am wrong, please > correct me. > > As Kerberos protocol works atop of TCP protocol. Kerberos protocol has its > own different implementation such MIT Kerberos. And on top of Kerberos, > there is a virtual layer SASL - simple authentication and security layer, > this SASL layer can use different mechanism including Kerberos. There is a > up layer implementation called GSSAPI - generic security system API. It > also holds different mechanisms underneath including Kerberos. no sure the > relation ship between SASL and GSSAPI. > > Per my understanding about Kerberos implementation, it is all inside the > TCP. I haven't checked the implementation but I guess that Kerberos TGT is > sent by the client to the kerberized service over TCP. My question is how > does this happen in a Proxy-in-the-middle environment? How does the > kerberized service know that the Proxy-in-the-middle is trusted, and which > client the request is from? In the client side, how can the client know > where the kerberized service is and where is the Proxy-in-the-middle?
Kerberos is built to prevent Man-in-the-Middle, that said when Kerberos, via GSSAPI and SPNEGO is used in a browser does not actually normally use Channel Bindings (that is it does not bind the authentication to the outer HTTPS channel) so proxy-in-the-middle normally works. There are some setting in Windows environments to enable Channel Bindings (It's called Extended Protection for Authentication), and when that is enabled and enforced a Proxy-in-the-middle would cause authentication failures. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos