[tor-commits] [torspec/master] Now add proposals/190-password-bridge-authorization.txt.

[nickm at torproject.org]

commit 4aba6f4a27638cd9fed82124f70c640a054003a1
Author: George Kadianakis <desnacked at 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!