On 2011-11-04, George Kadianakis desnacked@gmail.com wrote:
Filename: 190-password-bridge-authorization.txt Title: Password-based Bridge Client Authorization Author: George Kadianakis Created: 04 Nov 2011 Status: Open
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.
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.
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.
Tor implementation
The Tor implementation of the above scheme uses SHA256 as the hash function 'H'.
SHA256 also makes HASH_LEN equal to 32.
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