What is the interaction for Kerberos in a proxy environment?

[Simo Sorce]

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