Reflow proposals 233, 234.
[torspec.git] / proposals / 189-authorize-cell.txt
1 Filename: 189-authorize-cell.txt
2 Title: AUTHORIZE and AUTHORIZED cells
3 Author: George Kadianakis
4 Created: 04 Nov 2011
5 Status: Open
6
7 1. Overview
8
9    Proposal 187 introduced the concept of the AUTHORIZE cell, a cell
10    whose purpose is to make Tor bridges resistant to scanning attacks.
11
12    This is achieved by having the bridge and the client share a secret
13    out-of-band and then use AUTHORIZE cells to validate that the
14    client indeed knows that secret before proceeding with the Tor
15    protocol.
16
17    This proposal specifies the format of the AUTHORIZE cell and also
18    introduces the AUTHORIZED cell, a way for bridges to announce to
19    clients that the authorization process is complete and successful.
20
21 2. Motivation
22
23    AUTHORIZE cells should be able to perform a variety of
24    authorization protocols based on a variety of shared secrets. This
25    forces the AUTHORIZE cell to have a dynamic format based on the
26    authorization method used.
27
28    AUTHORIZED cells are used by bridges to signal the end of a
29    successful bridge client authorization and the beginning of the
30    actual link handshake. AUTHORIZED cells have no other use and for
31    this reason their format is very simple.
32
33    Both AUTHORIZE and AUTHORIZED cells are to be used under censorship
34    conditions and they should look innocuous to any adversary capable
35    of monitoring network traffic.
36
37    As an attack example, an adversary could passively monitor the
38    traffic of a bridge host, looking at the packets directly after the
39    TLS handshake and trying to deduce from their packet size if they
40    are AUTHORIZE and AUTHORIZED cells. For this reason, AUTHORIZE and
41    AUTHORIZED cells are padded with a random amount of padding before
42    sending.
43
44 3. Design
45
46 3.1. AUTHORIZE cell
47
48    The AUTHORIZE cell is a variable-sized cell.
49
50    The generic AUTHORIZE cell format is:
51
52          AuthMethod                       [1 octet]
53          MethodFields                     [...]
54          PadLen                           [2 octets]
55          Padding                          ['PadLen' octets]
56
57    where:
58
59    'AuthMethod', is the authorization method to be used.
60
61    'MethodFields', is dependent on the authorization Method used. It's
62                    a meta-field hosting an arbitrary amount of fields.
63
64    'PadLen', specifies the amount of padding in octets.
65    Implementations SHOULD pick 'PadLen' to be a random integer from 1
66    to 3141 inclusive.
67
68    'Padding', is 'PadLen' octets of random content.
69
70 3.2. AUTHORIZED cell format
71
72    The AUTHORIZED cell is a variable-sized cell.
73
74    The AUTHORIZED cell format is:
75
76          'AuthMethod'                       [1 octet]
77          'PadLen'                           [2 octets]
78          'Padding'                          ['PadLen' octets]
79
80    where all fields have the same meaning as in section 3.1.
81
82 3.3. Cell parsing
83
84    Implementations MUST ignore the contents of 'Padding'.
85
86    Implementations MUST reject an AUTHORIZE or AUTHORIZED cell where
87    the 'Padding' field is not 'PadLen' octets long.
88
89    Implementations MUST reject an AUTHORIZE cell with an 'AuthMethod'
90    they don't recognize.
91
92 4. Discussion
93
94 4.1. What's up with the [1,3141] padding bytes range?
95
96    The upper limit is larger than the Ethernet MTU so that AUTHORIZE
97    and AUTHORIZED cells are not always transmitted into a single
98    packet. Other than that, it's indeed pretty much arbitrary.
99
100 4.2. Why not let the pluggable transports do the padding, like they
101      are supposed to do for the rest of the Tor protocol?
102
103    The arguments of section "Alternative design: Just use pluggable
104    transports" of proposal 187, apply here as well:
105
106    All bridges who use client authorization will also need padded
107    AUTHORIZE and AUTHORIZED cells.
108
109 4.3. How should multiple round-trip authorization protocols be handled?
110
111    Protocols that require multiple round trips between the client and
112    the bridge should use AUTHORIZE cells for communication.
113
114    The format of the AUTHORIZE cell is flexible enough to support
115    messages from the client to the bridge and the reverse.
116
117    At the end of a successful multiple-round-trip protocol, an
118    AUTHORIZED cell must be issued from the bridge to the client.
119
120 4.4. AUTHORIZED seems useless. Why not use VPADDING instead?
121
122    As noted in proposal 187, the Tor protocol uses VPADDING cells for
123    padding; any other use of VPADDING makes the Tor protocol kludgy.
124
125    In the future, and in the example case of a v3 handshake, a client
126    can optimistically send a VERSIONS cell along with the final
127    AUTHORIZE cell of an authorization protocol. That allows the
128    bridge, in the case of successful authorization, to also process
129    the VERSIONS cell and begin the v3 handshake promptly.
130
131 4.5. What should actually happen when a bridge rejects an AUTHORIZE
132      cell?
133
134    When a bridge detects a badly formed or malicious AUTHORIZE cell,
135    it should assume that the other side is an adversary scanning for
136    bridges. The bridge should then act accordingly to avoid detection.
137
138    This proposal does not try to specify how a bridge can avoid
139    detection by an adversary.
140