[tor-commits] [torspec/master] Update proposals 189, 190 and 191.
nickm at torproject.org
nickm at torproject.org
Mon Jan 9 23:58:09 UTC 2012
commit af99cd5ada63d7afcc09f7912a1686a5b62ebe62
Author: George Kadianakis <desnacked at gmail.com>
Date: Sun Jan 8 02:02:12 2012 +0100
Update proposals 189, 190 and 191.
---
proposals/189-authorize-cell.txt | 34 ++++-
proposals/190-password-bridge-authorization.txt | 153 +++++++-------------
proposals/191-mitm-bridge-detection-resistance.txt | 59 +++++++-
3 files changed, 129 insertions(+), 117 deletions(-)
diff --git a/proposals/189-authorize-cell.txt b/proposals/189-authorize-cell.txt
index 10b45a2..09f74e6 100644
--- a/proposals/189-authorize-cell.txt
+++ b/proposals/189-authorize-cell.txt
@@ -62,6 +62,8 @@ Status: Open
a meta-field hosting an arbitrary amount of fields.
'PadLen', specifies the amount of padding in octets.
+ Implementations SHOULD pick 'PadLen' to be a random integer from 1
+ to 3141 inclusive.
'Padding', is 'PadLen' octets of random content.
@@ -89,27 +91,33 @@ Status: Open
4. Discussion
-4.1. Why not let the pluggable transports do the padding, like they
+4.1. What's up with the [1,3141] padding bytes range?
+
+ The upper limit is larger than the Ethernet MTU so that AUTHORIZE
+ and AUTHORIZED cells are not always transmitted into a single
+ packet. Other than that, it's indeed pretty much arbitrary.
+
+4.2. Why not let the pluggable transports do the padding, like they
are supposed to do for the rest of the Tor protocol?
The arguments of section "Alternative design: Just use pluggable
transports" of proposal 187, apply here as well:
- All bridges who use client authorization will also need camouflaged
- AUTHORIZE/AUTHORIZED cell.
+ All bridges who use client authorization will also need padded
+ AUTHORIZE and AUTHORIZED cells.
-4.2. How should multiple round-trip authorization protocols be handled?
+4.3. How should multiple round-trip authorization protocols be handled?
- Protocols that require multiple round-trips between the client and
+ Protocols that require multiple-round trips between the client and
the bridge should use AUTHORIZE cells for communication.
The format of the AUTHORIZE cell is flexible enough to support
- messages from the client to the bridge and the inverse.
+ messages from the client to the bridge and the reverse.
- In the end of a successful multiple round-trip protocol, an
+ At the end of a successful multiple round-trip protocol, an
AUTHORIZED cell must be issued from the bridge to the client.
-4.3. AUTHORIZED seems useless. Why not use VPADDING instead?
+4.4. AUTHORIZED seems useless. Why not use VPADDING instead?
As noted in proposal 187, the Tor protocol uses VPADDING cells for
padding; any other use of VPADDING makes the Tor protocol kludgy.
@@ -120,3 +128,13 @@ Status: Open
bridge, in the case of successful authorization, to also process
the VERSIONS cell and begin the v3 handshake promptly.
+4.5. 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.
+
diff --git a/proposals/190-password-bridge-authorization.txt b/proposals/190-password-bridge-authorization.txt
index 36c8c35..95a0d19 100644
--- a/proposals/190-password-bridge-authorization.txt
+++ b/proposals/190-password-bridge-authorization.txt
@@ -1,145 +1,90 @@
-Filename: 190-password-bridge-authorization.txt
-Title: Password-based Bridge Client Authorization
+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 the AUTHORIZE and AUTHORIZED cells.
+ 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 password between the bridge user and bridge operator.
+ on a shared secret between the bridge user and bridge operator.
2. Motivation
- A proper bridge client authorization scheme should:
+ A bridge client authorization scheme should only allow clients who
+ show knowledge of a shared secret to talk Tor to the bridge.
- - request information from a client that only an authorized bridge
- client would know.
+3. Shared-secret-based authorization
- - 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.
+3.1. Where do shared secrets come from?
- The bridge client authorization scheme presented in this proposal
- is based on a shared password and attempts to satisfy both of the
- above requirements.
+ A shared secret is a piece of data known only to the bridge
+ operator and the bridge client.
-3. Design
+ It's meant to be automatically generated by the bridge
+ implementation to avoid issues with insecure and weak passwords.
- If the AuthMethod of an AUTHORIZE cell is '0x1', the client wants
- to become authorized using a shared secret based on a password.
+ Bridge implementations SHOULD create shared secrets by generating
+ random data using a strong RNG or PRNG.
- The short name of this authorization scheme is 'BRIDGE_AUTH_PSK'.
+3.2. AUTHORIZE cell format
-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
+ In shared-secret-based authorization, the MethodFields field of the
AUTHORIZE cell becomes:
- 'HMAC(shared_secret, tls_cert)' [HASH_LEN octets]
+ 'shared_secret' [10 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.
+ 'shared_secret', is the shared secret between the bridge operator
+ and the bridge client.
-3.4. Password-based authorization notes
+3.3. Cell parsing
- Bridge implementations MUST reject clients who provide malformed
- AUTHORIZE cells or HMAC values that do not verify the appropriate
- TLS certificate.
+ 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.
- Bridge implementations SHOULD provide an easy way to create and
- change the bridge shared secret.
+4. Tor implementation
-3.5. Security arguments
+4.1. Bridge side
- 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'.
+ Tor bridge implementations MUST create the bridge shared secret by
+ generating 10 octets of random data using a strong RNG or PRNG.
- 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'.
+ Tor bridge implementations MUST store the shared secret in
+ 'DataDirectory/keys/bridge_auth_ss_key' in hexademical encoding.
- The two above paragraphs resolve the requirements of the
- 'Motivation' section.
+ Tor bridge implementations MUST support the boolean
+ 'BridgeRequireClientSharedSecretAuthorization' configuration file
+ option which enables bridge client authorization based on a shared
+ secret.
- 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.
+ If 'BridgeRequireClientSharedSecretAuthorization' is set, bridge
+ implementations MUST generate a new shared secret, if
+ 'DataDirectory/keys/bridge_auth_ss_key' does not already exist.
- The bridge's identity key digest also serves as a salt to counter
- rainbow table precomputation attacks.
+4.2. Client side
-4. Tor implementation
+ 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>]
- The Tor implementation of the above scheme uses SHA256 as the hash
- function 'H'.
+ where <shared_secret> is the bridge shared secret in hexademical
+ encoding.
- SHA256 also makes HASH_LEN equal to 32.
+ 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. 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
+5.1. What should actually happen when a bridge rejects an AUTHORIZE
cell?
When a bridge detects a badly formed or malicious AUTHORIZE cell,
@@ -151,6 +96,6 @@ Status: Open
6. Acknowledgements
- Without Nick Mathewson and Robert Ransom this proposal would
- actually be specifying a useless and broken authentication scheme.
- Thanks!
+ Thanks to Nick Mathewson and Robert Ransom for the help and
+ suggestions while writing this proposal.
+
diff --git a/proposals/191-mitm-bridge-detection-resistance.txt b/proposals/191-mitm-bridge-detection-resistance.txt
index 7709ae8..013d76c 100644
--- a/proposals/191-mitm-bridge-detection-resistance.txt
+++ b/proposals/191-mitm-bridge-detection-resistance.txt
@@ -68,7 +68,9 @@ Status: Open
The certificate fingerprints used on this scheme MUST be computed
by applying the SHA256 cryptographic hash function upon the ASN.1
- DER encoding of a public-key certificate.
+ DER encoding of a public-key certificate, then truncating the hash
+ output to 12 bytes, encoding it to RFC4648 Base32 and omitting any
+ trailing padding '='.
4.2. Bridge side implementation
@@ -90,13 +92,12 @@ Status: Open
Bridge <method> <address:port> [["keyid="]<id-fingerprint>] \
["shared_secret="<shared_secret>] ["link_cert_fpr="<fingerprint>]
- where <fingerprint> is the bridge's SSL certificate fingerprint in
- hexademical encoding.
+ where <fingerprint> is the bridge's SSL certificate fingerprint.
Tor clients who use bridges and want to pin their SSL certificates
must specify the bridge's SSL certificate fingerprint as in:
Bridge 12.34.56.78 shared_secret=934caff420aa7852b855 \
- link_cert_fpr=38b0712e90bed729df81f2a22811d3dd89e91406d2522f4482ae4079e5245187
+ link_cert_fpr=GM4GEMBXGEZGKOJQMJSWINZSHFSGMOBRMYZGCMQ
4.4. Implementation prerequisites
@@ -107,7 +108,55 @@ Status: Open
Tor trac ticket #4390 and proposal YYY were created to resolve this
issue.
-5. Acknowledgements
+5. Other ideas
+
+5.1. Certificate tagging using a shared secret
+
+ Another idea worth considering is having the bridge use the shared
+ secret from proposal 190 to embed a "secret message" on her
+ certificate, which could only be understood by a client who knows
+ that shared secret, essentially authenticating the bridge.
+
+ Specifically, the bridge would "tag" the Serial Number (or any
+ other covert field) of her certificate with the (potentially
+ truncated) HMAC of her link public key, using the shared secret of
+ proposal 190 as the key: HMAC(shared_secret, link_public_key).
+
+ A client knowing the shared secret would be able to verify the
+ 'link_public_key' and authenticate the bridge, and since the Serial
+ Number field is usually composed of random bytes a probing attacker
+ would not notice the "tagging" of the certificate.
+
+ Arguments for this scheme are that it:
+ a) doesn't need extra bridge credentials apart from the shared secret
+ of prop190.
+ b) doesn't need any maintenance in case of certificate expiration.
+
+ Arguments against this scheme are:
+ a) In the case of self-signed certificates, OpenSSL creates an
+ 8-bytes random Serial number, and we would probably need
+ something more than 8-bytes to tag. There are not many other
+ covert fields in SSL certificates mutable by vanilla OpenSSL.
+ b) It complicates the scheme, and if not implemented and researched
+ wisely it might also make it fingerprintable.
+ c) We most probably won't be able to tag CA-signed certificates.
+
+6. Discussion
+
+6.1. In section 4.1, why do you truncate the SHA256 output to 12 bytes?!
+
+ Bridge credentials are frequently propagated by word of mouth or
+ are physically written down, which renders the occult Base64
+ encoding unsatisfactory. The 104 characters Base32 encoding or the
+ 64 characters hex representation of the SHA256 output would also be
+ too much bloat.
+
+ By truncating the SHA256 output to 12 bytes and encoding it with
+ Base32, we get 39 characters of readable and easy to transcribe
+ output, and sufficient security. Finally, dividing '39' by the
+ golden ratio gives us about 24.10!
+
+7. Acknowledgements
Thanks to Robert Ransom for his great help and suggestions on
devising this scheme and writing this proposal!
More information about the tor-commits
mailing list