[tor-dev] Proposal 190: Password-based Bridge Client Authorization

[George Kadianakis <desnacked@xxxxxxxxx>]

Filename: 190-password-bridge-authorization.txt
Title: Password-based Bridge Client Authorization
Author: George Kadianakis
Created: 04 Nov 2011
Status: Open

1. Overview

   Proposals 187 and 189 introduced the AUTHORIZE and AUTHORIZED cells.
   Their purpose is to make bridge relays scanning resistant against
   censoring adversaries capable of probing hosts to observe whether
   they speak the Tor protocol.

   This proposal specifies a bridge client authorization scheme based
   on a shared password between the bridge user and bridge operator.

2. Motivation

   A proper bridge client authorization scheme should:

   - request information from a client that only an authorized bridge
     client would know.

   - ensure that the shared secret sent by the bridge client during
     the authorization can only be read and validated by the proper
     bridge relay. This is important since the v3 link handshake which
     authenticates the bridge to the client is carried out *after* the
     bridge client authorization, which means that when the AUTHORIZE
     cell is sent, the client might be actually speaking to a Man In
     The Middle.

   The bridge client authorization scheme presented in this proposal
   is based on a shared password and attempts to satisfy both of the
   above requirements.

3. Design

   If the AuthMethod of an AUTHORIZE cell is '0x1', the client wants
   to become authorized using a shared secret based on a password.

   The short name of this authorization scheme is 'BRIDGE_AUTH_PSK'.

3.1. Notation

   '||', denotes concatenation.

   'HMAC(k, m)', is the Hash-based Message Authentication Code of
                 message 'm' using 'k' as the secret key.

   'H(m)', is a cryptographic hash function applied on a message 'm'.

   'HASH_LEN', is the output size of the hash function 'H'.

3.2. Shared secret format

   A bridge client and a bridge relay willing to use this
   authorization scheme, should have already exchanged out-of-band
   (for example, during the bridge credentials exchange) a shared
   password.

   In this case, the shared secret of this scheme becomes:

      shared_secret = H( H(bridge_identity_key) || ":" || password)

   where:

   'bridge_identity_key', is the PKCS#1 ASN1 encoding of the bridge's
                          public identity key.

   '":"', is the colon character (0x3a in UTF-8).

   'password', is the bridge password.

3.3. Password-based authorization AUTHORIZE cell format

   In password-based authorization, the MethodFields field of the
   AUTHORIZE cell becomes:

       'HMAC(shared_secret, tls_cert)'               [HASH_LEN octets]

   where:

   'HMAC(shared_secret, tls_cert), is the HMAC construction of the TLS
   certificate of the bridge relay, using the shared secret of section
   3.2 as the secret key.

3.4. Password-based authorization notes

   Bridge implementations MUST reject clients who provide malformed
   AUTHORIZE cells or HMAC values that do not verify the appropriate
   TLS certificate.

   Bridge implementations SHOULD provide an easy way to create and
   change the bridge shared secret.

3.5. Security arguments

   An adversary who does not know the 'shared_secret' of a bridge
   cannot construct an HMAC that verifies its TLS certificate when
   used with the correct 'shared_secret'.

   An adversary who attempts to MITM the TLS connection of a bridge
   user to steal the 'shared_secret' will instead steal an HMAC value
   created by the 'tls_cert' of the TLS certificate that the attacker
   used to MITM the TLS connection. Replaying that 'shared_secret'
   value to the actual bridge will fail to verify the correct
   'tls_cert'.

   The two above paragraphs resolve the requirements of the
   'Motivation' section.

   Furthermore, an adversary who compromises a bridge, steals the
   shared secret and attempts to replay it to other bridges of the
   same bridge operator will fail since each shared secret has a
   digest of the bridge's identity key baked in it.

   The bridge's identity key digest also serves as a salt to counter
   rainbow table precomputation attacks.

4. Tor implementation

   The Tor implementation of the above scheme uses SHA256 as the hash
   function 'H'.

   SHA256 also makes HASH_LEN equal to 32.

5. Discussion

5.1. Do we need more authorization schemes?

   Probably yes.

   The centuries-old problem with passwords is that humans can't get
   their passwords right.

   To avoid problems associated with the human condition, schemes
   based on public key cryptography and certificates can be used. A
   public and well tested protocol that can be used as the basis of a
   future authorization scheme is the SSH "publickey" authorization
   protocol.

5.2. What should actually happen when a bridge rejects an AUTHORIZE
     cell?

   When a bridge detects a badly formed or malicious AUTHORIZE cell,
   it should assume that the other side is an adversary scanning for
   bridges. The bridge should then act accordingly to avoid detection.

   This proposal does not try to specify how a bridge can avoid
   detection by an adversary.

6. Acknowledgements

   Without Nick Mathewson and Robert Ransom this proposal would
   actually be specifying a useless and broken authentication scheme.
   Thanks!
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev