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 08-Dec-2007 Incorporated comments by Nick posted to or-dev on 10-Oct-2007 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: [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 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, 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 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. 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 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. [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 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 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 -- 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. [Removed public-key authentication protocol. -KL] 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" 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. [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 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). [Removed public-key authentication protocol. -KL] 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. [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: 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 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 and service providers will have to update their Tor installation if they want to be able to use the service.