mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 21:23:58 +01:00
r15381@catbus: nickm | 2007-09-26 10:48:00 -0400
Add hidden-service-authentication.etxt as proposal 121. svn:r11653
This commit is contained in:
parent
3349c77b2f
commit
d87a91b822
@ -43,6 +43,7 @@ Proposals by number:
|
||||
118 Advertising multiple ORPorts at once [NEEDS-RESEARCH]
|
||||
119 New PROTOCOLINFO command for controllers [CLOSED]
|
||||
120 Suicide descriptors when Tor servers stop [OPEN]
|
||||
121 Hidden Service Authentication [OPEN]
|
||||
|
||||
|
||||
Proposals by status:
|
||||
@ -57,6 +58,7 @@ Proposals by status:
|
||||
116 Two hop paths from entry guards
|
||||
117 IPv6 exits
|
||||
120 Suicide descriptors when Tor servers stop
|
||||
121 Hidden Service Authentication
|
||||
ACCEPTED:
|
||||
101 Voting on the Tor Directory System
|
||||
103 Splitting identity key from regularly used signing key
|
||||
|
358
doc/spec/proposals/121-hidden-service-authentication.txt
Normal file
358
doc/spec/proposals/121-hidden-service-authentication.txt
Normal file
@ -0,0 +1,358 @@
|
||||
Filename: 121-hidden-service-authentication.txt
|
||||
Title: Hidden Service Authentication
|
||||
Version: $LastChangedRevision$
|
||||
Last-Modified: $LastChangedDate$
|
||||
Author: Tobias Kamm, Thomas Lauterbach, Karsten Loesing, Ferdinand Rieger,
|
||||
Christoph Weingarten
|
||||
Created: 10-Sep-2007
|
||||
Status: Open
|
||||
|
||||
Change history:
|
||||
|
||||
26-Sep-2007 Initial proposal for or-dev
|
||||
|
||||
Overview:
|
||||
|
||||
This proposal deals with some possibilities to implement authentication
|
||||
for restricted access to hidden services. This way we try to increase the
|
||||
security level for the service provider (Bob) by giving him the ability
|
||||
to exclude non-authorized users from using his service. It is based on
|
||||
proposal 114-distributed-storage but is better suited for a fine grained
|
||||
way of authentication, because it is less resource-consuming. Whenever we
|
||||
refer to service descriptors and cell formats, we are talking about the
|
||||
definitions found in 114-distributed-storage unless otherwise stated.
|
||||
|
||||
We discuss password and public-key authentication for the Onion Proxy
|
||||
(OP) of Bob's hidden service (HS). Furthermore a challenge-response
|
||||
authentication mechanism is introduced at the introduction point.
|
||||
|
||||
These modifications aim at:
|
||||
- increasing the security of hidden services by limiting access only to
|
||||
authorized users (specification see details) and
|
||||
- reducing the traffic in the network by rejecting unauthorized access
|
||||
requests earlier.
|
||||
|
||||
Motivation:
|
||||
|
||||
The currently used implementation of hidden services does not provide any
|
||||
kind of authentication. The v2 implementation adds an authentication
|
||||
mechanism at the directory server. Security can be further improved by
|
||||
adding two more authentication authorities at the introduction point
|
||||
(IPo) and the OP.
|
||||
|
||||
Although the service descriptors are already designed to carry
|
||||
authentication information the existing fields are not used so far.
|
||||
Moreover one can find a couple of notes at the specification of cell
|
||||
formats (rend-spec) which point at adding authentication information but
|
||||
no fields are specified yet. It would be preferable to extend the Tor
|
||||
network with authentication features to offer a solution for all
|
||||
services. This would also provide means to authorize access to services
|
||||
that currently do not support authentication mechanisms. Moreover, Bob's
|
||||
authentication administration for all services could be performed
|
||||
centralized in the Tor application, and the implementation overhead for
|
||||
developers would be significantly reduced. Another benefit would be the
|
||||
reduced traffic by checking authentication data and dropping unauthorized
|
||||
requests as soon as possible. For example unauthorized requests could
|
||||
already be discarded at the introduction points.
|
||||
|
||||
In addition to that, our implementation is able to hide the service from
|
||||
users, who still have access to the secret cookie (see
|
||||
114-distributed-storage) but should no longer be authorized. Bob can now
|
||||
not only hide his location, but also to a certain degree his presence
|
||||
towards unauthorized clients given that none of his IPo's are corrupted.
|
||||
|
||||
Details:
|
||||
|
||||
/1/ Client authentication at the hidden service
|
||||
|
||||
In proposal 114 a client (Alice) who has a valid secret cookie, which may
|
||||
be considered as a form of authentication, and a service ID is able to
|
||||
connect to Bob if he is online. He can not distinguish between Alice
|
||||
being intentionally authorized by himself or being an attacker.
|
||||
Integrating authentication in Tor HS will ensure Bob that Alice is only
|
||||
able to use the service if she is authorized by him.
|
||||
|
||||
Authentication data will be transmitted via the RELAY_INTRODUCE1 cell
|
||||
from Alice to Bob that is forwarded by the IPo. For this message several
|
||||
format versions are specified in the rend-spec in section 1.8. We will
|
||||
use the format version 3. This specification already contains the fields
|
||||
"AUTHT" (to specify the authentication method), "AUTHL" (length of the
|
||||
authentication data), and "AUTHD" (the authentication data) that will be
|
||||
used to store authentication data. Since these fields are encrypted with
|
||||
the service's public key, sniffing attacks will fail. Bob will only build
|
||||
the circuit to the rendezvous point if the provided authentication data
|
||||
is valid, otherwise he will drop the cell. This will improve security due
|
||||
to preventing communication between Bob and Alice if she is an attacker.
|
||||
As a positive side effect it reduces network traffic because it avoids
|
||||
Bob from building unnecessary circuits to the rendezvous points.
|
||||
Authentication at the HS should be the last gatekeeper and the number of
|
||||
cases in which a client successfully passes the introduction point, but
|
||||
fails at the HS should be almost zero. Therefore it is very important to
|
||||
perform fine-grained access control already at the IPo (but without
|
||||
relying on it).
|
||||
|
||||
The first authentication mechanism that will be supported is password
|
||||
(symmetric secret) authentication. "AUTHT" is set to "1" for this
|
||||
authentication method while the "AUTHL" field is set to "20", the length
|
||||
of the SHA-1 digest of the password.
|
||||
|
||||
(1) Alice creates a password x and sends the password digest h(x) to Bob
|
||||
out of band.
|
||||
(2) Alice sends h(x) to Bob, encrypted with Bob's fresh service key (not
|
||||
subject to this proposal, see proposal 114).
|
||||
(3) Bob decrypts Alice's message using his private service key (see
|
||||
proposal 114) and compares the contained h(x) with what he knows what
|
||||
Alice's password digest h(x) should be.
|
||||
|
||||
This kind of authentication is well-known. It has the known disadvantage
|
||||
of weak passwords that are vulnerable to dictionary or brute-force
|
||||
attacks. Nevertheless it seems to be an appropriate solution since safe
|
||||
passwords can be randomly generated by Tor. Cracking methods that rely on
|
||||
guessing passwords should not be effective in the constantly changing
|
||||
network infrastructure. A usability advantage is that this method is easy
|
||||
to perform even for unexperienced users. The authenticationdata will be
|
||||
the SHA-1 secure hash (see tor-spec) of the shared secret (password).
|
||||
|
||||
The premise to use password authentication is that Bob must send the
|
||||
password to Alice outside Tor. If at the same time the secret cookie is
|
||||
transmitted and the message is intercepted the attacker can gain access
|
||||
to the service. Therefore, a secure way to exchange this information must
|
||||
be established.
|
||||
|
||||
The second authentication mechanism is public-key authentication. The
|
||||
well-known RSA implementation will be used as cipher (see tor-spec).
|
||||
Authentication data will be the hash of the rendezvous cookie, signed
|
||||
with the private key (SK).
|
||||
|
||||
When Alice wants to use this authentication method she sets "AUTHT" to
|
||||
"2" and "AUTHL" to "128" which is the size of the encrypted data. Since
|
||||
the rendezvous cookie changes each time Alice connects, replay attacks
|
||||
can be easily prevented.
|
||||
|
||||
(1) Alice creates a private key e and sends the corresponding public key
|
||||
d to Bob out of band.
|
||||
(2) Alice generates a random rendezvous cookie r, computes PKSign(e, r),
|
||||
encrypts it with Bob's fresh service key (see proposal 114), and
|
||||
sends the result to Bob.
|
||||
(3) Bob decrypts Alice's message using his private service key (see
|
||||
proposal 114) and verifies PKSign(e, r) with d.
|
||||
|
||||
The premise for public-key authentication is that Alice must send the
|
||||
generated public key to Bob outside Tor. If an attacker is able to swap
|
||||
that key, the attacker could perform a man-in-the-middle attack, if he
|
||||
managed to serve as an IPo for Bob. Therefore a secure exchange channel
|
||||
must be established.
|
||||
|
||||
Depending on what authentication data Bob knows from Alice (password
|
||||
and/or public key, or other data that is added later) there are several
|
||||
choices for Alice to authenticate to the service.
|
||||
|
||||
After validating the provided "AUTHD" Bob builds a circuit to the
|
||||
rendezvous point and starts interacting with Alice. If Bob cannot
|
||||
identify the client he must refuse the request by not connecting to the
|
||||
rendezvous point.
|
||||
|
||||
It will also still be possible to establish v2 hidden services without
|
||||
authentication. Therefore the "AUTHT" field must be set to "0". "AUTHL"
|
||||
and "AUTHD" are not provided by the client in that case.
|
||||
|
||||
/2/ Client authentication at the introduction point
|
||||
|
||||
In addition to authentication at the HS OP, the IPo should be able to
|
||||
detect and abandon all unauthorized requests. This would help to raise
|
||||
the level of privacy and therefore also the level of security for Bob by
|
||||
better hiding his online activity from unauthorized users. Especially if
|
||||
Alice still has access to the secret cookie. This can be the case if she
|
||||
had access to the service earlier, but is no longer authorized or the
|
||||
directory is outdated. Another advantage of this additional "gate keeper"
|
||||
would be reduced traffic in the network, because unauthorized requests
|
||||
could already be detected and declined at the IPo.
|
||||
|
||||
It is important to notice that the IPo may not be trustworthy, and
|
||||
therefore can not replace authentication at the HS OP itself. Nor should
|
||||
the IPo get hold of critical authentication information (because it could
|
||||
try to access the service itself).
|
||||
|
||||
A challenge-response authentication protocol is used to address these
|
||||
issues. This means that a challenge is needed to be solved by Alice to
|
||||
get forwarded to Bob by the IPo.
|
||||
|
||||
Two types of authentication are supported and need to be preconfigured by
|
||||
Bob when creating the service: password and public-key authentication.
|
||||
Again it is up to Alice what kind of authentication mechanism she wants
|
||||
to use, given that Bob knows both her password and her public key.
|
||||
|
||||
If Alice uses a password to authenticate herself at the IPo, the
|
||||
authentication is based on a symmetric challenge-response authentication
|
||||
protocol. In this case the challenge for Alice is to send h(x|y) where x
|
||||
is a user-specific password, which should be different from the password
|
||||
needed for authentication at the hidden service and y is a randomly
|
||||
generated value. Alice gets hold of her password out of band.
|
||||
|
||||
With the initial RELAY_ESTABLISH_INTRO cell, the IPo gets a list of
|
||||
h(x|y)'s which it stores locally. Upon a request of Alice it compares her
|
||||
provided authentication data with the list entries. If there is a
|
||||
matching entry in its list, Alice's request is valid and can be forwarded
|
||||
to Bob. To generate the hash, Alice needs to know the password (which she
|
||||
will get out of band) and the random value y. This value is contained in
|
||||
the cookie-encrypted part of the hidden service descriptor which Alice
|
||||
can retrieve from the directory using her secret cookie.
|
||||
|
||||
(1) Alice creates a password x and sends the password digest h(x) to Bob
|
||||
out of band.
|
||||
(2) Bob creates a random value y, computes h(h(x)|y), and sends the
|
||||
result to the introduction point.
|
||||
(3) Bob encrypts y with a secret cookie (see proposal 114) and writes it
|
||||
to a rendezvous service descriptor.
|
||||
(4) Alice fetches Bob's rendezvous service descriptor, decrypts y using
|
||||
the secret cookie (see proposal 114), computes h(h(x)|y), encrypts
|
||||
it with the public key of the introduction point, and sends it to
|
||||
that introduction point.
|
||||
(5) The introduction point decrypts h(h(x)|y) from Alice's message and
|
||||
compares it to the value it knows from Bob (from step 2).
|
||||
|
||||
If Alice wants to use public-key authentication to authenticate herself
|
||||
at Bob's HS, the challenge-response authentication protocol is slightly
|
||||
different.
|
||||
|
||||
The IPo's are provided with a list of random value hashes h(r) with an
|
||||
entry for each user via the RELAY_ESTABLISH_INTRO cell. For public-key
|
||||
authentication Alice uses an RSA public/private-key pair (as specified in
|
||||
tor-spec). The public key is made known to Bob out of band. The IPo's
|
||||
will now be sent a new ESTABLISH_INTRO cell with an additional random
|
||||
value hash for Alice and a new descriptor is uploaded to the responsible
|
||||
directories. The public-key authentication part of the service descriptor
|
||||
holds a blank separated list of key-value pairs with one pair for every
|
||||
authorized user. The hash of the public key of a user serves as a key,
|
||||
while the PK-encrypted r represents the value. Authorized users can now
|
||||
find their respective key-value pair and decrypt the value of h(r). This
|
||||
result serves as an authorization token at the IPo in the same way as
|
||||
with password authentication. The IPo does not know which authentication
|
||||
method was used since the tokens always have the same format.
|
||||
|
||||
(1) Alice creates a private key e and sends the corresponding public key
|
||||
d to Bob out of band.
|
||||
(2) Bob creates a random value y and sends it to the introduction point.
|
||||
(3) Bob computes PKEncrypt(d, y), encrypts the result with a secret
|
||||
cookie (see proposal 114), and writes it to a rendezvous service
|
||||
descriptor.
|
||||
(4) Alice fetches Bob's rendezvous service descriptor, decrypts
|
||||
PKEncrypt(d, y) using the secret cookie (see proposal 114), decrypts
|
||||
y from it using her private key e, and sends it to the introduction
|
||||
point.
|
||||
(5) The introduction point compares y with the value it knows from Bob
|
||||
(from step 2).
|
||||
|
||||
To remove a user from a group, Bob needs to update the random value list
|
||||
at the IPo's.
|
||||
|
||||
The changes needed in Tor to realize these two challenge-response
|
||||
variations affect the RELAY_ESTABLISH_INTRO and RELAY_INTRODUCE1 relay
|
||||
cells, the service descriptor and the code parts in Tor where these cells
|
||||
and the descriptor are handled.
|
||||
|
||||
The RELAY_ESTABLISH_INTRO cell is now structured as follows:
|
||||
|
||||
V Format byte: set to 255 [1 octet]
|
||||
V Version byte: set to 2 [1 octet]
|
||||
KL Key length [2 octets]
|
||||
PK Bob's public key [KL octets]
|
||||
HS Hash of session info [20 octets]
|
||||
AUTHT The auth type that is supported [1 octet]
|
||||
AUTHL Length of auth data [2 octets]
|
||||
AUTHD Auth data [variable]
|
||||
SIG Signature of above information [variable]
|
||||
|
||||
"AUTHT" is set to "1" for password/public-key authentication.
|
||||
"AUTHD" is a list of 20 octet long challenges for clients.
|
||||
|
||||
The service descriptor as specified in 114-distributed-storage is used in
|
||||
our implementation.
|
||||
|
||||
For password authentication "authentication" auth-type is set to "1" and
|
||||
auth-data contains the 20 octets long string used by clients to construct
|
||||
the response to the challenge for authentication at the IPo.
|
||||
|
||||
When using public-key authentication the auth-type is set to "2" and
|
||||
auth-data holds a list of 148 octets long blank separated values. The
|
||||
first 20 octets of each value is the hash of the public key of a certain
|
||||
client and used by Alice to determine her entry in the list. The
|
||||
remaining 128 octets contain the PK-encrypted token needed to
|
||||
authenticate to the IPo.
|
||||
|
||||
The part of the RELAY_INTRODUCE1 cell that can be read by the IPo has the
|
||||
following fields added:
|
||||
|
||||
AUTHT The auth type that is supported [1 octet]
|
||||
AUTHL Length of auth data [1 octets]
|
||||
AUTHD Auth data [variable]
|
||||
|
||||
The AUTHT and AUTHL fields are provided to allow extensions of the
|
||||
protocol. Currently, we set AUTHT to 1 for password/public-key
|
||||
authentication and AUTHL to 20 for the length of the authorization token.
|
||||
|
||||
Security implications:
|
||||
|
||||
In addition to the security features proposed in 114-distributed-storage
|
||||
a new way of authentication is added at the OP of Bob. Moreover, the
|
||||
authentication at the IPo's is improved to support a fine-grained access
|
||||
control. Corrupted IPo's may easily bypass this authentication, but given
|
||||
the case that the majority of IPo's is acting as expected we still
|
||||
consider this feature as being useful.
|
||||
|
||||
Bob can now decide whether he wants to allow Alice to use his services or
|
||||
not. This gives him the possibility to offer his services only to known
|
||||
and trusted users that need to identify by a password or by signing their
|
||||
messages. The anonymity of the client towards the service provider is
|
||||
thereby reduced to pseudonymity.
|
||||
|
||||
Changing of access rights now involves all three authorization authorities
|
||||
depending on what changes should be made:
|
||||
|
||||
- The user configures his changes at the local OP. Therefore he can
|
||||
edit the cookie files that were extended to support multiple users.
|
||||
Moreover he can edit the new user files that were added to specify
|
||||
authentication information for every user.
|
||||
|
||||
- Whenever local changes occur, this information needs to be either
|
||||
passed to the responsible IPo's, the directory servers, or both
|
||||
depending on the authorization method and operation used. It is
|
||||
important to have consistent authorization results at all authorities
|
||||
at the same time, to create a trustworthy system with good user
|
||||
acceptance. As these reconfigurations always follow local changes
|
||||
they can be done automatically by the new Tor implementation and
|
||||
therefore no user interaction is needed.
|
||||
|
||||
- The secret cookies proposed in 114-distributed-storage are used for
|
||||
group management in our implementation as their use would be far to
|
||||
costly for a user-based authorization. That is because right now one
|
||||
descriptor is generated and uploaded for every secret cookie. Changes
|
||||
in this configuration should therefore be rare (maybe never) and only
|
||||
a few groups should exist. Provided that this is the case the costs
|
||||
for changes seem acceptable. As there is currently no possibility to
|
||||
make a directory remove the descriptor for a group an updated
|
||||
descriptor without any IPo should be uploaded to the directory
|
||||
servers.
|
||||
|
||||
Local changes to access rights can now be done faster than by changing
|
||||
service descriptors which reduces the directory server load and network
|
||||
traffic. Still every configuration change remains costly and users should
|
||||
carefully choose how detailed the access right configuration should be.
|
||||
|
||||
Attacking clients now need to bypass two more authentication steps to
|
||||
reach the service implementation. Compared to the current state it is
|
||||
more likely that attackers can be stopped even before they are able to
|
||||
contact Bob's OP. We expect that the possibility of an attack is thereby
|
||||
significantly reduced. Another positive side effect is that network
|
||||
traffic and router load is reduced by discarding unauthorized cells which
|
||||
should lower the effectiveness of denial of service attacks.
|
||||
|
||||
Compatibility:
|
||||
|
||||
When using our authentication for hidden services the implementation of
|
||||
IPo's needs to be extended. Therefore we use version information provided
|
||||
in router descriptors to be sure that we only send modified
|
||||
RELAY_ESTABLISH_INTRO cells to routers that can handle them. Clients of
|
||||
v2 hidden services will have to update their Tor installation if they
|
||||
want to be able to use the service.
|
||||
|
Loading…
Reference in New Issue
Block a user