[or-cvs] r12725: proposal 121: incorporated comments by Nick posted to or-dev (tor/trunk/doc/spec/proposals)
kloesing at seul.org
kloesing at seul.org
Sun Dec 9 00:18:51 UTC 2007
Author: kloesing
Date: 2007-12-08 19:18:51 -0500 (Sat, 08 Dec 2007)
New Revision: 12725
Modified:
tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt
Log:
proposal 121: incorporated comments by Nick posted to or-dev on 10-Oct-2007
Modified: tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt
===================================================================
--- tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt 2007-12-08 20:16:34 UTC (rev 12724)
+++ tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt 2007-12-09 00:18:51 UTC (rev 12725)
@@ -10,6 +10,7 @@
Change history:
26-Sep-2007 Initial proposal for or-dev
+ 08-Dec-2007 Incorporated comments by Nick posted to or-dev on 10-Oct-2007
Overview:
@@ -63,6 +64,15 @@
Details:
+ [XXX Restructure this section in separate patch:
+ A) The general mechanisms to perform authentication at three
+ authentication points (directory, service, introduction point)
+ B) A specific authentication protocol based on secret cookies. -KL]
+
+ [XXX Describe use of descriptor cookie as "/0/ Client authentication at
+ directory". Optional encryption/decryption using a descriptor cookie is
+ understood since proposal 114, but not used by servers and clients. -KL]
+
/1/ Client authentication at the hidden service
In proposal 114 a client (Alice) who has a valid secret cookie, which may
@@ -75,7 +85,8 @@
Authentication data will be transmitted via the RELAY_INTRODUCE1 cell
from Alice to Bob that is forwarded by the IPo. For this message several
format versions are specified in the rend-spec in section 1.8. We will
- use the format version 3. This specification already contains the fields
+ use the format version 3, which is specified, but not implemented by
+ December 2007. This specification already contains the fields
"AUTHT" (to specify the authentication method), "AUTHL" (length of the
authentication data), and "AUTHD" (the authentication data) that will be
used to store authentication data. Since these fields are encrypted with
@@ -83,6 +94,8 @@
the circuit to the rendezvous point if the provided authentication data
is valid, otherwise he will drop the cell. This will improve security due
to preventing communication between Bob and Alice if she is an attacker.
+ Especially, it prevents the attack described by Øverlier and Syverson in
+ their paper "Locating Hidden Servers", even without the need for guards.
As a positive side effect it reduces network traffic because it avoids
Bob from building unnecessary circuits to the rendezvous points.
Authentication at the HS should be the last gatekeeper and the number of
@@ -98,6 +111,8 @@
(1) Alice creates a password x and sends the password digest h(x) to Bob
out of band.
+ [XXX Don't distinguish between x and h(x), so that both Alice and Bob
+ can be the initiator of the password exchange. -KL]
(2) Alice sends h(x) to Bob, encrypted with Bob's fresh service key (not
subject to this proposal, see proposal 114).
(3) Bob decrypts Alice's message using his private service key (see
@@ -110,47 +125,30 @@
passwords can be randomly generated by Tor. Cracking methods that rely on
guessing passwords should not be effective in the constantly changing
network infrastructure. A usability advantage is that this method is easy
- to perform even for unexperienced users. The authenticationdata will be
+ to perform even for unexperienced users. The authentication data will be
the SHA-1 secure hash (see tor-spec) of the shared secret (password).
The premise to use password authentication is that Bob must send the
- password to Alice outside Tor. If at the same time the secret cookie is
+ password to Alice -- or the other way around -- outside Tor.
+ If at the same time the secret cookie is
transmitted and the message is intercepted the attacker can gain access
to the service. Therefore, a secure way to exchange this information must
be established.
- The second authentication mechanism is public-key authentication. The
- well-known RSA implementation will be used as cipher (see tor-spec).
- Authentication data will be the hash of the rendezvous cookie, signed
- with the private key (SK).
+ [Removed public-key authentication protocol. -KL]
- When Alice wants to use this authentication method she sets "AUTHT" to
- "2" and "AUTHL" to "128" which is the size of the encrypted data. Since
- the rendezvous cookie changes each time Alice connects, replay attacks
- can be easily prevented.
-
- (1) Alice creates a private key e and sends the corresponding public key
- d to Bob out of band.
- (2) Alice generates a random rendezvous cookie r, computes PKSign(e, r),
- encrypts it with Bob's fresh service key (see proposal 114), and
- sends the result to Bob.
- (3) Bob decrypts Alice's message using his private service key (see
- proposal 114) and verifies PKSign(e, r) with d.
-
- The premise for public-key authentication is that Alice must send the
- generated public key to Bob outside Tor. If an attacker is able to swap
- that key, the attacker could perform a man-in-the-middle attack, if he
- managed to serve as an IPo for Bob. Therefore a secure exchange channel
- must be established.
-
- Depending on what authentication data Bob knows from Alice (password
- and/or public key, or other data that is added later) there are several
- choices for Alice to authenticate to the service.
-
After validating the provided "AUTHD" Bob builds a circuit to the
rendezvous point and starts interacting with Alice. If Bob cannot
identify the client he must refuse the request by not connecting to the
rendezvous point.
+ [XXX Bob should discard an IPo after a certain number of cells containing
+ bad auth data. But any denouncement by other IPos or clients, e.g. by
+ replaying cells, must be inhibited. Maybe Bob should keep a history of
+ connection attempts within a certain time and discard an IPo after a
+ specific threshold. And maybe authentication to the service should be
+ based on a nonce, so that the service can differentiate between a replay
+ attack by an introduction point and regular reconnection attempts. More
+ thoughts needed here. -KL]
It will also still be possible to establish v2 hidden services without
authentication. Therefore the "AUTHT" field must be set to "0". "AUTHL"
@@ -202,6 +200,9 @@
out of band.
(2) Bob creates a random value y, computes h(h(x)|y), and sends the
result to the introduction point.
+ [XXX There should be a separate y for each introduction point, so
+ that none of them may impersonate Alice to any of the other
+ introduction points. -KL]
(3) Bob encrypts y with a secret cookie (see proposal 114) and writes it
to a rendezvous service descriptor.
(4) Alice fetches Bob's rendezvous service descriptor, decrypts y using
@@ -211,38 +212,8 @@
(5) The introduction point decrypts h(h(x)|y) from Alice's message and
compares it to the value it knows from Bob (from step 2).
- If Alice wants to use public-key authentication to authenticate herself
- at Bob's HS, the challenge-response authentication protocol is slightly
- different.
+ [Removed public-key authentication protocol. -KL]
- The IPo's are provided with a list of random value hashes h(r) with an
- entry for each user via the RELAY_ESTABLISH_INTRO cell. For public-key
- authentication Alice uses an RSA public/private-key pair (as specified in
- tor-spec). The public key is made known to Bob out of band. The IPo's
- will now be sent a new ESTABLISH_INTRO cell with an additional random
- value hash for Alice and a new descriptor is uploaded to the responsible
- directories. The public-key authentication part of the service descriptor
- holds a blank separated list of key-value pairs with one pair for every
- authorized user. The hash of the public key of a user serves as a key,
- while the PK-encrypted r represents the value. Authorized users can now
- find their respective key-value pair and decrypt the value of h(r). This
- result serves as an authorization token at the IPo in the same way as
- with password authentication. The IPo does not know which authentication
- method was used since the tokens always have the same format.
-
- (1) Alice creates a private key e and sends the corresponding public key
- d to Bob out of band.
- (2) Bob creates a random value y and sends it to the introduction point.
- (3) Bob computes PKEncrypt(d, y), encrypts the result with a secret
- cookie (see proposal 114), and writes it to a rendezvous service
- descriptor.
- (4) Alice fetches Bob's rendezvous service descriptor, decrypts
- PKEncrypt(d, y) using the secret cookie (see proposal 114), decrypts
- y from it using her private key e, and sends it to the introduction
- point.
- (5) The introduction point compares y with the value it knows from Bob
- (from step 2).
-
To remove a user from a group, Bob needs to update the random value list
at the IPo's.
@@ -279,6 +250,9 @@
client and used by Alice to determine her entry in the list. The
remaining 128 octets contain the PK-encrypted token needed to
authenticate to the IPo.
+ [XXX Handle space limitation problem, either by using fewer space, by
+ sending multiple cells, or by finding a protocol that is
+ space-independent here. -KL]
The part of the RELAY_INTRODUCE1 cell that can be read by the IPo has the
following fields added:
@@ -286,11 +260,15 @@
AUTHT The auth type that is supported [1 octet]
AUTHL Length of auth data [1 octets]
AUTHD Auth data [variable]
+ [XXX Insert a version field, so that we won't be facing the same problems
+ again when specifying the next version of INTRODUCE1 cells. -KL]
The AUTHT and AUTHL fields are provided to allow extensions of the
protocol. Currently, we set AUTHT to 1 for password/public-key
authentication and AUTHL to 20 for the length of the authorization token.
+ [XXX Insert file format containing auth data here. -KL]
+
Security implications:
In addition to the security features proposed in 114-distributed-storage
@@ -352,7 +330,7 @@
When using our authentication for hidden services the implementation of
IPo's needs to be extended. Therefore we use version information provided
in router descriptors to be sure that we only send modified
- RELAY_ESTABLISH_INTRO cells to routers that can handle them. Clients of
- v2 hidden services will have to update their Tor installation if they
+ RELAY_ESTABLISH_INTRO cells to routers that can handle them. Clients and
+ service providers will have to update their Tor installation if they
want to be able to use the service.
More information about the tor-commits
mailing list