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!