[tor-dev] Proposal xxx: Safe cookie authentication

[Robert Ransom]

On 2012-02-05, Damian Johnson <atagar1 at gmail.com> wrote:
>> Unlike other commands besides AUTHENTICATE
>
> AUTHENTICATE and PROTOCOLINFO
>
>> HMAC-SHA256("Tor controller-to-server cookie authenticator", CookieString)
>
> I'm more than a little green with HMAC. Does this mean that the hmac
> key is that static string, so it would be implemented like...
>
> import hmac
> cookie_file = open("/path/to/cookie")
> h = hmac.new("Tor controller-to-server cookie authenticator",
> cookie_file.read())
>
> # that second wrapper, where it looks like the above is the key
> h = hmac.new(h.hexdigest(), server_challenge_response)

Yes.  (See the line below that, which tells you which argument is the key.)

> # send to the controller
> send_to_controller(h.hexdigest())

This seems backwards.

> Also, is "HMAC-SHA256" some special hmac implementation that I need to
> look up? Is it part of the builtin python lib?

Some versions of Python include SHA256 and a generic HMAC
implementation (which can be used with SHA256) in their standard
library.

> Speaking as someone who will need to implement the controller side of
> this I'm not really sure what I'm supposed to do with this. Some
> points of clarification that are needed:
>
> 1. Is CLIENTCHALLENGE just any arbitrary client provided string used
> as a salt for the hash?

It is a nonce, used to prove that the CLIENTRESPONSE value is ‘fresh’.

> 2. The CLIENTRESPONSE is something that I validate then discard, right?

Yes.

> 3. What happens if a user issues a AUTHCHALLENGE, PROTOCOLINFO, then
> AUTHENTICATE? What about PROTOCOLINFO, AUTHCHALLENGE, AUTHENTICATE?

The former is an error; the latter is expected behaviour.

The safe cookie authentication protocol is only needed for controllers
which look at Tor's response to the PROTOCOLINFO command to decide
where to look for a cookie file.

> Personally I don't see the reason for the last handshake. The
> controller is proving that it should have access by providing the
> cookie contents. Providing both the cookie contents and
> SERVERCHALLENGE proves that we sent and received the AUTHCHALLENGE
> which isn't terribly interesting.

In the safe cookie authentication protocol, the controller never sends
the cookie itself.  That is the entire point of the protocol.

> If we only included the AUTHCHALLENGE message and response then this
> would not require a new authentication method so controllers could opt
> into the extra cookie validation. That said, if your intent is to
> force controllers to do the SAFECOOKIE handshake then this makes
> sense.

The old cookie authentication protocol exposes the *controller* to an
attack by (what it thinks is) Tor.  Controllers which use PROTOCOLINFO
to determine which cookie file to use should be updated to remove
support for the old COOKIE protocol.  Controllers which only look for
cookie files at paths whitelisted by their users can safely continue
to use COOKIE.


Robert Ransom