[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r12824: proposal 121: rewrote complete proposal for better readabili (tor/trunk/doc/spec/proposals)
Author: kloesing
Date: 2007-12-15 15:09:43 -0500 (Sat, 15 Dec 2007)
New Revision: 12824
Modified:
tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt
Log:
proposal 121: rewrote complete proposal for better readability, modified authentication protocol, merged in personal notes
Modified: tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt
===================================================================
--- tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt 2007-12-15 08:57:35 UTC (rev 12823)
+++ tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt 2007-12-15 20:09:43 UTC (rev 12824)
@@ -11,326 +11,602 @@
26-Sep-2007 Initial proposal for or-dev
08-Dec-2007 Incorporated comments by Nick posted to or-dev on 10-Oct-2007
+ 15-Dec-2007 Rewrote complete proposal for better readability, modified
+ authentication protocol, merged in personal notes
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.
+ This proposal deals with a general infrastructure for performing
+ authentication and authorization of requests to hidden services at three
+ authentication points: (1) when downloading and decrypting parts of the
+ hidden service descriptor, (2) at the introduction point, and (3) at
+ Bob's onion proxy before contacting the rendezvous point. A service
+ provider will be able to restrict access to his service at these three
+ points to authorized clients only. Further, the proposal contains a first
+ instance of an authentication protocol for the presented infrastructure.
- 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.
+ This proposal is based on v2 hidden service descriptors as described in
+ proposal 114 and introduced in version 0.2.0.10-alpha.
- 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.
+ The proposal is structured as follows: The next section motivates the
+ integration of authentication mechanisms in the hidden service protocol.
+ Then we describe a general infrastructure for authentication in hidden
+ services, followed by a specific authentication protocol for this
+ infrastructure. At the end we discuss a number of attacks and non-attacks
+ as well as compatibility issues.
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.
+ The major part of hidden services does not require client authentication
+ now and won't do so in the future. To the contrary, many clients would
+ not want to be (pseudonymously) identifiable by the service, but rather
+ use the service anonymously. These services are not addressed by this
+ proposal.
- 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.
+ However, there may be certain services which are intended to be accessed
+ by a limited set of clients only. A possible application might be a
+ wiki or forum that should only be accessible for a closed user group.
+ Another, less intuitive example might be a real-time communication
+ service, where someone provides a presence and messaging service only to
+ his buddies. Finally, a possible application would be a personal home
+ server that should be remotely accessed by its owner.
- 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.
+ Performing authentication to a hidden service within the Tor network, as
+ proposed here, offers a range of advantages compared to allowing all
+ client connections in the first instance and deferring authentication and
+ authorization to the transported protocol:
+ (1) Reduced traffic: Unauthorized requests would be rejected as early as
+ possible, thereby reducing the overall traffic in the network generated
+ by establishing circuits and sending cells.
+
+ (2) Better protection of service location: Unauthorized clients could not
+ force Bob to create circuits to their rendezvous points, thus preventing
+ the attack described by Øverlier and Syverson in their paper "Locating
+ Hidden Servers" even without the need for guards.
+
+ (3) Hiding activity: Apart from performing the actual access control, a
+ service provider could also hide the mere presence of his service when
+ not providing hidden service descriptors to unauthorized clients and
+ rejecting unauthorized requests already at the introduction point
+ (ideally without leaking presence information at any of these points).
+
+ (4) Better protection of introduction points: When providing hidden
+ service descriptors to authorized clients only and encrypting the
+ introduction points as described in proposal 114, the introduction points
+ would be unknown to unauthorized clients and thereby protected from DoS
+ attacks.
+
+ (5) Protocol independence: Authentication and authorization could be
+ performed for all transported protocols, regardless of their own
+ capabilities to do so.
+
+ (6) Ease of administration: A service provider running multiple hidden
+ services would be able to configure access at a single place uniformly
+ instead of doing so for all services separately.
+
+ (7) Optional QoS support: Bob could adapt his node selection algorithm
+ for building the circuit to Alice's rendezvous point depending on a
+ previously guaranteed QoS level, thus providing better latency or
+ bandwidth for selected clients.
+
+ Performing authentication generally implies being identifiable towards an
+ authentication point. However, when performing authentication within the
+ Tor network, untrusted points should not gain any useful information
+ about the identities of communicating parties, neither server nor client.
+ A crucial challenge is to remain anonymous towards directory servers and
+ introduction points.
+
+ The current implementation of hidden services does not provide any kind
+ of authentication. The hidden service descriptor version 2, introduced by
+ proposal 114, was designed to use a descriptor cookie for downloading and
+ decrypting parts of the descriptor content, but this feature is not yet
+ in use. Further, most relevant cell formats specified in rend-spec
+ contain fields for authentication data, but those fields are neither
+ implemented nor do they suffice entirely.
+
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]
+ 1 General infrastructure for authentication to hidden services
- [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]
+ We spotted three possible authentication points in the hidden service
+ protocol:
- /1/ Client authentication at the hidden service
+ (1) when downloading and decrypting parts of the hidden service
+ descriptor,
+ (2) at the introduction point, and
+ (3) at Bob's onion proxy before contacting the rendezvous point.
- 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.
+ The general idea of this proposal is to allow service providers to
+ restrict access to all of these authentication points to authorized
+ clients only.
- 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).
+ 1.1 Client authentication at directory
- 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.
+ Since the implementation of proposal 114 it is possible to combine a
+ hidden service descriptor with a so-called descriptor cookie. If done so,
+ the descriptor cookie becomes part of the descriptor ID, thus having an
+ effect on the storage location of the descriptor. Someone who has learned
+ about a service, but is not aware of the descriptor cookie, won't be able
+ to determine the descriptor ID and download the current hidden service
+ descriptor; he won't even know whether the service has uploaded a
+ descriptor recently. Descriptor IDs are calculated as follows (see
+ section 1.2 of rend-spec for the complete specification of v2 hidden
+ service descriptors):
- (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.
+ descriptor-id =
+ H(permanent-id | H(time-period | descriptor-cookie | replica))
- 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 second purpose of the descriptor cookie is to encrypt the list of
+ introduction points, including optional authentication data. Hence, the
+ hidden service directories won't learn any introduction information from
+ storing a hidden service descriptor. This feature is implemented but
+ unused at the moment, so that this proposal will harness the advantages
+ of proposal 114.
- 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.
+ The descriptor cookie can be used for authentication by keeping it secret
+ from everyone but authorized clients. A service could then decide whether
+ to publish hidden service descriptors using that descriptor cookie later
+ on. An authorized client being aware of the descriptor cookie would be
+ able to download and decrypt the hidden service descriptor.
+
+ The number of concurrently used descriptor cookies for one hidden service
+ is not restricted. A service could use a single descriptor cookie for all
+ users, a distinct cookie per user, or something in between, like one
+ cookie per group of users. It is up to the specific protocol and how it
+ is applied by a service provider. However, we advise to use a small
+ number of descriptor cookies for efficiency reasons and for improving the
+ ability to hide presence of a service (see security implications at the
+ end of this document).
+
+ Although this part of the proposal is meant to describe a general
+ infrastructure for authentication, changing the way of using the
+ descriptor cookie to look up hidden service descriptors, e.g. applying
+ some sort of asymmetric crypto system, would require in-depth changes
+ that would be incompatible to v2 hidden service descriptors. On the
+ contrary, using another key for en-/decrypting the introduction point
+ part of a hidden service descriptor, e.g. a different symmetric key or
+ asymmetric encryption, would be easy to implement and compatible to v2
+ hidden service descriptors as understood by hidden service directories
+ (clients and servers would have to be upgraded anyway for using the new
+ features).
- [Removed public-key authentication protocol. -KL]
+ 1.2 Client authentication at introduction point
- 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]
+ The next possible authentication point after downloading and decrypting
+ a hidden service descriptor is the introduction point. It is important
+ for authentication, because it bears the last chance of hiding presence
+ of a hidden service from unauthorized clients. Further, performing
+ authentication at the introduction point might reduce traffic in the
+ network, because unauthorized requests would not be passed to the
+ hidden service. This applies to those clients who are aware of a
+ descriptor cookie and thereby of the hidden service descriptor, but do
+ not have authorization data to access the service.
- 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.
+ It is important to note that the introduction point must be considered
+ untrustworthy, and therefore cannot replace authentication at the hidden
+ service itself. Nor should the introduction point learn any sensitive
+ identifiable information from either server or client.
- /2/ Client authentication at the introduction point
+ In order to perform authentication at the introduction point, three
+ message formats need to be modified: (1) v2 hidden service descriptors,
+ (2) ESTABLISH_INTRO cells, and (3) INTRODUCE1 cells.
- 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.
+ A v2 hidden service descriptor needs to contain authentication data that
+ is introduction-point-specific and sometimes also authentication data
+ that is introduction-point-independent. Therefore, v2 hidden service
+ descriptors as specified in section 1.2 of rend-spec already contain two
+ reserved fields "intro-authentication" and "service-authentication"
+ containing an authentication type number and arbitrary authentication
+ data. We propose that authentication data consists of base64 encoded
+ objects of arbitrary length, surrounded by "-----BEGIN MESSAGE-----" and
+ "-----END MESSAGE-----". This will increase the size of hidden service
+ descriptors, which however is possible, as there is no strict upper
+ limit.
- 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).
+ The current ESTABLISH_INTRO cells as described in section 1.3 of
+ rend-spec don't contain either authentication data or version
+ information. Therefore, we propose a new version 1 of the ESTABLISH_INTRO
+ cells adding these two issues as follows:
- 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.
+ V Format byte: set to 255 [1 octet]
+ V Version byte: set to 1 [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]
- 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.
+ From the format it is possible to determine the maximum allowed size for
+ authentication data: given the fact that cells are 512 octets long, of
+ which 498 octets are usable (see section 6.1 of tor-spec), and assuming
+ 1024 bit = 128 octet long keys, there are 215 octets left for
+ authentication data. Hence, authentication protocols are bound to use no
+ more than these 215 octets, regardless of the number of clients that
+ shall be authenticated at the introduction point. Otherwise, one would
+ need to send multiple ESTABLISH_INTRO cells or split them up, what we do
+ not specify here.
- 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.
+ In order to understand a v1 ESTABLISH_INTRO cell, the implementation of
+ a relay must have a certain Tor version, which would probably be some
+ 0.2.1.x. Hidden services need to be able to distinguish relays being
+ capable of understanding the new v1 cell formats and perform
+ authentication. We propose to use the version number that is contained in
+ networkstatus documents to find capable introduction points.
- 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.
+ The current INTRODUCE1 cells as described in section 1.8 of rend-spec is
+ not designed to carry authentication data and has no version number, too.
+ We propose the following version 1 of INTRODUCE1 cells:
- (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).
+ Cleartext
+ V Version byte: set to 1 [1 octet]
+ PK_ID Identifier for Bob's PK [20 octets]
+ AUTHT The auth type that is supported [1 octet]
+ AUTHL Length of auth data [2 octets]
+ AUTHD Auth data [variable]
+ Encrypted to Bob's PK:
+ (RELAY_INTRODUCE2 cell)
- [Removed public-key authentication protocol. -KL]
+ The maximum length of contained authentication data depends on the length
+ of the contained INTRODUCE2 cell. A calculation follows below when
+ describing the INTRODUCE2 cell format we propose to use.
- To remove a user from a group, Bob needs to update the random value list
- at the IPo's.
+ Unfortunately, v0 INTRODUCE1 cells consist only of a fixed-size,
+ seemingly random PK_ID, followed by the encrypted INTRODUCE2 cell. This
+ makes it impossible to distinguish v0 INTRODUCE1 cells from any later
+ format. In particular, it is not possible to introduce some kind of
+ format and version byte for newer versions of this cell. That's probably
+ where the comment "[XXX011 want to put intro-level auth info here, but no
+ version. crap. -RD]" that was part of rend-spec some time ago comes from.
- 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.
+ Processing of v1 INTRODUCE1 cells therefore requires knowledge about the
+ context in which they are used. As a result, we propose that when
+ receiving a v1 ESTABLISH_INTRO cell, an introduction point only accepts
+ v1 INTRODUCE1 cells later on. Hence, the same introduction point cannot
+ be used to accept both v0 and v1 INTRODUCE1 cells. (Another solution
+ would be to distinguish v0 and v1 INTRODUCE1 cells by their size, as v0
+ INTRODUCE1 cells can only have specific cell sizes, depending on the
+ version of the contained INTRODUCE2 cell; however, this approach does not
+ appear very clean.)
- The RELAY_ESTABLISH_INTRO cell is now structured as follows:
+ 1.3 Client authentication at hidden service
- 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]
+ The time when a hidden service receives an INTRODUCE2 cell constitutes
+ the last possible authentication point during the hidden service
+ protocol. Performing authentication here is easier than at the other two
+ authentication points, because there are no possibly untrusted entities
+ involved.
- "AUTHT" is set to "1" for password/public-key authentication.
- "AUTHD" is a list of 20 octet long challenges for clients.
+ In general, a client that is successfully authorized at the introduction
+ point should be granted access at the hidden service, too. Otherwise, the
+ client would receive a positive INTRODUCE_ACK cell from the introduction
+ point and conclude that it may connect to the service, but the request
+ will be dropped without notice. This would appear as a failure to
+ clients. Therefore, the number of cases in which a client successfully
+ passes the introduction point, but fails at the hidden service should be
+ almost zero. However, this does not lead to the conclusion, that the
+ authentication data used at the introduction point and the hidden service
+ must be the same, but only that both authentication data should lead to
+ the same authorization result.
- The service descriptor as specified in 114-distributed-storage is used in
- our implementation.
+ Authentication data is transmitted from client to server via an
+ INTRODUCE2 cell that is forwarded by the introduction point. There are
+ versions 0 to 2 specified in section 1.8 of rend-spec, but none of these
+ contains fields for carrying authentication data. We propose a slightly
+ modified version of v3 INTRODUCE2 cells that is specified in section
+ 1.8.1 and which is not implemented as of December 2007. The only change
+ is to switch the lengths of AUTHT and AUTHL, which we assume to be a typo
+ in current rend-spec. The proposed format of v3 INTRODUCE2 cells is as
+ follows:
- 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.
+ VER Version byte: set to 3. [1 octet]
+ ATYPE An address type (typically 4) [1 octet]
+ ADDR Rendezvous point's IP address [4 or 16 octets]
+ PORT Rendezvous point's OR port [2 octets]
+ AUTHT The auth type that is supported [1 octet]
+ AUTHL Length of auth data [2 octets]
+ AUTHD Auth data [variable]
+ ID Rendezvous point identity ID [20 octets]
+ KLEN Length of onion key [2 octets]
+ KEY Rendezvous point onion key [KLEN octets]
+ RC Rendezvous cookie [20 octets]
+ g^x Diffie-Hellman data, part 1 [128 octets]
- 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 maximum possible length of authentication data is related to the
+ enclosing INTRODUCE1 cell. A v3 INTRODUCE2 cell with IPv6 address and
+ 1024 bit = 128 octets long public keys without any authentication data
+ occupies 321 octets, plus 58 octets for hybrid public key encryption (see
+ section 5.1 of tor-spec on hybrid encryption of CREATE cells). The
+ surrounding v1 INTRODUCE1 cell requires 24 octets. This leaves only 95
+ of the 498 available octets free, which must be shared between
+ authentication data to the introduction point _and_ to the hidden
+ service.
- The part of the RELAY_INTRODUCE1 cell that can be read by the IPo has the
- following fields added:
+ When receiving a v3 INTRODUCE2 cell, Bob checks whether a client has
+ provided valid authentication data to him. He will only then build a
+ circuit to the provided rendezvous point and otherwise will drop the
+ cell.
- 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]
+ There might be several attacks based on the idea of replaying existing
+ cells to the hidden service. In particular, someone (the introduction
+ point or an evil authenticated client) might replay valid INTRODUCE2
+ cells to make the hidden service build an arbitrary number of circuits to
+ (maybe long gone) rendezvous points. Therefore, we propose that hidden
+ services maintain a history of received INTRODUCE2 cells within the last
+ hour and only accept INTRODUCE2 cells matching the following rules:
- 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.
+ (1) a maximum of 3 cells coming from the same client and containing the
+ same rendezvous cookie, and
+ (2) a maximum of 10 cells coming from the same client with different
+ rendezvous cookies.
- [XXX Insert file format containing auth data here. -KL]
+ This allows a client to retry connection establishment using the same
+ rendezvous point for 3 times and a total number of 10 connection
+ establishments (not requests in the transported protocol) per hour.
+ 1.4 Summary of authentication data fields
+
+ In summary, the proposed descriptor format and cell formats provide the
+ following fields for carrying authentication data:
+
+ (1) The v2 hidden service descriptor contains:
+ - a descriptor cookie that is used for the lookup process, and
+ - an arbitrary encryption schema to encrypt introduction information
+ (currently symmetric encryption with the descriptor cookie).
+
+ (2) For performing authentication at the introduction point we can use:
+ - the fields intro-authentication and service-authentication in
+ hidden service descriptors,
+ - a maximum of 215 octets in the ESTABLISH_INTRO cell, and
+ - one part of 95 octets in the INTRODUCE1 cell.
+
+ (3) For performing authentication at the hidden service we can use:
+ - the fields intro-authentication and service-authentication in
+ hidden service descriptors,
+ - the other part of 95 octets in the INTRODUCE2 cell.
+
+ It will also still be possible to access a hidden service without any
+ authentication or only use a part of the authentication infrastructure.
+ However, this requires to consider all parts of the infrastructure to
+ make sure that no assumption is violated. For example, authentication at
+ the introduction point relying on confidential intro-authentication data
+ transported in the hidden service descriptor cannot be performed without
+ using an encryption schema for introduction information.
+
+ 1.5 Managing authentication data at servers and clients
+
+ In order to provide authentication data at the hidden server and the
+ authenticated clients, we propose to use files---either the tor
+ configuration file or separate files. In the latter case a hidden server
+ would use one file per provided service, and a client would use one file
+ per server she wants to access. The exact format of these special files
+ depends on the authentication protocol used.
+
+ Currently, rend-spec contains the proposition to encode client-side
+ authentication data in the URL, like in x.y.z.onion. This was never used
+ and is also a bad idea, because in case of HTTP the requested URL may be
+ contained in the Host and Referer fields.
+
+ 2 An authentication protocol based on group and user passwords
+
+ In the following we discuss an authentication protocol for the proposed
+ authentication architecture that performs authentication at all three
+ proposed authentication points. The protocol relies on two symmetrically
+ shared keys: a group key and a user key. The reason for this separation
+ as compared to using a single key for each user is the fact that the
+ number of descriptor cookies should be limited, so that the group key
+ will be used for authenticating at the directory, whereas two keys
+ derived from the user key will be used for performing authentication at
+ the introduction and the hidden service.
+
+ 2.1 Client authentication at directory
+
+ The server creates groups of users that shall be able to access his
+ service. He provides all users of a certain group with the same group key
+ which is a password of arbitrary length.
+
+ The group key is used as input to derive a 128 bit descriptor cookie from
+ it. We propose to apply a secure hash function and use the first 128 bits
+ of output:
+
+ descriptor-cookie = H(group-key)
+
+ Hence, there will be a distinct hidden service descriptor for every group
+ of users. All descriptors contain the same introduction points and the
+ authentication data required by the users of the given group. Whenever a
+ server decides to remove authentication for a group, he can simply stop
+ publishing hidden service descriptors using the descriptor cookie.
+
+ 2.2 Client authentication at introduction point
+
+ The idea for authenticating at the introduction point is borrowed from
+ authentication at the rendezvous point using a rendezvous cookie. A
+ rendezvous cookie is created by the client and encrypted for the server
+ in order to authenticate the server at the rendezvous point. Likewise,
+ the so-called introduction cookie is created by the server and encrypted
+ for the client in order to authenticate the client at the introduction
+ point.
+
+ More precise, the server creates a new introduction cookie when
+ establishing an introduction point and includes it in the ESTABLISH_INTRO
+ cell that it sends to the introduction point. This introduction cookie
+ will be used by all clients during the complete time of using this
+ introduction point. The server then encrypts the introduction cookie for
+ all authorized clients (as described in the next paragraph) and includes
+ it in the introduction-point-specific part of the hidden service
+ descriptor. A client reads and decrypts the introduction cookie from the
+ hidden service descriptor and includes it in the INTRODUCE1 cell that it
+ sends to the introduction point. The introduction point can then compare
+ the introduction cookie included in the INTRODUCE1 cell with the value
+ that it previously received in the ESTABLISH_INTRO cell. If both values
+ match, the introduction point passes the INTRODUCE2 cell to the hidden
+ service.
+
+ For the sake of simplicity, the size of an introduction cookie should be
+ only 16 bytes so that they can be encrypted using AES-128 without using
+ a block mode. Although rendezvous cookies are 20 bytes long, the 16 bytes
+ of an introduction cookie should still provide similar, or at least
+ sufficient security.
+
+ Encryption of the introduction cookie is done on a per user base. Every
+ client shares a password of arbitrary length with the server, which is
+ the so-called user key. The server derives a symmetric key from the
+ client's user key by applying a secure hash function and using the first
+ 128 bits of output as follows:
+
+ encryption-key = H(user-key | "INTRO")
+
+ It is important that the encryption key does not allow any inference on
+ the user key, because the latter will also be used for authentication at
+ the hidden service. This is ensured by applying the secure one-way
+ function H.
+
+ The 16 bytes long, symmetrically encrypted introduction cookies are
+ encoded in binary form in the authentication data object of a hidden
+ service descriptor. Additionally, for every client there is a 20 byte
+ long client identifier that is also derived from the user key, so that
+ the client can identify which value to decrypt. The client identifier is
+ determined as follows:
+
+ client-id = H(user-key | "CLIENT")
+
+ The authentication data encoded to the hidden service descriptor consists
+ of the concatenation of pairs consisting of 20 byte client identifiers
+ and 20 byte encrypted introduction cookies. The authentication type
+ number for the encrypted introduction cookies as well as for
+ ESTABLISH_INTRO and INTRODUCE1 cells is "1".
+
+ 2.3 Client authentication at hidden service
+
+ Authentication at the hidden service also makes use of the user key,
+ because whoever is authorized to pass the introduction point shall be
+ authorized to access the hidden service. Therefore, the server and client
+ derive a common value from the user key, which is called service cookie
+ and which is 20 bytes long:
+
+ service-cookie = H(user-key | "SERVICE")
+
+ The client is supposed to include this service cookie, preceded by the 20
+ bytes long client ID, in INTRODUCE2 cells that it sends to the server.
+ The server compares authentication data of incoming INTRODUCE2 cells with
+ the locally stored value that it would expect. The authentication type
+ number of this protocol for INTRODUCE2 cells is "1".
+
+ 2.4 Providing authentication data
+
+ The authentication data that needs to be provided by servers consists of
+ a number of group keys, each having a number of user keys assigned. These
+ data items could be provided by two new configuration options
+ "HiddenServiceAuthGroup group-name group-key" and "HiddenServiceAuthUser
+ user-name user-key" with the semantics that a group contains all users
+ directly following the group key definition and before reaching the next
+ group key definition for a hidden service.
+
+ On client side, authentication data also consists of a group and a user
+ key. Therefore, a new configuration option "HiddenServiceAuthClient
+ onion-address group-key user-key" could be introduced that could be
+ written to any place in the configuration file. Whenever the user would
+ try to access the given onion address, the given group and user key
+ would be used for authentication.
+
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.
+ In the following we want to discuss attacks and non-attacks by dishonest
+ entities in the presented infrastructure and specific protocol. These
+ security implications would have to be verified once more when adding
+ another protocol. The dishonest entities (theoretically) include the
+ hidden server itself, the authenticated clients, hidden service directory
+ nodes, introduction points, and rendezvous points. The relays that are
+ part of circuits used during protocol execution, but never learn about
+ the exchanged descriptors or cells by design, are not considered.
+ Obviously, this list makes no claim to be complete. The discussed attacks
+ are sorted by the difficulty to perform them, in ascending order,
+ starting with roles that everyone could attempt to take and ending with
+ partially trusted entities abusing the trust put in them.
- 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.
+ (1) A hidden service directory could attempt to conclude presence of a
+ server from the existence of a locally stored hidden service descriptor:
+ This passive attack is possible, because descriptors need to contain a
+ publicly visible signature of the server (see proposal 114 for a more
+ extensive discussion of the v2 descriptor format). A possible protection
+ would be to reduce the number of concurrently used descriptor cookies and
+ increase the number of hidden service directories in the network.
+
+ (2) An introduction point could try to identify the pseudonym of the
+ hidden service on behalf of which it operates: This is impossible by
+ design, because the service uses a fresh public key for every
+ establishment of an introduction point (see proposal 114) and the
+ introduction point receives a fresh introduction cookie, so that there is
+ no identifiable information about the service that the introduction point
+ could learn. The introduction point cannot even tell if client accesses
+ belong to the same client or not, nor can it know the total number of
+ authorized clients. The only information might be the pattern of
+ anonymous client accesses, but that is hardly enough to reliably identify
+ a specific server.
- Changing of access rights now involves all three authorization authorities
- depending on what changes should be made:
+ (3) An introduction point could want to learn the identities of accessing
+ clients: This is also impossible by design, because all clients use the
+ same introduction cookie for authentication at the introduction point.
- - 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.
+ (4) An introduction point could try to replay a correct INTRODUCE1 cell
+ to other introduction points of the same service, e.g. in order to force
+ the service to create a huge number of useless circuits: This attack is
+ not possible by design, because INTRODUCE1 cells need to contain an
+ introduction cookie that is different for every introduction point.
- - 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.
+ (5) An introduction point could attempt to replay a correct INTRODUCE2
+ cell to the hidden service, e.g. for the same reason as in the last
+ attack: This attack is very limited by the fact that a server will only
+ accept 3 INTRODUCE2 cells containing the same rendezvous cookie and drop
+ all further replayed cells.
- - 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.
+ (6) An introduction point could block client requests by sending either
+ positive or negative INTRODUCE_ACK cells back to the client, but without
+ forwarding INTRODUCE2 cells to the server: This attack is an annoyance
+ for clients, because they might wait for a timeout to elapse until trying
+ another introduction point. However, this attack is not introduced by
+ performing authentication and it cannot be targeted towards a specific
+ client. A countermeasure might be for the server to periodically perform
+ introduction requests to his own service to see if introduction points
+ are working correctly.
- 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.
+ (7) The rendezvous point could attempt to identify either server or
+ client: No, this remains impossible as it was before, because the
+ rendezvous cookie does not contain any identifiable information.
+
+ (8) An authenticated client could try to break the encryption keys of the
+ other authenticated clients that have their introduction cookies
+ encrypted in the hidden service descriptor: This known-plaintext attack
+ can be performed offline. The only useful countermeasure against it could
+ be safe passwords that are generated by Tor. However, the attack would
+ not be very useful as long as encryption keys do not reveal information
+ on the contained user key.
+
+ (9) An authenticated client could swamp the server with valid INTRODUCE1
+ and INTRODUCE2 cells, e.g. in order to force the service to create
+ useless circuits to rendezvous points; as opposed to an introduction
+ point replaying the same INTRODUCE2 cell, a client could include a new
+ rendezvous cookie for every request: The countermeasure for this attack
+ is the restriction to 10 connection establishments per client and hour.
- 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.
+ (10) An authenticated client could attempt to break the service cookie of
+ another authenticated client to obtain access at the hidden service: This
+ requires a brute-force online attack. There are no countermeasures
+ provided, but the question arises whether the outcome of this attack is
+ worth the cost. The service cookie from one authenticated client is as
+ good as from another, with the only exception of possible better QoS
+ properties of certain clients.
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.
+ An implementation of this proposal would require changes to hidden
+ servers and clients to process authentication data and encode and
+ understand the new formats. However, both servers and clients would
+ remain compatible to regular hidden services without authentication.
+ Further, the implementation of introduction points would have to be
+ changed, so that they understand the new cell versions and perform
+ authentication. But again, the new introduction points would remain
+ compatible to the existing hidden service protocol.