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

[Robert Ransom]

On 2011-11-04, George Kadianakis <desnacked at gmail.com> wrote:
>
> 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.

   - request information from a client that only an authorized client
     of the bridge 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.

The shared secret cannot be read by the bridge relay, only validated.
(That's a feature.)


>                    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.

And the reason that the client might be speaking to a MITM attacker is
that the client has no way to determine whether it should accept
whatever link certificate chain it receives.  Hmm.


>    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.

At the time that the client needs to compute shared_secret from
password (before it receives a CERT cell from the bridge for the first
time), the client does not know the bridge's identity key.

There is no reason to have shared_secret and password be different
strings.


> 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.

Which TLS certificate, encoded in what way?  (The bridge may send a
CA-signed certificate and its issuer chain.)


> 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'.

An adversary who MITMs the TLS connection and receives a Tor AUTHORIZE
cell will know that the client is trying to connect to a Tor bridge.

Should the client send a string of the form "GET
/?q=correct+horse+battery+staple\r\n\r\n" instead of an AUTHORIZE
cell, where "correct+horse+battery+staple" is a semi-plausible search
phrase derived from the HMAC in some way?


>    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.

Where do passwords come from?

In my opinion, each Tor bridge configured to require a password should
generate its own password, as a sufficiently long random string.  80
bits of entropy should be far more than enough for a bridge password.
In this case, different bridges should never have the same password.


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

Precomputation should not be useful if each password contains 80 bits
of entropy.  The bridge's identity key digest is not used in the
protocol specified above; only the identity key itself.


> 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.

Passwords used for this purpose should be provided to clients as part
of a Bridge torrc line, in either written or electronic form.  The
user will not retype them every time he/she/it starts Tor.


>    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.

Secret keys for DSA (with a fixed group) and EC-based signature
schemes can be short enough to be fairly easy to transport.  Secret
keys for RSA are a PITA to transport, unless you either (a) specify a
deterministic key-generation procedure, or (b) make the public key
available to all clients somehow, and provide enough information to
clients intended to access a bridge that the client can factor the
modulus efficiently.


> 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.


Robert Ransom