[tor-dev] Proposal xxx: Safe cookie authentication

[Robert Ransom]

On 2012-02-07, Nick Mathewson <nickm at alum.mit.edu> wrote:
> On Sun, Feb 5, 2012 at 7:46 AM, Robert Ransom <rransom.8774 at gmail.com>
> wrote:
>> See attached, because GMail would wrap lines if I sent it inline.
>
> Added as proposal 193.

Remember to push it.

> This seems like a general case of "A and B prove to each other that
> they both know some secret S without revealing S."  Are there existing
> protocols for that with security proofs?  It seems like something
> that's probably been done before.

Yes.  I believe this is an existing protocol, except for the extra
(inner) HMAC (see next chunk of reply).

> I wonder, have you got the HMAC arguments reversed in some places?
> When you do HMAC("string", cookiestring), you seem to be using the
> secret thing as the message, and the not-secret thing as the key.

I am, but that HMAC is meant only as a ‘tweaked message-digest
function’, so that we never ever compute
HMAC(potentially_secret_cookie_string, something_else).  (It's
remotely possible that someone could have a 32-byte HMAC-SHA256 key
stored as a binary file; I want to keep the server from abusing such a
key.)

> This would be a little easier to read if the function
> HMAC(HMAC(x,y),z) were given a name.
>
> Part of me wants to to incorporate both the ClientChallengeString and
> ServerChallengeString in both of the authenticator values, just on the
> theory that authenticating more fields of the protocol is probably
> smarter.

I'll think about this further.

> I'd note that this doesn't actually prevent information leakage
> entirely.  Instead of making you reveal some secret 32-byte file S,
> the attacker now makes you reveal HMAC(HMAC(k,S),c), where k is
> constant and the attacker controls c.   That's fine if S has plenty of
> entropy, but not so good if (say) S has 20 bytes of predictable data
> and 12 bytes of a user-generated password.  Then again, I'm not so
> sure a zero-knowledge protocol is really warranted here.

The server reveals its string first, thereby proving knowledge of the
secret (unless the client e.g. reuses a challenge, in which case it
deserves to lose) or access to an oracle for the server-to-controller
PoK.  (If the server has access to an oracle, it can already
brute-force a low-entropy secret.  An honest server's secret is not
low-entropy, so we don't have to worry about a client using this
attack.)

This is also another reason that I used the weird HMAC-of-HMAC
construction for both proofs -- no one has an excuse for using a
protocol which this authentication protocol could be used to attack.

> I am leery of adding this to 0.2.3.x (which is in feature-freeze),
> much less backporting it, but I'm having a hard time coming up with a
> way to do this entirely in the controller, so I guess we could call it
> a "security fix" rather than a "feature" if we can't think of another
> way to kludge around the problem.

The best that a controller can do without this protocol is to refuse
to use the cookie path Tor specifies in its response to a PROTOCOLINFO
command unless the controller's user has whitelisted that cookie path.
 I don't know whether that would be acceptable to controller authors
and users.


Robert Ransom