[tor-commits] [torspec/master] proposal 190 got renamed.
nickm at torproject.org
nickm at torproject.org
Wed Jan 11 17:34:11 UTC 2012
commit a04a6f1412ca709d003e7acb07c13b9e91540e7a
Author: Nick Mathewson <nickm at 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.
+
More information about the tor-commits
mailing list