[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Now add proposals/190-password-bridge-authorization.txt.
commit 4aba6f4a27638cd9fed82124f70c640a054003a1
Author: George Kadianakis <desnacked@xxxxxxxxx>
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!
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits