nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-27 22:03:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

proposal 121: rewrote complete proposal for better readability, modified authentication protocol, merged in personal notes

Browse Source 
svn:r12824
This commit is contained in:
Karsten Loesing 2007-12-15 20:09:43 +00:00
parent f50cd72848
commit 5864b43e02
1 changed files with 540 additions and 264 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

804
doc/spec/proposals/121-hidden-service-authentication.txt
View File

@ -11,326 +11,602 @@ Change history:
26-Sep-2007 Initial proposal for or-dev 26-Sep-2007 Initial proposal for or-dev
08-Dec-2007 Incorporated comments by Nick posted to or-dev on 10-Oct-2007 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: Overview:
This proposal deals with some possibilities to implement authentication This proposal deals with a general infrastructure for performing
for restricted access to hidden services. This way we try to increase the authentication and authorization of requests to hidden services at three
security level for the service provider (Bob) by giving him the ability authentication points: (1) when downloading and decrypting parts of the
to exclude non-authorized users from using his service. It is based on hidden service descriptor, (2) at the introduction point, and (3) at
proposal 114-distributed-storage but is better suited for a fine grained Bob's onion proxy before contacting the rendezvous point. A service
way of authentication, because it is less resource-consuming. Whenever we provider will be able to restrict access to his service at these three
refer to service descriptors and cell formats, we are talking about the points to authorized clients only. Further, the proposal contains a first
definitions found in 114-distributed-storage unless otherwise stated. instance of an authentication protocol for the presented infrastructure.
We discuss password and public-key authentication for the Onion Proxy This proposal is based on v2 hidden service descriptors as described in
(OP) of Bob's hidden service (HS). Furthermore a challenge-response proposal 114 and introduced in version 0.2.0.10-alpha.
authentication mechanism is introduced at the introduction point.
These modifications aim at: The proposal is structured as follows: The next section motivates the
- increasing the security of hidden services by limiting access only to integration of authentication mechanisms in the hidden service protocol.
authorized users (specification see details) and Then we describe a general infrastructure for authentication in hidden
- reducing the traffic in the network by rejecting unauthorized access services, followed by a specific authentication protocol for this
requests earlier. infrastructure. At the end we discuss a number of attacks and non-attacks
as well as compatibility issues.
Motivation: Motivation:
The currently used implementation of hidden services does not provide any The major part of hidden services does not require client authentication
kind of authentication. The v2 implementation adds an authentication now and won't do so in the future. To the contrary, many clients would
mechanism at the directory server. Security can be further improved by not want to be (pseudonymously) identifiable by the service, but rather
adding two more authentication authorities at the introduction point use the service anonymously. These services are not addressed by this
(IPo) and the OP. proposal.
Although the service descriptors are already designed to carry However, there may be certain services which are intended to be accessed
authentication information the existing fields are not used so far. by a limited set of clients only. A possible application might be a
Moreover one can find a couple of notes at the specification of cell wiki or forum that should only be accessible for a closed user group.
formats (rend-spec) which point at adding authentication information but Another, less intuitive example might be a real-time communication
no fields are specified yet. It would be preferable to extend the Tor service, where someone provides a presence and messaging service only to
network with authentication features to offer a solution for all his buddies. Finally, a possible application would be a personal home
services. This would also provide means to authorize access to services server that should be remotely accessed by its owner.
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 Performing authentication to a hidden service within the Tor network, as
users, who still have access to the secret cookie (see proposed here, offers a range of advantages compared to allowing all
114-distributed-storage) but should no longer be authorized. Bob can now client connections in the first instance and deferring authentication and
not only hide his location, but also to a certain degree his presence authorization to the transported protocol:
towards unauthorized clients given that none of his IPo's are corrupted.
(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: Details:
[XXX Restructure this section in separate patch: 1 General infrastructure for authentication to hidden services
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 We spotted three possible authentication points in the hidden service
directory". Optional encryption/decryption using a descriptor cookie is protocol:
understood since proposal 114, but not used by servers and clients. -KL]
/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 The general idea of this proposal is to allow service providers to
be considered as a form of authentication, and a service ID is able to restrict access to all of these authentication points to authorized
connect to Bob if he is online. He can not distinguish between Alice clients only.
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 1.1 Client authentication at directory
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 Since the implementation of proposal 114 it is possible to combine a
(symmetric secret) authentication. "AUTHT" is set to "1" for this hidden service descriptor with a so-called descriptor cookie. If done so,
authentication method while the "AUTHL" field is set to "20", the length the descriptor cookie becomes part of the descriptor ID, thus having an
of the SHA-1 digest of the password. 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 descriptor-id =
out of band. H(permanent-id | H(time-period | descriptor-cookie | replica))
[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 The second purpose of the descriptor cookie is to encrypt the list of
of weak passwords that are vulnerable to dictionary or brute-force introduction points, including optional authentication data. Hence, the
attacks. Nevertheless it seems to be an appropriate solution since safe hidden service directories won't learn any introduction information from
passwords can be randomly generated by Tor. Cracking methods that rely on storing a hidden service descriptor. This feature is implemented but
guessing passwords should not be effective in the constantly changing unused at the moment, so that this proposal will harness the advantages
network infrastructure. A usability advantage is that this method is easy of proposal 114.
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 The descriptor cookie can be used for authentication by keeping it secret
password to Alice -- or the other way around -- outside Tor. from everyone but authorized clients. A service could then decide whether
If at the same time the secret cookie is to publish hidden service descriptors using that descriptor cookie later
transmitted and the message is intercepted the attacker can gain access on. An authorized client being aware of the descriptor cookie would be
to the service. Therefore, a secure way to exchange this information must able to download and decrypt the hidden service descriptor.
be established.
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 The next possible authentication point after downloading and decrypting
rendezvous point and starts interacting with Alice. If Bob cannot a hidden service descriptor is the introduction point. It is important
identify the client he must refuse the request by not connecting to the for authentication, because it bears the last chance of hiding presence
rendezvous point. of a hidden service from unauthorized clients. Further, performing
[XXX Bob should discard an IPo after a certain number of cells containing authentication at the introduction point might reduce traffic in the
bad auth data. But any denouncement by other IPos or clients, e.g. by network, because unauthorized requests would not be passed to the
replaying cells, must be inhibited. Maybe Bob should keep a history of hidden service. This applies to those clients who are aware of a
connection attempts within a certain time and discard an IPo after a descriptor cookie and thereby of the hidden service descriptor, but do
specific threshold. And maybe authentication to the service should be not have authorization data to access the service.
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 It is important to note that the introduction point must be considered
authentication. Therefore the "AUTHT" field must be set to "0". "AUTHL" untrustworthy, and therefore cannot replace authentication at the hidden
and "AUTHD" are not provided by the client in that case. 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 A v2 hidden service descriptor needs to contain authentication data that
detect and abandon all unauthorized requests. This would help to raise is introduction-point-specific and sometimes also authentication data
the level of privacy and therefore also the level of security for Bob by that is introduction-point-independent. Therefore, v2 hidden service
better hiding his online activity from unauthorized users. Especially if descriptors as specified in section 1.2 of rend-spec already contain two
Alice still has access to the secret cookie. This can be the case if she reserved fields "intro-authentication" and "service-authentication"
had access to the service earlier, but is no longer authorized or the containing an authentication type number and arbitrary authentication
directory is outdated. Another advantage of this additional "gate keeper" data. We propose that authentication data consists of base64 encoded
would be reduced traffic in the network, because unauthorized requests objects of arbitrary length, surrounded by "-----BEGIN MESSAGE-----" and
could already be detected and declined at the IPo. "-----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 The current ESTABLISH_INTRO cells as described in section 1.3 of
therefore can not replace authentication at the HS OP itself. Nor should rend-spec don't contain either authentication data or version
the IPo get hold of critical authentication information (because it could information. Therefore, we propose a new version 1 of the ESTABLISH_INTRO
try to access the service itself). cells adding these two issues as follows:
A challenge-response authentication protocol is used to address these V Format byte: set to 255 [1 octet]
issues. This means that a challenge is needed to be solved by Alice to V Version byte: set to 1 [1 octet]
get forwarded to Bob by the IPo. 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 From the format it is possible to determine the maximum allowed size for
Bob when creating the service: password and public-key authentication. authentication data: given the fact that cells are 512 octets long, of
Again it is up to Alice what kind of authentication mechanism she wants which 498 octets are usable (see section 6.1 of tor-spec), and assuming
to use, given that Bob knows both her password and her public key. 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 In order to understand a v1 ESTABLISH_INTRO cell, the implementation of
authentication is based on a symmetric challenge-response authentication a relay must have a certain Tor version, which would probably be some
protocol. In this case the challenge for Alice is to send h(x|y) where x 0.2.1.x. Hidden services need to be able to distinguish relays being
is a user-specific password, which should be different from the password capable of understanding the new v1 cell formats and perform
needed for authentication at the hidden service and y is a randomly authentication. We propose to use the version number that is contained in
generated value. Alice gets hold of her password out of band. networkstatus documents to find capable introduction points.
With the initial RELAY_ESTABLISH_INTRO cell, the IPo gets a list of The current INTRODUCE1 cells as described in section 1.8 of rend-spec is
h(x|y)'s which it stores locally. Upon a request of Alice it compares her not designed to carry authentication data and has no version number, too.
provided authentication data with the list entries. If there is a We propose the following version 1 of INTRODUCE1 cells:
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 Cleartext
out of band. V Version byte: set to 1 [1 octet]
(2) Bob creates a random value y, computes h(h(x)|y), and sends the PK_ID Identifier for Bob's PK [20 octets]
result to the introduction point. AUTHT The auth type that is supported [1 octet]
[XXX There should be a separate y for each introduction point, so AUTHL Length of auth data [2 octets]
that none of them may impersonate Alice to any of the other AUTHD Auth data [variable]
introduction points. -KL] Encrypted to Bob's PK:
(3) Bob encrypts y with a secret cookie (see proposal 114) and writes it (RELAY_INTRODUCE2 cell)
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] 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 Unfortunately, v0 INTRODUCE1 cells consist only of a fixed-size,
at the IPo's. 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 Processing of v1 INTRODUCE1 cells therefore requires knowledge about the
variations affect the RELAY_ESTABLISH_INTRO and RELAY_INTRODUCE1 relay context in which they are used. As a result, we propose that when
cells, the service descriptor and the code parts in Tor where these cells receiving a v1 ESTABLISH_INTRO cell, an introduction point only accepts
and the descriptor are handled. 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] The time when a hidden service receives an INTRODUCE2 cell constitutes
V Version byte: set to 2 [1 octet] the last possible authentication point during the hidden service
KL Key length [2 octets] protocol. Performing authentication here is easier than at the other two
PK Bob's public key [KL octets] authentication points, because there are no possibly untrusted entities
HS Hash of session info [20 octets] involved.
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. In general, a client that is successfully authorized at the introduction
"AUTHD" is a list of 20 octet long challenges for clients. 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 Authentication data is transmitted from client to server via an
our implementation. 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 VER Version byte: set to 3. [1 octet]
auth-data contains the 20 octets long string used by clients to construct ATYPE An address type (typically 4) [1 octet]
the response to the challenge for authentication at the IPo. 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 The maximum possible length of authentication data is related to the
auth-data holds a list of 148 octets long blank separated values. The enclosing INTRODUCE1 cell. A v3 INTRODUCE2 cell with IPv6 address and
first 20 octets of each value is the hash of the public key of a certain 1024 bit = 128 octets long public keys without any authentication data
client and used by Alice to determine her entry in the list. The occupies 321 octets, plus 58 octets for hybrid public key encryption (see
remaining 128 octets contain the PK-encrypted token needed to section 5.1 of tor-spec on hybrid encryption of CREATE cells). The
authenticate to the IPo. surrounding v1 INTRODUCE1 cell requires 24 octets. This leaves only 95
[XXX Handle space limitation problem, either by using fewer space, by of the 498 available octets free, which must be shared between
sending multiple cells, or by finding a protocol that is authentication data to the introduction point _and_ to the hidden
space-independent here. -KL] service.
The part of the RELAY_INTRODUCE1 cell that can be read by the IPo has the When receiving a v3 INTRODUCE2 cell, Bob checks whether a client has
following fields added: 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] There might be several attacks based on the idea of replaying existing
AUTHL Length of auth data [1 octets] cells to the hidden service. In particular, someone (the introduction
AUTHD Auth data [variable] point or an evil authenticated client) might replay valid INTRODUCE2
[XXX Insert a version field, so that we won't be facing the same problems cells to make the hidden service build an arbitrary number of circuits to
again when specifying the next version of INTRODUCE1 cells. -KL] (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 (1) a maximum of 3 cells coming from the same client and containing the
protocol. Currently, we set AUTHT to 1 for password/public-key same rendezvous cookie, and
authentication and AUTHL to 20 for the length of the authorization token. (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: Security implications:
In addition to the security features proposed in 114-distributed-storage In the following we want to discuss attacks and non-attacks by dishonest
a new way of authentication is added at the OP of Bob. Moreover, the entities in the presented infrastructure and specific protocol. These
authentication at the IPo's is improved to support a fine-grained access security implications would have to be verified once more when adding
control. Corrupted IPo's may easily bypass this authentication, but given another protocol. The dishonest entities (theoretically) include the
the case that the majority of IPo's is acting as expected we still hidden server itself, the authenticated clients, hidden service directory
consider this feature as being useful. 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 (1) A hidden service directory could attempt to conclude presence of a
not. This gives him the possibility to offer his services only to known server from the existence of a locally stored hidden service descriptor:
and trusted users that need to identify by a password or by signing their This passive attack is possible, because descriptors need to contain a
messages. The anonymity of the client towards the service provider is publicly visible signature of the server (see proposal 114 for a more
thereby reduced to pseudonymity. 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 (3) An introduction point could want to learn the identities of accessing
depending on what changes should be made: 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 (4) An introduction point could try to replay a correct INTRODUCE1 cell
edit the cookie files that were extended to support multiple users. to other introduction points of the same service, e.g. in order to force
Moreover he can edit the new user files that were added to specify the service to create a huge number of useless circuits: This attack is
authentication information for every user. 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 (5) An introduction point could attempt to replay a correct INTRODUCE2
passed to the responsible IPo's, the directory servers, or both cell to the hidden service, e.g. for the same reason as in the last
depending on the authorization method and operation used. It is attack: This attack is very limited by the fact that a server will only
important to have consistent authorization results at all authorities accept 3 INTRODUCE2 cells containing the same rendezvous cookie and drop
at the same time, to create a trustworthy system with good user all further replayed cells.
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 (6) An introduction point could block client requests by sending either
group management in our implementation as their use would be far to positive or negative INTRODUCE_ACK cells back to the client, but without
costly for a user-based authorization. That is because right now one forwarding INTRODUCE2 cells to the server: This attack is an annoyance
descriptor is generated and uploaded for every secret cookie. Changes for clients, because they might wait for a timeout to elapse until trying
in this configuration should therefore be rare (maybe never) and only another introduction point. However, this attack is not introduced by
a few groups should exist. Provided that this is the case the costs performing authentication and it cannot be targeted towards a specific
for changes seem acceptable. As there is currently no possibility to client. A countermeasure might be for the server to periodically perform
make a directory remove the descriptor for a group an updated introduction requests to his own service to see if introduction points
descriptor without any IPo should be uploaded to the directory are working correctly.
servers.
Local changes to access rights can now be done faster than by changing (7) The rendezvous point could attempt to identify either server or
service descriptors which reduces the directory server load and network client: No, this remains impossible as it was before, because the
traffic. Still every configuration change remains costly and users should rendezvous cookie does not contain any identifiable information.
carefully choose how detailed the access right configuration should be.
(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 (10) An authenticated client could attempt to break the service cookie of
reach the service implementation. Compared to the current state it is another authenticated client to obtain access at the hidden service: This
more likely that attackers can be stopped even before they are able to requires a brute-force online attack. There are no countermeasures
contact Bob's OP. We expect that the possibility of an attack is thereby provided, but the question arises whether the outcome of this attack is
significantly reduced. Another positive side effect is that network worth the cost. The service cookie from one authenticated client is as
traffic and router load is reduced by discarding unauthorized cells which good as from another, with the only exception of possible better QoS
should lower the effectiveness of denial of service attacks. properties of certain clients.
Compatibility: Compatibility:
When using our authentication for hidden services the implementation of An implementation of this proposal would require changes to hidden
IPo's needs to be extended. Therefore we use version information provided servers and clients to process authentication data and encode and
in router descriptors to be sure that we only send modified understand the new formats. However, both servers and clients would
RELAY_ESTABLISH_INTRO cells to routers that can handle them. Clients and remain compatible to regular hidden services without authentication.
service providers will have to update their Tor installation if they
want to be able to use the service.
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.