commit 4aba6f4a27638cd9fed82124f70c640a054003a1 Author: George Kadianakis desnacked@gmail.com Date: Fri Nov 4 18:39:00 2011 +0100
Now add proposals/190-password-bridge-authorization.txt. --- proposals/190-password-bridge-authorization.txt | 156 +++++++++++++++++++++++ 1 files changed, 156 insertions(+), 0 deletions(-)
diff --git a/proposals/190-password-bridge-authorization.txt b/proposals/190-password-bridge-authorization.txt new file mode 100644 index 0000000..36c8c35 --- /dev/null +++ b/proposals/190-password-bridge-authorization.txt @@ -0,0 +1,156 @@ +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!