commit a04a6f1412ca709d003e7acb07c13b9e91540e7a Author: Nick Mathewson nickm@torproject.org Date: Wed Jan 11 12:33:31 2012 -0500

proposal 190 got renamed. --- proposals/190-password-bridge-authorization.txt | 101 -------------------- .../190-shared-secret-bridge-authorization.txt | 101 ++++++++++++++++++++ 2 files changed, 101 insertions(+), 101 deletions(-)

diff --git a/proposals/190-password-bridge-authorization.txt b/proposals/190-password-bridge-authorization.txt deleted file mode 100644 index 95a0d19..0000000 --- a/proposals/190-password-bridge-authorization.txt +++ /dev/null @@ -1,101 +0,0 @@ -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. - 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. +