nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-28 06:13: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

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

@ -11,221 +11,206 @@ 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.
[Removed public-key authentication protocol. -KL] 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).
After validating the provided "AUTHD" Bob builds a circuit to the Although this part of the proposal is meant to describe a general
rendezvous point and starts interacting with Alice. If Bob cannot infrastructure for authentication, changing the way of using the
identify the client he must refuse the request by not connecting to the descriptor cookie to look up hidden service descriptors, e.g. applying
rendezvous point. some sort of asymmetric crypto system, would require in-depth changes
[XXX Bob should discard an IPo after a certain number of cells containing that would be incompatible to v2 hidden service descriptors. On the
bad auth data. But any denouncement by other IPos or clients, e.g. by contrary, using another key for en-/decrypting the introduction point
replaying cells, must be inhibited. Maybe Bob should keep a history of part of a hidden service descriptor, e.g. a different symmetric key or
connection attempts within a certain time and discard an IPo after a asymmetric encryption, would be easy to implement and compatible to v2
specific threshold. And maybe authentication to the service should be hidden service descriptors as understood by hidden service directories
based on a nonce, so that the service can differentiate between a replay (clients and servers would have to be upgraded anyway for using the new
attack by an introduction point and regular reconnection attempts. More features).
thoughts needed here. -KL]
It will also still be possible to establish v2 hidden services without 1.2 Client authentication at introduction point
authentication. Therefore the "AUTHT" field must be set to "0". "AUTHL"
and "AUTHD" are not provided by the client in that case.
/2/ Client authentication at the introduction point 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.
In addition to authentication at the HS OP, the IPo should be able to It is important to note that the introduction point must be considered
detect and abandon all unauthorized requests. This would help to raise untrustworthy, and therefore cannot replace authentication at the hidden
the level of privacy and therefore also the level of security for Bob by service itself. Nor should the introduction point learn any sensitive
better hiding his online activity from unauthorized users. Especially if identifiable information from either server or client.
Alice still has access to the secret cookie. This can be the case if she
had access to the service earlier, but is no longer authorized or the
directory is outdated. Another advantage of this additional "gate keeper"
would be reduced traffic in the network, because unauthorized requests
could already be detected and declined at the IPo.
It is important to notice that the IPo may not be trustworthy, and In order to perform authentication at the introduction point, three
therefore can not replace authentication at the HS OP itself. Nor should message formats need to be modified: (1) v2 hidden service descriptors,
the IPo get hold of critical authentication information (because it could (2) ESTABLISH_INTRO cells, and (3) INTRODUCE1 cells.
try to access the service itself).
A challenge-response authentication protocol is used to address these A v2 hidden service descriptor needs to contain authentication data that
issues. This means that a challenge is needed to be solved by Alice to is introduction-point-specific and sometimes also authentication data
get forwarded to Bob by the IPo. 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.
Two types of authentication are supported and need to be preconfigured by The current ESTABLISH_INTRO cells as described in section 1.3 of
Bob when creating the service: password and public-key authentication. rend-spec don't contain either authentication data or version
Again it is up to Alice what kind of authentication mechanism she wants information. Therefore, we propose a new version 1 of the ESTABLISH_INTRO
to use, given that Bob knows both her password and her public key. cells adding these two issues as follows:
If Alice uses a password to authenticate herself at the IPo, the
authentication is based on a symmetric challenge-response authentication
protocol. In this case the challenge for Alice is to send h(x|y) where x
is a user-specific password, which should be different from the password
needed for authentication at the hidden service and y is a randomly
generated value. Alice gets hold of her password out of band.
With the initial RELAY_ESTABLISH_INTRO cell, the IPo gets a list of
h(x|y)'s which it stores locally. Upon a request of Alice it compares her
provided authentication data with the list entries. If there is a
matching entry in its list, Alice's request is valid and can be forwarded
to Bob. To generate the hash, Alice needs to know the password (which she
will get out of band) and the random value y. This value is contained in
the cookie-encrypted part of the hidden service descriptor which Alice
can retrieve from the directory using her secret cookie.
(1) Alice creates a password x and sends the password digest h(x) to Bob
out of band.
(2) Bob creates a random value y, computes h(h(x)|y), and sends the
result to the introduction point.
[XXX There should be a separate y for each introduction point, so
that none of them may impersonate Alice to any of the other
introduction points. -KL]
(3) Bob encrypts y with a secret cookie (see proposal 114) and writes it
to a rendezvous service descriptor.
(4) Alice fetches Bob's rendezvous service descriptor, decrypts y using
the secret cookie (see proposal 114), computes h(h(x)|y), encrypts
it with the public key of the introduction point, and sends it to
that introduction point.
(5) The introduction point decrypts h(h(x)|y) from Alice's message and
compares it to the value it knows from Bob (from step 2).
[Removed public-key authentication protocol. -KL]
To remove a user from a group, Bob needs to update the random value list
at the IPo's.
The changes needed in Tor to realize these two challenge-response
variations affect the RELAY_ESTABLISH_INTRO and RELAY_INTRODUCE1 relay
cells, the service descriptor and the code parts in Tor where these cells
and the descriptor are handled.
The RELAY_ESTABLISH_INTRO cell is now structured as follows:
V Format byte: set to 255 [1 octet] V Format byte: set to 255 [1 octet]
V Version byte: set to 2 [1 octet] V Version byte: set to 1 [1 octet]
KL Key length [2 octets] KL Key length [2 octets]
PK Bob's public key [KL octets] PK Bob's public key [KL octets]
HS Hash of session info [20 octets] HS Hash of session info [20 octets]
@ -234,103 +219,394 @@ Details:
AUTHD Auth data [variable] AUTHD Auth data [variable]
SIG Signature of above information [variable] SIG Signature of above information [variable]
"AUTHT" is set to "1" for password/public-key authentication. From the format it is possible to determine the maximum allowed size for
"AUTHD" is a list of 20 octet long challenges for clients. 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.
The service descriptor as specified in 114-distributed-storage is used in In order to understand a v1 ESTABLISH_INTRO cell, the implementation of
our implementation. 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.
For password authentication "authentication" auth-type is set to "1" and The current INTRODUCE1 cells as described in section 1.8 of rend-spec is
auth-data contains the 20 octets long string used by clients to construct not designed to carry authentication data and has no version number, too.
the response to the challenge for authentication at the IPo. We propose the following version 1 of INTRODUCE1 cells:
When using public-key authentication the auth-type is set to "2" and
auth-data holds a list of 148 octets long blank separated values. The
first 20 octets of each value is the hash of the public key of a certain
client and used by Alice to determine her entry in the list. The
remaining 128 octets contain the PK-encrypted token needed to
authenticate to the IPo.
[XXX Handle space limitation problem, either by using fewer space, by
sending multiple cells, or by finding a protocol that is
space-independent here. -KL]
The part of the RELAY_INTRODUCE1 cell that can be read by the IPo has the
following fields added:
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] AUTHT The auth type that is supported [1 octet]
AUTHL Length of auth data [1 octets] AUTHL Length of auth data [2 octets]
AUTHD Auth data [variable] AUTHD Auth data [variable]
[XXX Insert a version field, so that we won't be facing the same problems Encrypted to Bob's PK:
again when specifying the next version of INTRODUCE1 cells. -KL] (RELAY_INTRODUCE2 cell)
The AUTHT and AUTHL fields are provided to allow extensions of the The maximum length of contained authentication data depends on the length
protocol. Currently, we set AUTHT to 1 for password/public-key of the contained INTRODUCE2 cell. A calculation follows below when
authentication and AUTHL to 20 for the length of the authorization token. describing the INTRODUCE2 cell format we propose to use.
[XXX Insert file format containing auth data here. -KL] 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.
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.)
1.3 Client authentication at hidden service
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.
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.
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:
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]
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.
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.
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:
(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.
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.
Changing of access rights now involves all three authorization authorities (2) An introduction point could try to identify the pseudonym of the
depending on what changes should be made: 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.
- The user configures his changes at the local OP. Therefore he can (3) An introduction point could want to learn the identities of accessing
edit the cookie files that were extended to support multiple users. clients: This is also impossible by design, because all clients use the
Moreover he can edit the new user files that were added to specify same introduction cookie for authentication at the introduction point.
authentication information for every user.
- Whenever local changes occur, this information needs to be either (4) An introduction point could try to replay a correct INTRODUCE1 cell
passed to the responsible IPo's, the directory servers, or both to other introduction points of the same service, e.g. in order to force
depending on the authorization method and operation used. It is the service to create a huge number of useless circuits: This attack is
important to have consistent authorization results at all authorities not possible by design, because INTRODUCE1 cells need to contain an
at the same time, to create a trustworthy system with good user introduction cookie that is different for every introduction point.
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 (5) An introduction point could attempt to replay a correct INTRODUCE2
group management in our implementation as their use would be far to cell to the hidden service, e.g. for the same reason as in the last
costly for a user-based authorization. That is because right now one attack: This attack is very limited by the fact that a server will only
descriptor is generated and uploaded for every secret cookie. Changes accept 3 INTRODUCE2 cells containing the same rendezvous cookie and drop
in this configuration should therefore be rare (maybe never) and only all further replayed cells.
a few groups should exist. Provided that this is the case the costs
for changes seem acceptable. As there is currently no possibility to
make a directory remove the descriptor for a group an updated
descriptor without any IPo should be uploaded to the directory
servers.
Local changes to access rights can now be done faster than by changing (6) An introduction point could block client requests by sending either
service descriptors which reduces the directory server load and network positive or negative INTRODUCE_ACK cells back to the client, but without
traffic. Still every configuration change remains costly and users should forwarding INTRODUCE2 cells to the server: This attack is an annoyance
carefully choose how detailed the access right configuration should be. 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.
Attacking clients now need to bypass two more authentication steps to (7) The rendezvous point could attempt to identify either server or
reach the service implementation. Compared to the current state it is client: No, this remains impossible as it was before, because the
more likely that attackers can be stopped even before they are able to rendezvous cookie does not contain any identifiable information.
contact Bob's OP. We expect that the possibility of an attack is thereby
significantly reduced. Another positive side effect is that network (8) An authenticated client could try to break the encryption keys of the
traffic and router load is reduced by discarding unauthorized cells which other authenticated clients that have their introduction cookies
should lower the effectiveness of denial of service attacks. 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.
(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: 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.