[tor-commits] [torspec/master] Add proposal 193: safe cookie authentication.
nickm at torproject.org
nickm at torproject.org
Tue Feb 7 18:32:32 UTC 2012
commit bd70d0448684325d9aa0d4f7645affee0aca39fa
Author: Nick Mathewson <nickm at torproject.org>
Date: Tue Feb 7 12:39:08 2012 -0500
Add proposal 193: safe cookie authentication.
---
proposals/000-index.txt | 2 +
proposals/193-safe-cookie-authentication.txt | 144 ++++++++++++++++++++++++++
2 files changed, 146 insertions(+), 0 deletions(-)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index d539742..73cdd5b 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -113,6 +113,7 @@ Proposals by number:
190 Bridge Client Authorization Based on a Shared Secret [NEEDS-REVISION]
191 Bridge Detection Resistance against MITM-capable Adversaries [OPEN]
192 Automatically retrieve and store information about bridges [OPEN]
+193 Safe cookie authentication for Tor controllers [OPEN]
Proposals by status:
@@ -147,6 +148,7 @@ Proposals by status:
189 AUTHORIZE and AUTHORIZED cells
191 Bridge Detection Resistance against MITM-capable Adversaries
192 Automatically retrieve and store information about bridges [for 0.2.[45].x]
+ 193 Safe cookie authentication for Tor controllers
ACCEPTED:
117 IPv6 exits [for 0.2.3.x]
140 Provide diffs between consensuses
diff --git a/proposals/193-safe-cookie-authentication.txt b/proposals/193-safe-cookie-authentication.txt
new file mode 100644
index 0000000..01d8720
--- /dev/null
+++ b/proposals/193-safe-cookie-authentication.txt
@@ -0,0 +1,144 @@
+Filename: 193-safe-cookie-authentication.txt
+Title: Safe cookie authentication for Tor controllers
+Author: Robert Ransom
+Created: 2012-02-04
+Status: Open
+
+Overview:
+
+ Not long ago, all Tor controllers which automatically attempted
+ 'cookie authentication' were vulnerable to an information-disclosure
+ attack. (See https://bugs.torproject.org/4303 for slightly more
+ information.)
+
+ Now, some Tor controllers which automatically attempt cookie
+ authentication are only vulnerable to an information-disclosure
+ attack on any 32-byte files they can read. But the Ed25519
+ signature scheme (among other cryptosystems) has 32-byte secret
+ keys, and we would like to not worry about Tor controllers leaking
+ our secret keys to whatever can listen on what the controller thinks
+ is Tor's control port.
+
+ Additionally, we would like to not have to remodel Tor's innards and
+ rewrite all of our Tor controllers to use TLS on Tor's control port
+ this week (or deal with the many design issues which that would
+ raise).
+
+Design:
+
+From af6bf472d59162428a1d7f1d77e6e77bda827414 Mon Sep 17 00:00:00 2001
+From: Robert Ransom <rransom.8774 at gmail.com>
+Date: Sun, 5 Feb 2012 04:02:23 -0800
+Subject: [PATCH] Add SAFECOOKIE control-port authentication method
+
+---
+ control-spec.txt | 59 ++++++++++++++++++++++++++++++++++++++++++++++-------
+ 1 files changed, 51 insertions(+), 8 deletions(-)
+
+diff --git a/control-spec.txt b/control-spec.txt
+index 66088f7..3651c86 100644
+--- a/control-spec.txt
++++ b/control-spec.txt
+@@ -323,11 +323,12 @@
+ For information on how the implementation securely stores authentication
+ information on disk, see section 5.1.
+
+- Before the client has authenticated, no command other than PROTOCOLINFO,
+- AUTHENTICATE, or QUIT is valid. If the controller sends any other command,
+- or sends a malformed command, or sends an unsuccessful AUTHENTICATE
+- command, or sends PROTOCOLINFO more than once, Tor sends an error reply and
+- closes the connection.
++ Before the client has authenticated, no command other than
++ PROTOCOLINFO, AUTHCHALLENGE, AUTHENTICATE, or QUIT is valid. If the
++ controller sends any other command, or sends a malformed command, or
++ sends an unsuccessful AUTHENTICATE command, or sends PROTOCOLINFO or
++ AUTHCHALLENGE more than once, Tor sends an error reply and closes
++ the connection.
+
+ To prevent some cross-protocol attacks, the AUTHENTICATE command is still
+ required even if all authentication methods in Tor are disabled. In this
+@@ -949,6 +950,7 @@
+ "NULL" / ; No authentication is required
+ "HASHEDPASSWORD" / ; A controller must supply the original password
+ "COOKIE" / ; A controller must supply the contents of a cookie
++ "SAFECOOKIE" ; A controller must prove knowledge of a cookie
+
+ AuthCookieFile = QuotedString
+ TorVersion = QuotedString
+@@ -970,9 +972,9 @@
+ methods that Tor currently accepts.
+
+ AuthCookieFile specifies the absolute path and filename of the
+- authentication cookie that Tor is expecting and is provided iff
+- the METHODS field contains the method "COOKIE". Controllers MUST handle
+- escape sequences inside this string.
++ authentication cookie that Tor is expecting and is provided iff the
++ METHODS field contains the method "COOKIE" and/or "SAFECOOKIE".
++ Controllers MUST handle escape sequences inside this string.
+
+ The VERSION line contains the Tor version.
+
+@@ -1033,6 +1035,47 @@
+
+ [TAKEOWNERSHIP was added in Tor 0.2.2.28-beta.]
+
++3.24. AUTHCHALLENGE
++
++ The syntax is:
++ "AUTHCHALLENGE" SP "AUTHMETHOD=SAFECOOKIE"
++ SP "COOKIEFILE=" AuthCookieFile
++ SP "CLIENTCHALLENGE=" 2*HEXDIG / QuotedString
++ CRLF
++
++ The server will reject this command with error code 512, then close
++ the connection, if Tor is not using the file specified in the
++ AuthCookieFile argument as a controller authentication cookie file.
++
++ If the server accepts the command, the server reply format is:
++ "250-AUTHCHALLENGE"
++ SP "CLIENTRESPONSE=" 64*64HEXDIG
++ SP "SERVERCHALLENGE=" 2*HEXDIG
++ CRLF
++
++ The CLIENTCHALLENGE, CLIENTRESPONSE, and SERVERCHALLENGE values are
++ encoded/decoded in the same way as the argument passed to the
++ AUTHENTICATE command.
++
++ The CLIENTRESPONSE value is computed as:
++ HMAC-SHA256(HMAC-SHA256("Tor server-to-controller cookie authenticator",
++ CookieString)
++ ClientChallengeString)
++ (with the HMAC key as its first argument)
++
++ After a controller sends a successful AUTHCHALLENGE command, the
++ next command sent on the connection must be an AUTHENTICATE command,
++ and the only authentication string which that AUTHENTICATE command
++ will accept is:
++ HMAC-SHA256(HMAC-SHA256("Tor controller-to-server cookie authenticator",
++ CookieString)
++ ServerChallengeString)
++
++ [Unlike other commands besides AUTHENTICATE, AUTHCHALLENGE may be
++ used (but only once!) before AUTHENTICATE.]
++
++ [AUTHCHALLENGE was added in Tor FIXME.]
++
+ 4. Replies
+
+ Reply codes follow the same 3-character format as used by SMTP, with the
+--
+1.7.8.3
+
+Rationale:
+
+ The weird inner HMAC was meant to ensure that whatever impersonates
+ Tor's control port cannot even abuse a secret key meant to be used
+ with HMAC-SHA256.
+
+ Then I added the server-to-controller challenge-response
+ authentication step, to ensure that the server can only use a
+ controller as an HMAC oracle if it already knows the contents of the
+ cookie file. Now, the inner HMAC is just a not-very-efficient way
+ to keep controllers from using the server as an oracle for its own
+ challenges (it could be replaced with a hash function).
+
More information about the tor-commits
mailing list