proposal 121: updated most parts of the concrete authorization protocol

svn:r14497

doc/spec/proposals/121-hidden-service-authentication.txt

@@ -15,6 +15,7 @@ Change history:
                authentication protocol, merged in personal notes
   24-Dec-2007  Replaced misleading term "authentication" by "authorization"
                and added some clarifications (comments by Sven Kaffille)
+  28-Apr-2008  Updated most parts of the concrete authorization protocol
 
 Overview:
 
@@ -22,7 +23,7 @@ Overview:
   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
+  and (3) at Bob's Tor client 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
@@ -71,9 +72,9 @@ Motivation:
   (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
+  them, rejecting unauthorized requests already at the introduction
   point (ideally without leaking presence information at any of these
-  points).
+  points), or not answering unauthorized introduction requests.
 
   (4) Better protection of introduction points: When providing hidden
   service descriptors to authorized clients only and encrypting the
@@ -98,7 +99,7 @@ Motivation:
   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. 
+  resources of the service.
 
   Authorization often implies authentication, i.e. proving one's identity.
   However, when performing authorization within the Tor network, untrusted
@@ -107,8 +108,8 @@ Motivation:
   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
+  client and therefore perfectly identifiable. Therefore, hiding client
-  from the hidden service is not aimed by this proposal.
+  identity from the hidden service is not aimed by this proposal.
 
   The current implementation of hidden services does not provide any kind
   of authorization. The hidden service descriptor version 2, introduced by
@@ -128,10 +129,11 @@ Details:
     (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.
+    (3) at Bob's Tor client before contacting the rendezvous point.
 
   The general idea of this proposal is to allow service providers to
-  restrict access to all of these points to authorized clients only.
+  restrict access to some or all of these points to authorized clients
+  only.
 
   1.1. Client authorization at directory
 
@@ -147,7 +149,13 @@ Details:
   service descriptors):
 
       descriptor-id =
-          H(permanent-id | H(time-period | descriptor-cookie | replica))
+          H(service-id | H(time-period | descriptor-cookie | replica))
+
+  Currently, service-id is equivalent to permanent-id which is calculated
+  as in the following formula. But in principle it could be any public
+  key.
+
+      permanent-id = H(permanent-key)[:10]
 
   The second purpose of the descriptor cookie is to encrypt the list of
   introduction points, including optional authorization data. Hence, the
@@ -166,10 +174,7 @@ Details:
   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
+  is applied by a service provider.
-  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 authorization, changing the way of using the
@@ -186,7 +191,7 @@ Details:
   1.2. Client authorization at introduction point
 
   The next possible authorization point after downloading and decrypting
-  a hidden service descriptor is the introduction point. It is important
+  a hidden service descriptor is the introduction point. It may be important
   for authorization, because it bears the last chance of hiding presence
   of a hidden service from unauthorized clients. Further, performing
   authorization at the introduction point might reduce traffic in the
@@ -222,7 +227,7 @@ Details:
   limit.
 
   The current ESTABLISH_INTRO cells as described in section 1.3 of
-  rend-spec don't contain either authorization data or version
+  rend-spec do not 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:
 
@@ -313,18 +318,18 @@ Details:
   versions 0 to 2 specified in section 1.8 of rend-spec, but none of these
   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
+  1.8.1 and which is not implemented as of December 2007. In contrast to
-  is to switch the lengths of AUTHT and AUTHL, which we assume to be a typo
+  the specified v3 we avoid specifying (and implementing) IPv6 capabilities,
-  in current rend-spec. The proposed format of v3 INTRODUCE2 cells is as
+  because Tor relays will be required to support IPv4 addresses for a long
-  follows:
+  time in the future, so that this seems unnecessary at the moment. 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]
+     IP     Rendezvous point's address           [4 octets]
+     PORT   Rendezvous point's OR port           [2 octets]
      ID     Rendezvous point identity ID        [20 octets]
      KLEN   Length of onion key                  [2 octets]
      KEY    Rendezvous point onion key        [KLEN octets]
