On 2011-11-04, George Kadianakis <desnac...@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 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev