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: replaced misleading term "authentication" by "authorization", added some clarifications (comments by Sven Kaffille)

Browse Source 
svn:r12967
This commit is contained in:
Karsten Loesing 2007-12-25 11:34:29 +00:00
parent f6072c36c8
commit 506a02d485
1 changed files with 176 additions and 139 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -13,35 +13,38 @@ Change history:
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
24-Dec-2007 Replaced misleading term "authentication" by "authorization"
and added some clarifications (comments by Sven Kaffille)
Overview:
This proposal deals with a general infrastructure for performing
authentication and authorization of requests to hidden services at three
authentication points: (1) when downloading and decrypting parts of the
hidden service descriptor, (2) at the introduction point, and (3) at
Bob's onion proxy before contacting the rendezvous point. A service
provider will be able to restrict access to his service at these three
points to authorized clients only. Further, the proposal contains a first
instance of an authentication protocol for the presented infrastructure.
authorization (not necessarily implying authentication) of requests to
hidden services at three points: (1) when downloading and decrypting
parts of the hidden service descriptor, (2) at the introduction point,
and (3) at Bob's onion proxy before contacting the rendezvous point. A
service provider will be able to restrict access to his service at these
three points to authorized clients only. Further, the proposal contains a
first instance of an authorization protocol for the presented
infrastructure.
This proposal is based on v2 hidden service descriptors as described in
proposal 114 and introduced in version 0.2.0.10-alpha.
The proposal is structured as follows: The next section motivates the
integration of authentication mechanisms in the hidden service protocol.
Then we describe a general infrastructure for authentication in hidden
services, followed by a specific authentication protocol for this
integration of authorization mechanisms in the hidden service protocol.
Then we describe a general infrastructure for authorization in hidden
services, followed by a specific authorization protocol for this
infrastructure. At the end we discuss a number of attacks and non-attacks
as well as compatibility issues.
Motivation:
The major part of hidden services does not require client authentication
The major part of hidden services does not require client authorization
now and won't do so in the future. To the contrary, many clients would
not want to be (pseudonymously) identifiable by the service, but rather
use the service anonymously. These services are not addressed by this
proposal.
not want to be (pseudonymously) identifiable by the service (which
is unavoidable to some extend), but rather use the service
anonymously. These services are not addressed by this proposal.
However, there may be certain services which are intended to be accessed
by a limited set of clients only. A possible application might be a
@ -51,10 +54,10 @@ Motivation:
his buddies. Finally, a possible application would be a personal home
server that should be remotely accessed by its owner.
Performing authentication to a hidden service within the Tor network, as
Performing authorization for a hidden service within the Tor network, as
proposed here, offers a range of advantages compared to allowing all
client connections in the first instance and deferring authentication and
authorization to the transported protocol:
client connections in the first instance and deferring authorization to
the transported protocol:
(1) Reduced traffic: Unauthorized requests would be rejected as early as
possible, thereby reducing the overall traffic in the network generated
@ -65,11 +68,12 @@ Motivation:
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).
(3) Hiding activity: Apart from performing the actual authorization, a
service provider could also hide the mere presence of his service from
unauthorized clients when not providing hidden service descriptors to
them 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
@ -77,39 +81,48 @@ Motivation:
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.
(5) Protocol independence: 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.
As a disadvantage of performing authorization within the Tor network can
be seen that a hidden service cannot make use of authorization data in
the transported protocol. Tor hidden services were designed to be
independent of the transported protocol. Therefore it's only possible to
either grant or deny access to the whole service, but not to specific
resources of the service.
Authorization often implies authentication, i.e. proving one's identity.
However, when performing authorization 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.
However, trying to hide identity from the hidden service is a futile
task, because a client would never know if he is the only authorized
client and therefore perfectly identifiable. Therefore, hiding identity
from the hidden service is not aimed by this proposal.
The current implementation of hidden services does not provide any kind
of authentication. The hidden service descriptor version 2, introduced by
of authorization. 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
contain fields for authorization data, but those fields are neither
implemented nor do they suffice entirely.
Details:
1 General infrastructure for authentication to hidden services
1 General infrastructure for authorization to hidden services
We spotted three possible authentication points in the hidden service
We spotted three possible authorization points in the hidden service
protocol:
(1) when downloading and decrypting parts of the hidden service
@ -118,10 +131,9 @@ Details:
(3) at Bob's onion proxy before contacting the rendezvous point.
The general idea of this proposal is to allow service providers to
restrict access to all of these authentication points to authorized
clients only.
restrict access to all of these points to authorized clients only.
1.1 Client authentication at directory
1.1 Client authorization at directory
Since the implementation of proposal 114 it is possible to combine a
hidden service descriptor with a so-called descriptor cookie. If done so,
@ -138,18 +150,18 @@ Details:
H(permanent-id | H(time-period | descriptor-cookie | replica))
The second purpose of the descriptor cookie is to encrypt the list of
introduction points, including optional authentication data. Hence, the
introduction points, including optional authorization data. Hence, the
hidden service directories won't learn any introduction information from
storing a hidden service descriptor. This feature is implemented but
unused at the moment, so that this proposal will harness the advantages
of proposal 114.
The descriptor cookie can be used for authentication by keeping it secret
The descriptor cookie can be used for authorization by keeping it secret
from everyone but authorized clients. A service could then decide whether
to publish hidden service descriptors using that descriptor cookie later
on. An authorized client being aware of the descriptor cookie would be
able to download and decrypt the hidden service descriptor.
The number of concurrently used descriptor cookies for one hidden service
is not restricted. A service could use a single descriptor cookie for all
users, a distinct cookie per user, or something in between, like one
@ -158,9 +170,9 @@ Details:
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
infrastructure for authorization, 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
@ -171,41 +183,46 @@ Details:
(clients and servers would have to be upgraded anyway for using the new
features).
1.2 Client authentication at introduction point
1.2 Client authorization at introduction point
The next possible authentication point after downloading and decrypting
The next possible authorization 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
for authorization, 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
authorization 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.
not have authorization data to pass the introduction point or access the
service (such a situation might occur when authorization data for
authorization at the directory is not issued on a per-user base as
opposed to authorization data for authorization at the introduction
point).
It is important to note that the introduction point must be considered
untrustworthy, and therefore cannot replace authentication at the hidden
untrustworthy, and therefore cannot replace authorization at the hidden
service itself. Nor should the introduction point learn any sensitive
identifiable information from either server or client.
In order to perform authentication at the introduction point, three
In order to perform authorization at the introduction point, three
message formats need to be modified: (1) v2 hidden service descriptors,
(2) ESTABLISH_INTRO cells, and (3) INTRODUCE1 cells.
A v2 hidden service descriptor needs to contain authentication data that
is introduction-point-specific and sometimes also authentication data
A v2 hidden service descriptor needs to contain authorization data that
is introduction-point-specific and sometimes also authorization data
that is introduction-point-independent. Therefore, v2 hidden service
descriptors as specified in section 1.2 of rend-spec already contain two
reserved fields "intro-authentication" and "service-authentication"
containing an authentication type number and arbitrary authentication
data. We propose that authentication data consists of base64 encoded
reserved fields "intro-authorization" and "service-authorization"
(originally, the names of these fields were "...-authentication")
containing an authorization type number and arbitrary authorization
data. We propose that authorization 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.
The current ESTABLISH_INTRO cells as described in section 1.3 of
rend-spec don't contain either authentication data or version
rend-spec don't contain either authorization data or version
information. Therefore, we propose a new version 1 of the ESTABLISH_INTRO
cells adding these two issues as follows:
@ -220,10 +237,10 @@ Details:
SIG Signature of above information [variable]
From the format it is possible to determine the maximum allowed size for
authentication data: given the fact that cells are 512 octets long, of
authorization 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
authorization data. Hence, authorization 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
@ -233,11 +250,11 @@ Details:
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
authorization. We propose to use the version number that is contained in
networkstatus documents to find capable introduction points.
The current INTRODUCE1 cells as described in section 1.8 of rend-spec is
not designed to carry authentication data and has no version number, too.
not designed to carry authorization data and has no version number, too.
We propose the following version 1 of INTRODUCE1 cells:
Cleartext
@ -249,7 +266,7 @@ Details:
Encrypted to Bob's PK:
(RELAY_INTRODUCE2 cell)
The maximum length of contained authentication data depends on the length
The maximum length of contained authorization data depends on the length
of the contained INTRODUCE2 cell. A calculation follows below when
describing the INTRODUCE2 cell format we propose to use.
@ -265,18 +282,18 @@ Details:
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.)
be used to accept both v0 and v1 INTRODUCE1 cells for the same service.
(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
1.3 Client authorization 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
the last possible authorization point during the hidden service
protocol. Performing authorization here is easier than at the other two
authorization points, because there are no possibly untrusted entities
involved.
In general, a client that is successfully authorized at the introduction
@ -286,15 +303,15 @@ Details:
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.
zero. However, this does not lead to the conclusion, that the
authorization data used at the introduction point and the hidden service
must be the same, but only that both authorization data should lead to
the same authorization result.
Authentication data is transmitted from client to server via an
Authorization 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
contains fields for carrying authorization 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
@ -314,18 +331,18 @@ Details:
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
The maximum possible length of authorization 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
1024 bit = 128 octets long public keys without any authorization 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
authorization 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
provided valid authorization data to him. He will only then build a
circuit to the provided rendezvous point and otherwise will drop the
cell.
@ -346,62 +363,63 @@ Details:
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
1.4 Summary of authorization data fields
In summary, the proposed descriptor format and cell formats provide the
following fields for carrying authentication data:
following fields for carrying authorization 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).
- an arbitrary encryption schema to ensure authorization to access
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
(2) For performing authorization at the introduction point we can use:
- the fields intro-authorization and service-authorization 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
(3) For performing authorization at the hidden service we can use:
- the fields intro-authorization and service-authorization 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.
authorization or only use a part of the authorization infrastructure.
However, this requires to consider all parts of the infrastructure. For
example, authorization at the introduction point relying on confidential
intro-authorization 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
1.5 Managing authorization data at servers and clients
In order to provide authentication data at the hidden server and the
In order to provide authorization 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.
depends on the authorization 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
authorization 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
2 An authorization 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
In the following we discuss an authorization protocol for the proposed
authorization architecture that performs authorization at all three
proposed authorization 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
derived from the user key will be used for performing authorization at
the introduction and the hidden service.
2.1 Client authentication at directory
2.1 Client authorization 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
@ -415,14 +433,14 @@ Details:
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
authorization data required by the users of the given group. Whenever a
server decides to remove authorization for a group, he can simply stop
publishing hidden service descriptors using the descriptor cookie.
2.2 Client authentication at introduction point
2.2 Client authorization at introduction point
The idea for authenticating at the introduction point is borrowed from
authentication at the rendezvous point using a rendezvous cookie. A
authorization 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
@ -449,7 +467,7 @@ Details:
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
@ -459,12 +477,12 @@ Details:
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 user key, because the latter will also be used for authorization 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
encoded in binary form in the authorization 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
@ -472,15 +490,15 @@ Details:
client-id = H(user-key | "CLIENT")
The authentication data encoded to the hidden service descriptor consists
The authorization 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
and 16 byte encrypted introduction cookies. The authorization 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
2.3 Client authorization at hidden service
Authentication at the hidden service also makes use of the user key,
Authorization 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
@ -490,13 +508,27 @@ Details:
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
The server compares authorization data of incoming INTRODUCE2 cells with
the locally stored value that it would expect. The authorization type
number of this protocol for INTRODUCE2 cells is "1".
2.4 Providing authentication data
Passing a derived value of a client's user key will make clients
identifiable to the hidden service. Although there might be ways to limit
identifiability, an authorized client can never be sure that he stays
anonymous to the hidden service. For example, if we created a service
cookie that is the same for all users and encrypted it for all users, and
if we further included a checksum of this service cookie in the
descriptor to prove that all users have the same value, a client would
never know if he is the only valid user contained in this descriptor,
with the other users only be fakes created by the hidden service.
Therefore, we did not make attempts to hide a client's identity from a
hidden service. Another reason was that we would not be able to apply a
connection limit of 10 requests per hour and user that helps prevent some
threats.
The authentication data that needs to be provided by servers consists of
2.4 Providing authorization data
The authorization 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
@ -504,12 +536,12 @@ Details:
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
On client side, authorization 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.
would be used for authorization.
Security implications:
@ -533,8 +565,13 @@ Security implications:
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
(2) A hidden service directory could try to break the descriptor cookies
of locally stored descriptors: This attack can be performed offline. The
only useful countermeasure against it might be using safe passwords that
are generated by Tor.
(3) 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
@ -546,52 +583,52 @@ Security implications:
anonymous client accesses, but that is hardly enough to reliably identify
a specific server.
(3) An introduction point could want to learn the identities of accessing
(4) An introduction point could want to learn the identities of accessing
clients: This is also impossible by design, because all clients use the
same introduction cookie for authentication at the introduction point.
same introduction cookie for authorization at the introduction point.
(4) An introduction point could try to replay a correct INTRODUCE1 cell
(5) An introduction point could try to replay a correct INTRODUCE1 cell
to other introduction points of the same service, e.g. in order to force
the service to create a huge number of useless circuits: This attack is
not possible by design, because INTRODUCE1 cells need to contain an
introduction cookie that is different for every introduction point.
(5) An introduction point could attempt to replay a correct INTRODUCE2
(6) An introduction point could attempt to replay a correct INTRODUCE2
cell to the hidden service, e.g. for the same reason as in the last
attack: This attack is very limited by the fact that a server will only
accept 3 INTRODUCE2 cells containing the same rendezvous cookie and drop
all further replayed cells.
(6) An introduction point could block client requests by sending either
(7) An introduction point could block client requests by sending either
positive or negative INTRODUCE_ACK cells back to the client, but without
forwarding INTRODUCE2 cells to the server: This attack is an annoyance
for clients, because they might wait for a timeout to elapse until trying
another introduction point. However, this attack is not introduced by
performing authentication and it cannot be targeted towards a specific
performing authorization 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.
(7) The rendezvous point could attempt to identify either server or
(8) The rendezvous point could attempt to identify either server or
client: No, this remains impossible as it was before, because the
rendezvous cookie does not contain any identifiable information.
(8) An authenticated client could try to break the encryption keys of the
(9) 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
(10) 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
(11) 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
@ -602,11 +639,11 @@ Security implications:
Compatibility:
An implementation of this proposal would require changes to hidden
servers and clients to process authentication data and encode and
servers and clients to process authorization data and encode and
understand the new formats. However, both servers and clients would
remain compatible to regular hidden services without authentication.
remain compatible to regular hidden services without authorization.
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
authorization. But again, the new introduction points would remain
compatible to the existing hidden service protocol.