[squid-users] Uncomplete Negotiate negotiation with Kerberos

[Amos Jeffries]

On 3/10/18 12:32 AM, Emmanuel Coirier wrote:
> Hi everybody !
> 
> Is it desirable that the Negotiate/Kerberos proxy authentication method be interrupted as soon as Squid knows the identity of the browser's user, without letting the browser authenticates Squid in response ?

That is not possible to happen. The process of authenticating finishes
by telling Squid what the username is.

> 
> When a browser wants to connect to some random HTTP website, it sends a GET request. A proxy wanting to authenticate the browser, via Kerberos, responds with 407, which lets the browser knows that it has to authenticate. Then the browser sends a Kerberos authenticator (in base64 in the Proxy-Authorization header). Then Squid *should* answer back with a Proxy-Authentication-Info letting the browser finish the Kerberos process and validating that it is communicating with the real proxy it wants to use. It is how gss-api is intended 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.

Notice two things;

 * firstly that there is no mention of *-Authentication-Info headers
anywhere in that specification.

* secondly that the auth tokens are exclusively flowing from the browser
to the server or proxy, not the other way around.




> It was the case with Squid 3.3.8, where Squid answers back, along with the response (200 OK), the Proxy-Authentication-Info header with the final token. But with Squid 4.2, the browser doesn't anymore add this headers, preventing the browser to authenticate back the proxy.
> 

Squid-4 has been updated to conform to RFC 7615 requirements of these
*-Authentication-Info headers usage which was in fact only previously
defined for use with Digest authentication scheme - not Negotiate.


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


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



...
> 
> It this behavior endorsed, or is it a bug ?
> 

The Squid-4 behaviour is "endorsed". The Squid-3 behaviour was arguably
a bug or more correctly an experimental feature which has now been
removed due to both the increased MITM risk I describe above and how its
content differs in syntax from the RFC 7615 specification.

Amos