[or-cvs] r11653: Add hidden-service-authentication.etxt as proposal 121. (in tor/trunk: . doc/spec/proposals)
nickm at seul.org
nickm at seul.org
Wed Sep 26 14:52:10 UTC 2007
Author: nickm
Date: 2007-09-26 10:52:10 -0400 (Wed, 26 Sep 2007)
New Revision: 11653
Added:
tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt
Modified:
tor/trunk/
tor/trunk/doc/spec/proposals/000-index.txt
Log:
r15381 at catbus: nickm | 2007-09-26 10:48:00 -0400
Add hidden-service-authentication.etxt as proposal 121.
Property changes on: tor/trunk
___________________________________________________________________
svk:merge ticket from /tor/trunk [r15381] on 8246c3cf-6607-4228-993b-4d95d33730f1
Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt 2007-09-26 13:23:09 UTC (rev 11652)
+++ tor/trunk/doc/spec/proposals/000-index.txt 2007-09-26 14:52:10 UTC (rev 11653)
@@ -43,6 +43,7 @@
118 Advertising multiple ORPorts at once [NEEDS-RESEARCH]
119 New PROTOCOLINFO command for controllers [CLOSED]
120 Suicide descriptors when Tor servers stop [OPEN]
+121 Hidden Service Authentication [OPEN]
Proposals by status:
@@ -57,6 +58,7 @@
116 Two hop paths from entry guards
117 IPv6 exits
120 Suicide descriptors when Tor servers stop
+ 121 Hidden Service Authentication
ACCEPTED:
101 Voting on the Tor Directory System
103 Splitting identity key from regularly used signing key
Added: tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt
===================================================================
--- tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt (rev 0)
+++ tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt 2007-09-26 14:52:10 UTC (rev 11653)
@@ -0,0 +1,358 @@
+Filename: 121-hidden-service-authentication.txt
+Title: Hidden Service Authentication
+Version: $LastChangedRevision$
+Last-Modified: $LastChangedDate$
+Author: Tobias Kamm, Thomas Lauterbach, Karsten Loesing, Ferdinand Rieger,
+ Christoph Weingarten
+Created: 10-Sep-2007
+Status: Open
+
+Change history:
+
+ 26-Sep-2007 Initial proposal for or-dev
+
+Overview:
+
+ This proposal deals with some possibilities to implement authentication
+ for restricted access to hidden services. This way we try to increase the
+ security level for the service provider (Bob) by giving him the ability
+ to exclude non-authorized users from using his service. It is based on
+ proposal 114-distributed-storage but is better suited for a fine grained
+ way of authentication, because it is less resource-consuming. Whenever we
+ refer to service descriptors and cell formats, we are talking about the
+ definitions found in 114-distributed-storage unless otherwise stated.
+
+ We discuss password and public-key authentication for the Onion Proxy
+ (OP) of Bob's hidden service (HS). Furthermore a challenge-response
+ authentication mechanism is introduced at the introduction point.
+
+ These modifications aim at:
+ - increasing the security of hidden services by limiting access only to
+ authorized users (specification see details) and
+ - reducing the traffic in the network by rejecting unauthorized access
+ requests earlier.
+
+Motivation:
+
+ The currently used implementation of hidden services does not provide any
+ kind of authentication. The v2 implementation adds an authentication
+ mechanism at the directory server. Security can be further improved by
+ adding two more authentication authorities at the introduction point
+ (IPo) and the OP.
+
+ Although the service descriptors are already designed to carry
+ authentication information the existing fields are not used so far.
+ Moreover one can find a couple of notes at the specification of cell
+ formats (rend-spec) which point at adding authentication information but
+ no fields are specified yet. It would be preferable to extend the Tor
+ network with authentication features to offer a solution for all
+ services. This would also provide means to authorize access to services
+ that currently do not support authentication mechanisms. Moreover, Bob's
+ authentication administration for all services could be performed
+ centralized in the Tor application, and the implementation overhead for
+ developers would be significantly reduced. Another benefit would be the
+ reduced traffic by checking authentication data and dropping unauthorized
+ requests as soon as possible. For example unauthorized requests could
+ already be discarded at the introduction points.
+
+ In addition to that, our implementation is able to hide the service from
+ users, who still have access to the secret cookie (see
+ 114-distributed-storage) but should no longer be authorized. Bob can now
+ not only hide his location, but also to a certain degree his presence
+ towards unauthorized clients given that none of his IPo's are corrupted.
+
+Details:
+
+ /1/ Client authentication at the hidden service
+
+ In proposal 114 a client (Alice) who has a valid secret cookie, which may
+ be considered as a form of authentication, and a service ID is able to
+ connect to Bob if he is online. He can not distinguish between Alice
+ being intentionally authorized by himself or being an attacker.
+ Integrating authentication in Tor HS will ensure Bob that Alice is only
+ able to use the service if she is authorized by him.
+
+ 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
+ "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
+ the service's public key, sniffing attacks will fail. Bob will only build
+ 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.
+ 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
+ cases in which a client successfully passes the introduction point, but
+ fails at the HS should be almost zero. Therefore it is very important to
+ perform fine-grained access control already at the IPo (but without
+ relying on it).
+
+ The first authentication mechanism that will be supported is password
+ (symmetric secret) authentication. "AUTHT" is set to "1" for this
+ authentication method while the "AUTHL" field is set to "20", the length
+ of the SHA-1 digest of the password.
+
+ (1) Alice creates a password x and sends the password digest h(x) to Bob
+ out of band.
+ (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
+ proposal 114) and compares the contained h(x) with what he knows what
+ Alice's password digest h(x) should be.
+
+ This kind of authentication is well-known. It has the known disadvantage
+ of weak passwords that are vulnerable to dictionary or brute-force
+ attacks. Nevertheless it seems to be an appropriate solution since safe
+ 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
+ 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
+ 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).
+
+ 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.
+
+ It will also still be possible to establish v2 hidden services without
+ authentication. Therefore the "AUTHT" field must be set to "0". "AUTHL"
+ and "AUTHD" are not provided by the client in that case.
+
+ /2/ Client authentication at the introduction point
+
+ In addition to authentication at the HS OP, the IPo should be able to
+ detect and abandon all unauthorized requests. This would help to raise
+ the level of privacy and therefore also the level of security for Bob by
+ better hiding his online activity from unauthorized users. Especially if
+ Alice still has access to the secret cookie. This can be the case if she
+ had access to the service earlier, but is no longer authorized or the
+ directory is outdated. Another advantage of this additional "gate keeper"
+ would be reduced traffic in the network, because unauthorized requests
+ could already be detected and declined at the IPo.
+
+ It is important to notice that the IPo may not be trustworthy, and
+ therefore can not replace authentication at the HS OP itself. Nor should
+ the IPo get hold of critical authentication information (because it could
+ try to access the service itself).
+
+ A challenge-response authentication protocol is used to address these
+ issues. This means that a challenge is needed to be solved by Alice to
+ get forwarded to Bob by the IPo.
+
+ Two types of authentication are supported and need to be preconfigured by
+ Bob when creating the service: password and public-key authentication.
+ Again it is up to Alice what kind of authentication mechanism she wants
+ to use, given that Bob knows both her password and her public key.
+
+ If Alice uses a password to authenticate herself at the IPo, the
+ authentication is based on a symmetric challenge-response authentication
+ protocol. In this case the challenge for Alice is to send h(x|y) where x
+ is a user-specific password, which should be different from the password
+ needed for authentication at the hidden service and y is a randomly
+ generated value. Alice gets hold of her password out of band.
+
+ With the initial RELAY_ESTABLISH_INTRO cell, the IPo gets a list of
+ h(x|y)'s which it stores locally. Upon a request of Alice it compares her
+ provided authentication data with the list entries. If there is a
+ matching entry in its list, Alice's request is valid and can be forwarded
+ to Bob. To generate the hash, Alice needs to know the password (which she
+ will get out of band) and the random value y. This value is contained in
+ the cookie-encrypted part of the hidden service descriptor which Alice
+ can retrieve from the directory using her secret cookie.
+
+ (1) Alice creates a password x and sends the password digest h(x) to Bob
+ out of band.
+ (2) Bob creates a random value y, computes h(h(x)|y), and sends the
+ result to the introduction point.
+ (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
+ the secret cookie (see proposal 114), computes h(h(x)|y), encrypts
+ it with the public key of the introduction point, and sends it to
+ that introduction point.
+ (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.
+
+ 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.
+
+ The changes needed in Tor to realize these two challenge-response
+ variations affect the RELAY_ESTABLISH_INTRO and RELAY_INTRODUCE1 relay
+ cells, the service descriptor and the code parts in Tor where these cells
+ and the descriptor are handled.
+
+ The RELAY_ESTABLISH_INTRO cell is now structured as follows:
+
+ V Format byte: set to 255 [1 octet]
+ V Version byte: set to 2 [1 octet]
+ KL Key length [2 octets]
+ PK Bob's public key [KL octets]
+ HS Hash of session info [20 octets]
+ AUTHT The auth type that is supported [1 octet]
+ AUTHL Length of auth data [2 octets]
+ AUTHD Auth data [variable]
+ SIG Signature of above information [variable]
+
+ "AUTHT" is set to "1" for password/public-key authentication.
+ "AUTHD" is a list of 20 octet long challenges for clients.
+
+ The service descriptor as specified in 114-distributed-storage is used in
+ our implementation.
+
+ For password authentication "authentication" auth-type is set to "1" and
+ auth-data contains the 20 octets long string used by clients to construct
+ the response to the challenge for authentication at the IPo.
+
+ When using public-key authentication the auth-type is set to "2" and
+ auth-data holds a list of 148 octets long blank separated values. The
+ first 20 octets of each value is the hash of the public key of a certain
+ 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.
+
+ The part of the RELAY_INTRODUCE1 cell that can be read by the IPo has the
+ following fields added:
+
+ AUTHT The auth type that is supported [1 octet]
+ AUTHL Length of auth data [1 octets]
+ AUTHD Auth data [variable]
+
+ 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.
+
+Security implications:
+
+ In addition to the security features proposed in 114-distributed-storage
+ a new way of authentication is added at the OP of Bob. Moreover, the
+ authentication at the IPo's is improved to support a fine-grained access
+ control. Corrupted IPo's may easily bypass this authentication, but given
+ the case that the majority of IPo's is acting as expected we still
+ consider this feature as being useful.
+
+ Bob can now decide whether he wants to allow Alice to use his services or
+ not. This gives him the possibility to offer his services only to known
+ and trusted users that need to identify by a password or by signing their
+ messages. The anonymity of the client towards the service provider is
+ thereby reduced to pseudonymity.
+
+ Changing of access rights now involves all three authorization authorities
+ depending on what changes should be made:
+
+ - The user configures his changes at the local OP. Therefore he can
+ edit the cookie files that were extended to support multiple users.
+ Moreover he can edit the new user files that were added to specify
+ authentication information for every user.
+
+ - Whenever local changes occur, this information needs to be either
+ passed to the responsible IPo's, the directory servers, or both
+ depending on the authorization method and operation used. It is
+ important to have consistent authorization results at all authorities
+ at the same time, to create a trustworthy system with good user
+ acceptance. As these reconfigurations always follow local changes
+ they can be done automatically by the new Tor implementation and
+ therefore no user interaction is needed.
+
+ - The secret cookies proposed in 114-distributed-storage are used for
+ group management in our implementation as their use would be far to
+ costly for a user-based authorization. That is because right now one
+ descriptor is generated and uploaded for every secret cookie. Changes
+ in this configuration should therefore be rare (maybe never) and only
+ a few groups should exist. Provided that this is the case the costs
+ for changes seem acceptable. As there is currently no possibility to
+ make a directory remove the descriptor for a group an updated
+ descriptor without any IPo should be uploaded to the directory
+ servers.
+
+ Local changes to access rights can now be done faster than by changing
+ service descriptors which reduces the directory server load and network
+ traffic. Still every configuration change remains costly and users should
+ carefully choose how detailed the access right configuration should be.
+
+ Attacking clients now need to bypass two more authentication steps to
+ reach the service implementation. Compared to the current state it is
+ more likely that attackers can be stopped even before they are able to
+ contact Bob's OP. We expect that the possibility of an attack is thereby
+ significantly reduced. Another positive side effect is that network
+ traffic and router load is reduced by discarding unauthorized cells which
+ should lower the effectiveness of denial of service attacks.
+
+Compatibility:
+
+ 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
+ want to be able to use the service.
+
Property changes on: tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
More information about the tor-commits
mailing list