[tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells

[Robert Ransom]

On 2011-11-04, George Kadianakis <desnacked at gmail.com> wrote:
>
> Filename: 189-authorize-cell.txt
> Title: AUTHORIZE and AUTHORIZED cells
> Author: George Kadianakis
> Created: 04 Nov 2011
> Status: Open
>
> 1. Overview
>
>    Proposal 187 introduced the concept of the AUTHORIZE cell, a cell
>    whose purpose is to make Tor bridges resistant to scanning attacks.
>
>    This is achieved by having the bridge and the client share a secret
>    out-of-band and then use AUTHORIZE cells to validate that the
>    client indeed knows that secret before proceeding with the Tor
>    protocol.
>
>    This proposal specifies the format of the AUTHORIZE cell and also
>    introduces the AUTHORIZED cell, a way for bridges to announce to
>    clients that the authorization process is complete and successful.
>
> 2. Motivation
>
>    AUTHORIZE cells should be able to perform a variety of
>    authorization protocols based on a variety of shared secrets. This
>    forces the AUTHORIZE cell to have a dynamic format based on the
>    authorization method used.
>
>    AUTHORIZED cells are used by bridges to signal the end of a
>    successful bridge client authorization and the beginning of the
>    actual link handshake. AUTHORIZED cells have no other use and for
>    this reason their format is very simple.
>
>    Both AUTHORIZE and AUTHORIZED cells are to be used under censorship
>    conditions and they should look innocuous to any adversary capable
>    of monitoring network traffic.

I wrote the following in my reply to proposal 190, but it probably
belongs here instead:

| An adversary who MITMs the TLS connection and receives a Tor AUTHORIZE
| cell will know that the client is trying to connect to a Tor bridge.
|
| Should the client send a string of the form "GET
| /?q=correct+horse+battery+staple\r\n\r\n" instead of an AUTHORIZE
| cell, where "correct+horse+battery+staple" is a semi-plausible search
| phrase derived from the HMAC in some way?


>    As an attack example, an adversary could passively monitor the
>    traffic of a bridge host, looking at the packets directly after the
>    TLS handshake and trying to deduce from their packet size if they
>    are AUTHORIZE and AUTHORIZED cells. For this reason, AUTHORIZE and
>    AUTHORIZED cells are padded with a random amount of padding before
>    sending.

What distribution should this 'random amount' be chosen from?


> 3. Design
>
> 3.1. AUTHORIZE cell
>
>    The AUTHORIZE cell is a variable-sized cell.
>
>    The generic AUTHORIZE cell format is:
>
>          AuthMethod                       [1 octet]
>          MethodFields                     [...]
>          PadLen                           [2 octets]
>          Padding                          ['PadLen' octets]
>
>    where:
>
>    'AuthMethod', is the authorization method to be used.
>
>    'MethodFields', is dependent on the authorization Method used. It's
>                    a meta-field hosting an arbitrary amount of fields.
>
>    'PadLen', specifies the amount of padding in octets.
>
>    'Padding', is 'PadLen' octets of random content.
>
> 3.2. AUTHORIZED cell format
>
>    The AUTHORIZED cell is a variable-sized cell.
>
>    The AUTHORIZED cell format is:
>
>          'AuthMethod'                       [1 octet]
>          'PadLen'                           [2 octets]
>          'Padding'                          ['PadLen' octets]
>
>    where all fields have the same meaning as in section 3.1.
>
> 3.3. Cell parsing
>
>    Implementations MUST ignore the contents of 'Padding'.
>
>    Implementations MUST reject an AUTHORIZE or AUTHORIZED cell where
>    the 'Padding' field is not 'PadLen' octets long.
>
>    Implementations MUST reject an AUTHORIZE cell with an 'AuthMethod'
>    they don't recognize.

What does "reject" mean here?


> 4. Discussion
>
> 4.1. 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.

What does "camouflaged" mean here?


> 4.2. How should multiple round-trip authorization protocols be handled?

s/multiple round/multiple-round/ # it's part of a phrase acting as an
ad-something

>    Protocols that require multiple round-trips between the client and
>    the bridge should use AUTHORIZE cells for communication.

.-1s/round-trips/round trips/ # it's part of a top-level noun phrase

>    The format of the AUTHORIZE cell is flexible enough to support
>    messages from the client to the bridge and the inverse.

s/inverse/reverse/

When can an AUTHORIZE cell be sent, and by whom?

Can a bridge which requires client authorization perform reachability
and bandwidth self-tests?  If so, how?


>    In the end of a successful multiple round-trip protocol, an
>    AUTHORIZED cell must be issued from the bridge to the client.

.-1s/multiple round/multiple-round/ # it's part of a phrase acting as
an ad-something
s/In/At/

> 4.3. 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.
>
>    In the future, and in the example case of a v3 handshake, a client
>    can optimistically send a VERSIONS cell along with the final
>    AUTHORIZE cell of an authorization protocol. That allows the
>    bridge, in the case of successful authorization, to also process
>    the VERSIONS cell and begin the v3 handshake promptly.


Robert Ransom