[tor-commits] [torspec/master] Add proposal 217: Tor Extended ORPort Authentication
nickm at torproject.org
nickm at torproject.org
Wed Nov 28 00:59:39 UTC 2012
commit 1d6ada880b389cb61a52ab120cb5a55a71292b6d
Author: Nick Mathewson <nickm at torproject.org>
Date: Tue Nov 27 19:59:34 2012 -0500
Add proposal 217: Tor Extended ORPort Authentication
---
proposals/000-index.txt | 2 +
proposals/217-ext-orport-auth.txt | 177 +++++++++++++++++++++++++++++++++++++
2 files changed, 179 insertions(+), 0 deletions(-)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 72bec71..5865e78 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -137,6 +137,7 @@ Proposals by number:
214 Allow 4-byte circuit IDs in a new link protocol [OPEN]
215 Let the minimum consensus method change with time [OPEN]
216 Improved circuit-creation key exchange [OPEN]
+217 Tor Extended ORPort Authentication [OPEN]
Proposals by status:
@@ -189,6 +190,7 @@ Proposals by status:
214 Allow 4-byte circuit IDs in a new link protocol
215 Let the minimum consensus method change with time
216 Improved circuit-creation key exchange
+ 217 Tor Extended ORPort Authentication [for 0.2.5.x]
ACCEPTED:
140 Provide diffs between consensuses
147 Eliminate the need for v2 directories in generating v3 directories [for 0.2.4.x]
diff --git a/proposals/217-ext-orport-auth.txt b/proposals/217-ext-orport-auth.txt
new file mode 100644
index 0000000..1206234
--- /dev/null
+++ b/proposals/217-ext-orport-auth.txt
@@ -0,0 +1,177 @@
+Filename: 217-ext-orport-auth.txt
+Title: Tor Extended ORPort Authentication
+Author: George Kadianakis
+Created: 28-11-2012
+Status: Open
+Target: 0.2.5.x
+
+1. Overview
+
+ This proposal defines a scheme for Tor components to authenticate to
+ each other using a shared-secret.
+
+2. Motivation
+
+ Proposal 196 introduced new ways for pluggable transport proxies to
+ communicate with Tor. The communication happens using TCP in the same
+ fashion that controllers speak to the ControlPort.
+
+ To defend against cross-protocol attacks [0] on the transport ports,
+ we need to define an authentication scheme that will restrict passage
+ to unknown clients.
+
+ Tor's ControlPort uses an authentication scheme called safe-cookie
+ authentication [1]. Unfortunately, the design of the safe-cookie
+ authentication was influenced by the protocol structure of the
+ ControlPort and the need for backwards compatibility of the
+ cookie-file and can't be easily reused in other use cases.
+
+3. Goals
+
+ The general goal of Extended ORPort authentication is to authenticate
+ the client based on a shared-secret that only authorized clients
+ should know.
+
+ Furthermore, its implementation should be flexible and easy to reuse,
+ so that it can be used as the authentication mechanism in front of
+ future Tor helper ports (for example, in proposal 199).
+
+ Finally, the protocol is able to support multiple authentication
+ schemes and each of them has different goals.
+
+4. Protocol Specification
+
+4.1. Initial handshake
+
+ When a client connects to the Extended ORPort, the server sends:
+
+ AuthTypes [variable]
+ EndAuthTypes [1 octet]
+
+ Where,
+
+ + AuthTypes are the authentication schemes that the server supports
+ for this session. They are multiple concatenated 1-octet values that
+ take values from 1 to 255.
+ + EndAuthTypes is the special value 0.
+
+ The client reads the list of supported authentication schemes and
+ replies with the one he prefers to use:
+
+ AuthType [1 octet]
+
+ Where,
+
+ + AuthType is the authentication scheme that the client wants to use
+ for this session. A valid authentication type takes values from 1 to
+ 255. A value of 0 means that the client did not like the
+ authentication types offered by the server.
+
+ If the client sent an AuthType of value 0, or an AuthType that the
+ server does not support, the server MUST close the connection.
+
+4.2. Authentication types
+
+4.2.1 SAFE_COOKIE handshake
+
+ Authentication type 1 is called SAFE_COOKIE.
+
+4.2.1.1. Motivation and goals
+
+ The SAFE_COOKIE scheme is pretty-much identical to the authentication
+ scheme that was introduced for the ControlPort in proposal 193.
+
+ An additional goal of the SAFE_COOKIE authentication scheme (apart
+ from the goals of section 2), is that it should not leak the contents
+ of the cookie-file to untrusted parties.
+
+ Specifically, the SAFE_COOKIE protocol will never leak the actual
+ contents of the file. Instead, it uses a challenge-response protocol
+ (similar to the HTTP digest authentication of RFC2617) to ensure that
+ both parties know the cookie without leaking it.
+
+4.2.1.2. Cookie-file format
+
+ The format of the cookie-file is:
+
+ StaticHeader [32 octets]
+ Cookie [32 octets]
+
+ Where,
+ + StaticHeader is the following string:
+ "! Extended ORPort Auth Cookie !\x0a"
+ + Cookie is the shared-secret. During the SAFE_COOKIE protocol, the
+ cookie is called CookieString.
+
+ Extended ORPort clients MUST make sure that the StaticHeader is
+ present in the cookie file, before proceeding with the
+ authentication protocol.
+
+ Details on how Tor locates the cookie file can be found in section 5
+ of proposal 196. Details on how transport proxies locate the cookie
+ file can be found in pt-spec.txt.
+
+4.2.1.3. Protocol specification
+
+ A client that performs the SAFE_COOKIE handshake begins by sending:
+
+ ClientNonce [32 octets]
+
+ Where,
+ + ClientNonce is 32 octets of random data.
+
+ Then, the server replies with:
+
+ ServerHash [32 octets]
+ ServerNonce [32 octets]
+
+ Where,
+ + ServerHash is computed as:
+ HMAC-SHA256(CookieString,
+ "ExtORPort authentication server-to-client hash" | ClientNonce | ServerNonce)
+ + ServerNonce is 32 random octets.
+
+ Upon receiving that data, the client computers ServerHash herself and
+ validates it against the ServerHash provided by the server.
+
+ If the server-provided ServerHash is invalid, the client MUST
+ terminate the connection.
+
+ Otherwise the client replies with:
+
+ ClientHash [32 octets]
+
+ Where,
+ + ClientHash is computed as:
+ HMAC-SHA256(CookieString,
+ "ExtORPort authentication client-to-server hash" | ClientNonce | ServerNonce)
+
+ Upon receiving that data, the server computers ClientHash herself and
+ validates it against the ClientHash provided by the client.
+
+ Finally, the server replies with:
+
+ Status [1 octet]
+
+ Where,
+ + Status is 1 if the authentication was successfull. If the
+ authentication failed, Status is 0.
+
+4.3. Post-authentication
+
+ After completing the Extended ORPort authentication successfully, the
+ two parties should proceed with the Extended ORPort protocol on the
+ same TCP connection.
+
+5. Acknowledgments
+
+ Thanks to Robert Ransom for helping with the proposal and designing
+ the original safe-cookie authentication scheme. Thanks to Nick
+ Mathewson for advices and reviews of the proposal.
+
+[0]:
+http://archives.seul.org/or/announce/Sep-2007/msg00000.html
+
+[1]:
+https://gitweb.torproject.org/torspec.git/blob/79f488c32c43562522e5592f2c19952dc7681a65:/control-spec.txt#l1069
+
More information about the tor-commits
mailing list