[squid-users] Uncomplete Negotiate negotiation with Kerberos

[Amos Jeffries]

On 3/10/18 3:29 AM, Emmanuel Coirier wrote:
> 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 ?

No more so than any other authentication scheme. If we assume there is
an MITM on the channel, it can as easily relay the tokens as see them.
The security in Negotiate comes from making an MITM not be able to know
anything about what secrets they hold, nor use those opaque secrets on
other connections.


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

Sorry, I was a bit tired when I wrote that and thinking only of the
Negotiate/Kerberos exchange myself.

There *MAY* be tokens going from proxy to client (eg in Negotiate/NTLM),
but they do so by extending the handshake with extra challenge messages
containing *-Authenticate headers. Not via *-Authentication-Info.


> 
> 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 client sends such ticket to the proxy, the proxy sends it to the DC.
The DC tells the proxy ("OK allow" or "no deny"). The HTTP part of
Kerberos is over with the client delivering its token to the proxy.

This lack of to-and-fro with tokens in messages is what makes
Negotiate/Kerberos significantly faster than either NTLM or Negotiate/NTLM.


> The service can use this session key to authentify its response to the client.
> 

Responses are messages. Negotiate does not authenticate any message.

The *TCP connection* is what is being authenticated by Negotiate.

A hypothetical MITM is free to alter any message contents within that
connection, so long as it can replay the Negotiate ticket which gives it
permission to open a TCP connection to the proxy.


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

What I have been trying to say is that there is no such "last GSSAPI
token" in Kerberos. You are thinking of Negotiate/NTLM contexts here.

And *-Info is informational extra data, not part of the authentication
exchange process.


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

As can tokens in the HTTP headers. With the same 'but'.


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

All the tokens in Negotiate and context exchange is done with
*-Authenticate headers. Not *-Authentication-Info.

There *may* be context exchange that uses reply headers depending on the
specific context. Or there may not be. That has not changed in Squid AFAIK.


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

If that were the case there would be no need for auth_param helpers to
be configured. Squid passes tokens to the helper which handles all
contact and validation with the DC.

Once a token is validated it becomes *the* token for that TCP
connection. Any change to the token terminates that connection.


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

That is up to the client and DC settings. So far as Squid is concerned
every new TCP connection needs to be separately authenticated.
The helper informs the proxy what user label to log for that token/ticket.


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

That is about the best description I can come up with right now. It is
basic PKI key exchange, using separate side channels to the DC instead
of in-channel (HTTP) key/ticket negotiation.


Amos