diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index dbd52869f1..28dd42e73f 100644 --- a/doc/spec/proposals/000-index.txt +++ b/doc/spec/proposals/000-index.txt @@ -43,6 +43,7 @@ Proposals by number: 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 @@ Proposals by status: 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 diff --git a/doc/spec/proposals/121-hidden-service-authentication.txt b/doc/spec/proposals/121-hidden-service-authentication.txt new file mode 100644 index 0000000000..848c88df1e --- /dev/null +++ b/doc/spec/proposals/121-hidden-service-authentication.txt @@ -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. +