proposal 190 got renamed.

1 files changed, 101 insertions, 0 deletions

diff --git a/proposals/190-shared-secret-bridge-authorization.txt b/proposals/190-shared-secret-bridge-authorization.txt
new file mode 100644
index 0000000..95a0d19
--- /dev/null
+++ b/proposals/190-shared-secret-bridge-authorization.txt
@@ -0,0 +1,101 @@
+Filename: 190-shared-secret-bridge-authorization.txt
+Title: Bridge Client Authorization Based on a Shared Secret
+Author: George Kadianakis
+Created: 04 Nov 2011
+Status: Open
+
+1. Overview
+
+   Proposals 187 and 189 introduced 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 secret between the bridge user and bridge operator.
+
+2. Motivation
+
+   A bridge client authorization scheme should only allow clients who
+   show knowledge of a shared secret to talk Tor to the bridge.
+
+3. Shared-secret-based authorization
+
+3.1. Where do shared secrets come from?
+
+   A shared secret is a piece of data known only to the bridge
+   operator and the bridge client.
+
+   It's meant to be automatically generated by the bridge
+   implementation to avoid issues with insecure and weak passwords.
+
+   Bridge implementations SHOULD create shared secrets by generating
+   random data using a strong RNG or PRNG.
+
+3.2. AUTHORIZE cell format
+
+   In shared-secret-based authorization, the MethodFields field of the
+   AUTHORIZE cell becomes:
+
+       'shared_secret'               [10 octets]
+
+   where:
+
+   'shared_secret', is the shared secret between the bridge operator
+                    and the bridge client.
+
+3.3. Cell parsing
+
+   Bridge implementations MUST reject any AUTHORIZE cells whose
+   'shared_secret' field does not match the shared secret negotiated
+   between the bridge operator and authorized bridge clients.
+
+4. Tor implementation
+
+4.1. Bridge side
+
+   Tor bridge implementations MUST create the bridge shared secret by
+   generating 10 octets of random data using a strong RNG or PRNG.
+
+   Tor bridge implementations MUST store the shared secret in
+   'DataDirectory/keys/bridge_auth_ss_key' in hexademical encoding.
+
+   Tor bridge implementations MUST support the boolean
+   'BridgeRequireClientSharedSecretAuthorization' configuration file
+   option which enables bridge client authorization based on a shared
+   secret.
+
+   If 'BridgeRequireClientSharedSecretAuthorization' is set, bridge
+   implementations MUST generate a new shared secret, if
+   'DataDirectory/keys/bridge_auth_ss_key' does not already exist.
+
+4.2. Client side
+
+   Tor client implementations must extend their Bridge line format to
+   support bridge shared secrets. The new format is:
+     Bridge <method> <address:port> [["keyid="]<id-fingerprint>] ["shared_secret="<shared_secret>]
+
+   where <shared_secret> is the bridge shared secret in hexademical
+   encoding.
+
+   Tor clients who use bridges with shared-secret-based client
+   authorization must specify the bridge's shared secret as in:
+     Bridge 12.34.56.78 shared_secret=934caff420aa7852b855
+
+5. Discussion
+
+5.1. 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
+
+   Thanks to Nick Mathewson and Robert Ransom for the help and
+   suggestions while writing this proposal.
+