@@ -332,11 +337,12 @@ Details:
      g^x    Diffie-Hellman data, part 1        [128 octets]
 
   The maximum possible length of authorization data is related to the
-  enclosing INTRODUCE1 cell. A v3 INTRODUCE2 cell with IPv6 address and
+  enclosing INTRODUCE1 cell. A v3 INTRODUCE2 cell with
   1024 bit = 128 octets long public keys without any authorization data
-  occupies 321 octets, plus 58 octets for hybrid public key encryption (see
+  occupies 306 octets (AUTHL is only used when AUTHT has a value != 0),
+  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
+  surrounding v1 INTRODUCE1 cell requires 24 octets. This leaves only 110
   of the 498 available octets free, which must be shared between
   authorization data to the introduction point _and_ to the hidden
   service.
@@ -378,12 +384,12 @@ Details:
       - 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.
+      - one part of 110 octets in the INTRODUCE1 cell.
 
   (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.
+      - the other part of 110 octets in the INTRODUCE2 cell.
 
   It will also still be possible to access a hidden service without any
   authorization or only use a part of the authorization infrastructure.
@@ -397,10 +403,8 @@ Details:
 
   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
+  configuration file or separate files. The exact format of these special
-  would use one file per provided service, and a client would use one file
+  files depends on the authorization protocol used.
-  per server she wants to access. The exact format of these special files
-  depends on the authorization protocol used.
 
   Currently, rend-spec contains the proposition to encode client-side
   authorization data in the URL, like in x.y.z.onion. This was never used
@@ -410,142 +414,91 @@ Details:
   2. An authorization protocol based on group and user passwords
 
   In the following we discuss an authorization protocol for the proposed
-  authorization architecture that performs authorization at all three
+  authorization architecture that performs authorization at the directory
-  proposed authorization points. The protocol relies on two symmetrically
+  and the hidden service, but not at the introduction point.
-  shared keys: a group key and a user key. The reason for this separation
+  The protocol relies on a distinct asymmetric (client-key) and a
-  as compared to using a single key for each user is the fact that the
+  symmetric key (descriptor-cookie) for
-  number of descriptor cookies should be limited, so that the group key
+  each client. The asymmetric key replaces the service's permanent key and
-  will be used for authenticating at the directory, whereas two keys
+  the symmetric key is used as descriptor cookie as described above.
-  derived from the user key will be used for performing authorization at
-  the introduction and the hidden service.
 
   2.1. Client authorization at directory
 
-  The server creates groups of users that shall be able to access his
+  The symmetric key of 128 bits length is used as descriptor cookie for
-  service. He provides all users of a certain group with the same group key
+  publishing/fetching
-  which is a password of arbitrary length.
+  hidden service descriptors and for encrypting/decrypting the contained
-
+  introduction points. Further, the asymmetric key replaces the service's
-  The group key is used as input to derive a 128 bit descriptor cookie from
+  permanent key that is used to encode and sign a v2 hidden service descriptor.
-  it. We propose to apply a secure hash function and use the first 128 bits
+  The result is a v2 hidden service descriptor with the following format:
-  of output:
+  
-
+      descriptor-id =
-     descriptor-cookie = H(group-key)
+          H(H(client-key)[:10] | H(time-period | descriptor-cookie | replica))
-
+      descriptor-content = {
-  Hence, there will be a distinct hidden service descriptor for every group
+        descriptor-id,
-  of users. All descriptors contain the same introduction points and the
+        version,
-  authorization data required by the users of the given group. Whenever a
+        client-key,
-  server decides to remove authorization for a group, he can simply stop
+        H(time-period | descriptor-cookie | replica),
+        timestamp,
+        protocol-versions,
+        { introduction-points } encrypted with descriptor-cookie
+      } signed with private-key
+
+  Whenever a
+  server decides to remove authorization for a client, he can simply stop
   publishing hidden service descriptors using the descriptor cookie.
+  The fact that there needs to be a separate
+  hidden service descriptor for each user leads to a large number of
+  such descriptors. However, this is the only way for a service
+  provider to remove a client's authorization without remains. We assume
+  that distributing the directory of hidden service descriptors as
+  implemented by proposal 114 provides the necessary scalability to do so.
 
   2.2. Client authorization at introduction point
 
-  The idea for authenticating at the introduction point is borrowed from
+  There is no need to perform authorization at the introduction point in
-  authorization at the rendezvous point using a rendezvous cookie. A
+  this protocol. Only authorized clients can decrypt the introduction
-  rendezvous cookie is created by the client and encrypted for the server
+  point part of a hidden service descriptor. This contains the
-  in order to authenticate the server at the rendezvous point. Likewise,
+  introduction key that was introduced by proposal 114 and that is required
-  the so-called introduction cookie is created by the server and encrypted
+  to get an INTRODUCE1 cell passed at the introduction point.
-  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 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 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
-  determined as follows:
-
-     client-id = H(user-key | "CLIENT")
-
-  The authorization data encoded to the hidden service descriptor consists
-  of the concatenation of pairs consisting of 20 byte client identifiers
-  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 authorization at hidden service
 
-  Authorization at the hidden service also makes use of the user key,
+  Authorization at the hidden service also makes use of the
-  because whoever is authorized to pass the introduction point shall be
+  descriptor cookie. The client include this descriptor cookie,
-  authorized to access the hidden service. Therefore, the server and client
+  in INTRODUCE2 cells that it sends to the server.
-  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 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".
 
-  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.
-
   2.4. Providing authorization data
 
-  The authorization data that needs to be provided by servers consists of
+  The Tor client of a hidden service needs to know the client keys
-  a number of group keys, each having a number of user keys assigned. These
+  and descriptor cookies of all authorized clients. We decided to
-  data items could be provided by two new configuration options
+  create a new configuration option that specifies a comma-separated list
-  "HiddenServiceAuthGroup group-name group-key" and "HiddenServiceAuthUser
+  of human-readable client names:
-  user-name user-key" with the semantics that a group contains all users
+
-  directly following the group key definition and before reaching the next
+  HiddenServiceAuthorizeClient client-name,client-name,...
-  group key definition for a hidden service.
+
-
+  When a hidden service is configured, the client keys and descriptor
-  On client side, authorization data also consists of a group and a user
+  cookies for all configured client names are either read from a file
-  key. Therefore, a new configuration option "HiddenServiceAuthClient
+  or generated and appended to that file. The file format is:
-  onion-address group-key user-key" could be introduced that could be
+
-  written to any place in the configuration file. Whenever the user would
+     "client-name" human-readable client identifier NL
-  try to access the given onion address, the given group and user key
+     "descriptor-cookie" 128-bit key ^= 22 base64 chars NL
-  would be used for authorization.
+     "client-key" NL a public key in PEM format
+
+  On client side, we propose to add a new configuration option that
+  contains a service name, the service identifier (H(client-key)[:10]),
+  and the descriptor cookie that are required to access a hidden service.
+  The configuration option has the following syntax:
+  
+  HidServAuth service-name service-address descriptor-cookie
+  
+  Whenever the user tries to access the given onion address, the given
+  descriptor cookie is used for authorization.
 
 Security implications:
 
-  In the following we want to discuss attacks and non-attacks by dishonest
+  In the following we want to discuss possible attacks by dishonest
   entities in the presented infrastructure and specific protocol. These
   security implications would have to be verified once more when adding
   another protocol. The dishonest entities (theoretically) include the
@@ -560,11 +513,12 @@ Security implications:
 
   (1) A hidden service directory could attempt to conclude presence of a
   server from the existence of a locally stored hidden service descriptor:
-  This passive attack is possible, because descriptors need to contain a
+  This passive attack is possible only for a single client-service
-  publicly visible signature of the server (see proposal 114 for a more
+  relation, because descriptors need to contain a
-  extensive discussion of the v2 descriptor format). A possible protection
+  publicly visible signature of the server using the client key
-  would be to reduce the number of concurrently used descriptor cookies and
+  A possible protection
-  increase the number of hidden service directories in the network.
+  would be to increase the number of hidden service directories in the
+  network.
 
   (2) A hidden service directory could try to break the descriptor cookies
   of locally stored descriptors: This attack can be performed offline. The
@@ -581,7 +535,7 @@ Security implications:
   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.
+  a specific service.
 
   (4) An introduction point could want to learn the identities of accessing
   clients: This is also impossible by design, because all clients use the
@@ -590,8 +544,9 @@ Security implications:
   (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
+  not possible by design, because INTRODUCE1 cells are encrypted using a
-  introduction cookie that is different for every introduction point.
+  freshly created introduction key that is only known to authorized
+  clients.
 
   (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
@@ -610,32 +565,16 @@ Security implications:
   are working correctly.
 
   (8) The rendezvous point could attempt to identify either server or
-  client: No, this remains impossible as it was before, because the
+  client: This remains impossible as it was before, because the
   rendezvous cookie does not contain any identifiable information.
 
-  (9) An authenticated client could try to break the encryption keys of the
+  (9) An authenticated client could swamp the server with valid INTRODUCE1
-  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.
-
-  (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.
 
-  (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
-  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:
 
   An implementation of this proposal would require changes to hidden
@@ -643,8 +582,60 @@ Compatibility:
   understand the new formats. However, both servers and clients would
   remain compatible to regular hidden services without authorization.
 
-  Further, the implementation of introduction points would have to be
+Implementation:
-  changed, so that they understand the new cell versions and perform
+
-  authorization. But again, the new introduction points would remain
+  The implementation of this proposal can be divided into a number of
-  compatible to the existing hidden service protocol.
+  changes to hidden service and client side. There are no
+  changes necessary on directory, introduction, or rendezvous nodes. All
+  changes are marked with either [service] or [client] do denote on which
+  side they need to be made.
+
+  /1/ Configure client authorization [service]
+
+  - Parse configuration option HiddenServiceAuthorizeClient containing
+    authorized client names.
+  - Load previously created client keys and descriptor cookies.
+  - Generate missing client keys and descriptor cookies, add them to
+    client_keys file.
+  - Rewrite the hostname file.
+  - Keep client keys and descriptor cookies of authorized clients in
+    memory.
+ [- In case of reconfiguration, mark which client authorizations were
+    added and whether any were removed. This can be used later when
+    deciding whether to rebuild introduction points and publish new
+    hidden service descriptors. Not implemented yet.]
+
+  /2/ Publish hidden service descriptors [service]
+
+  - Create and upload hidden service descriptors for all authorized
+    clients.
+ [- See /1/ for the case of reconfiguration.]
+
+  /3/ Configure permission for hidden services [client]
+
+  - Parse configuration option HidServAuth containing service
+    authorization, store authorization data in memory.
+
+  /5/ Fetch hidden service descriptors [client]
+
+  - Look up client authorization upon receiving a hidden service request.
+  - Request hidden service descriptor ID including client key and
+    descriptor cookie. Only request v2 descriptors, no v0.
+
+  /6/ Process hidden service descriptor [client]
+
+  - Decrypt introduction points with descriptor cookie.
+
+  /7/ Create introduction request [client]
+
+  - Include descriptor cookie in INTRODUCE2 cell to introduction point.
+  - Pass descriptor cookie around between involved connections and
+    circuits.
+
+  /8/ Process introduction request [service]
+
+  - Read descriptor cookie from INTRODUCE2 cell.
+  - Check whether descriptor cookie is authorized for access, including
+    checking access counters.
+  - Log access for accountability.