[squid-users] Uncomplete Negotiate negotiation with Kerberos

[Emmanuel Coirier]

Hi Amos and others,

Thanks for your response, but I'm afraid I'm not sure to have understood everything...

> De : squid-users [mailto:squid-users-bounces at lists.squid-cache.org] De la part 
> de Amos Jeffries

> > When a browser wants to connect to some random HTTP website, it sends a GET 
...
> to be used.
> > 
> 
> That is not true. RFC 4559 section 4
> (<https://tools.ietf.org/html/rfc4559#section-4>) defines how Negotiate scheme 
> operates in HTTP.

Ok

> > The problem is that it enables some potentially Man in the Middle 
> > attack (since any malicious proxy where the traffic is diverted could 
> > then answers back without the client knowing it talks to a malicious 
> > proxy)
> 
> Quite the opposite. The MITM issue you point out is part of the fundamental 
> design of the Negotiate scheme and exists for both Squid-3 and Squid-4 
> behaviours.

Are you telling me that the Negotiate scheme is fundamentally flawed ?
 
> Having the client use a token provided in-channel from the proxy enables an MITM 
> observing that channel to inject changes giving itself control over what the 
> client does in future authentication. This extra control point is prohibited by 

I don't understand this point. If we hypothesize that the proxy sends the tokens (including the last one) generated by the service gssapi back to the client (whatever the means), we can think that the gssapi tokens going from service to client are authenticated and encrypted.

With Kerberos, it is possible since the client previously sends a service ticket which contains a random session key encrypted with the service key. The service can use this session key to authentify its response to the client.

So it is harder for a MITM to fake this last gssapi token, especially if the client wait for it. So I don't see how a MITM could exploit this last token.

Clearly, the http body response could be altered, but it can also be altered in the current situation.

Or, is it right that a client cannot trust any form of service authentication based on Negotiate since it is fundamentally flawed ? And thus this last token has no use ?

> the Squid-4 behaviour, and has never been a formal part of Negotiate scheme as 
> you can see from the RFC 4559 texts.
> 
> The design of Negotiate/Kerberos has both client and proxy independently contact 
> the DC to respectively generate and verify the tokens. All token operations are 

In my undestanding and experiments of Kerberos, the service (here Squid and more precisely its negotiate_kerberos_auth) doesn't contact anything, but only trusts the admin provided keytab (which is just the service key). This service key decrypts a service ticket provided by the client, and if this ticket is fine, the client is authenticated. But it doesn't imply any communication with some KDC (Heimdal for my case) or DC (Or is Microsft Kerberos implementation working differently ?). This has been tested with a KDC shut off when surfing once the service ticket was retrieved.

The client contacts the KDC from time to time to get a service ticket, but it's far less than for each TCP connection.

> performed by the DC itself and contain secrets only the DC knows. The flow of 
> tokens is exclusively from client to proxy as proof that the client is already 
> authenticated with the DC. The proxy / server response is intentionally lacking 
> to starve any MITM of information it might use to reliably affect changes to the 
> client tokens.

This is the point I don't understand. Could you tell me more ?

Thanks

-- 
Emmanuel Coirier