diff options
Diffstat (limited to 'spec/rend-spec-v3/introduction-protocol-intro-protocol.md')
| -rw-r--r-- | spec/rend-spec-v3/introduction-protocol-intro-protocol.md | 62 |
1 files changed, 31 insertions, 31 deletions
diff --git a/spec/rend-spec-v3/introduction-protocol-intro-protocol.md b/spec/rend-spec-v3/introduction-protocol-intro-protocol.md index e1977fc..f4e6358 100644 --- a/spec/rend-spec-v3/introduction-protocol-intro-protocol.md +++ b/spec/rend-spec-v3/introduction-protocol-intro-protocol.md @@ -1,6 +1,6 @@ <a id="rend-spec-v3.txt-3"></a> -# The introduction protocol [INTRO-PROTOCOL] +# The introduction protocol \[INTRO-PROTOCOL\] The introduction protocol proceeds in three steps. @@ -30,11 +30,11 @@ the introduction request to the client. <a id="rend-spec-v3.txt-3.1"></a> -## Registering an introduction point [REG_INTRO_POINT] +## Registering an introduction point \[REG_INTRO_POINT\] <a id="rend-spec-v3.txt-3.1.1"></a> -### Extensible ESTABLISH_INTRO protocol. [EST_INTRO] +### Extensible ESTABLISH_INTRO protocol. \[EST_INTRO\] When a hidden service is establishing a new introduction point, it sends an ESTABLISH_INTRO cell with the following contents: @@ -115,7 +115,7 @@ later in INTRODUCE1 cells. <a id="rend-spec-v3.txt-3.1.1.1"></a> -#### Denial-of-Service Defense Extension. [EST_INTRO_DOS_EXT] +#### Denial-of-Service Defense Extension. \[EST_INTRO_DOS_EXT\] This extension can be used to send Denial-of-Service (DoS) parameters to the introduction point in order for it to apply them for the introduction @@ -127,7 +127,7 @@ defined as follow: EXT_FIELD_TYPE: -[01] -- Denial-of-Service Parameters. +\[01\] -- Denial-of-Service Parameters. ```text If this flag is set, the extension should be used by the introduction @@ -189,7 +189,7 @@ Introduced in tor-0.4.2.1-alpha. Tor nodes should also support an older version of the ESTABLISH_INTRO cell, first documented in rend-spec.txt. New hidden service hosts must use this format when establishing introduction points at older -Tor nodes that do not support the format above in [EST_INTRO]. +Tor nodes that do not support the format above in \[EST_INTRO\]. In this older protocol, an ESTABLISH_INTRO cell contains: @@ -215,7 +215,7 @@ authentication keys. <a id="rend-spec-v3.txt-3.1.3"></a> -### Acknowledging establishment of introduction point [INTRO_ESTABLISHED] +### Acknowledging establishment of introduction point \[INTRO_ESTABLISHED\] After setting up an introduction circuit, the introduction point reports its status back to the hidden service host with an INTRO_ESTABLISHED cell. @@ -232,15 +232,15 @@ The INTRO_ESTABLISHED cell has the following contents: Older versions of Tor send back an empty INTRO_ESTABLISHED cell instead. Services must accept an empty INTRO_ESTABLISHED cell from a legacy relay. -[The above paragraph is obsolete and refers to a workaround for -now-obsolete Tor relay versions. It is included for historical reasons.] +\[The above paragraph is obsolete and refers to a workaround for +now-obsolete Tor relay versions. It is included for historical reasons.\] The same rules for multiplicity, ordering, and handling unknown types -apply to the extension fields here as described [EST_INTRO] above. +apply to the extension fields here as described \[EST_INTRO\] above. <a id="rend-spec-v3.txt-3.2"></a> -## Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1] +## Sending an INTRODUCE1 cell to the introduction point. \[SEND_INTRO1\] In order to participate in the introduction protocol, a client must know the following: @@ -267,7 +267,7 @@ or that its request will not succeed. <a id="rend-spec-v3.txt-3.2.1"></a> -### INTRODUCE1 cell format [FMT_INTRO1] +### INTRODUCE1 cell format \[FMT_INTRO1\] When a client is connecting to an introduction point, INTRODUCE1 cells should be of the form: @@ -285,8 +285,8 @@ should be of the form: ENCRYPTED [Up to end of relay payload] ``` -AUTH_KEY_TYPE is defined as in [EST_INTRO]. Currently, the only value of -AUTH_KEY_TYPE for this cell is an Ed25519 public key [02]. +AUTH_KEY_TYPE is defined as in \[EST_INTRO\]. Currently, the only value of +AUTH_KEY_TYPE for this cell is an Ed25519 public key \[02\]. The LEGACY_KEY_ID field is used to distinguish between legacy and new style INTRODUCE1 cells. In new style INTRODUCE1 cells, LEGACY_KEY_ID is 20 zero @@ -306,11 +306,11 @@ change the order or multiplicity of the extensions sent by the client.) The same rules for multiplicity, ordering, and handling unknown types -apply to the extension fields here as described [EST_INTRO] above. +apply to the extension fields here as described \[EST_INTRO\] above. <a id="rend-spec-v3.txt-3.2.2"></a> -### INTRODUCE_ACK cell format. [INTRO_ACK] +### INTRODUCE_ACK cell format. \[INTRO_ACK\] An INTRODUCE_ACK cell has the following fields: @@ -331,11 +331,11 @@ An INTRODUCE_ACK cell has the following fields: ``` The same rules for multiplicity, ordering, and handling unknown types -apply to the extension fields here as described [EST_INTRO] above. +apply to the extension fields here as described \[EST_INTRO\] above. <a id="rend-spec-v3.txt-3.3"></a> -## Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2] +## Processing an INTRODUCE2 cell at the hidden service. \[PROCESS_INTRO2\] Upon receiving an INTRODUCE2 cell, the hidden service host checks whether the AUTH_KEY or LEGACY_KEY_ID field matches the keys for this @@ -353,8 +353,8 @@ contents of the cell as having been unmodified since they left the client. There may be multiple ways of decrypting the ENCRYPTED field, depending on the chosen type of the encryption key. Requirements for an introduction handshake protocol are described in -[INTRO-HANDSHAKE-REQS]. We specify one below in section -[NTOR-WITH-EXTRA-DATA]. +\[INTRO-HANDSHAKE-REQS\]. We specify one below in section +\[NTOR-WITH-EXTRA-DATA\]. The decrypted plaintext must have the form: @@ -380,7 +380,7 @@ Upon processing this plaintext, the hidden service makes sure that any required authentication is present in the extension fields, and then extends a rendezvous circuit to the node described in the LSPEC fields, using the ONION_KEY to complete the extension. As mentioned -in [BUILDING-BLOCKS], the "TLS-over-TCP, IPv4" and "Legacy node +in \[BUILDING-BLOCKS\], the "TLS-over-TCP, IPv4" and "Legacy node identity" specifiers must be present. As of 0.4.1.1-alpha, clients include both IPv4 and IPv6 link specifiers @@ -402,7 +402,7 @@ NOT modify it. The ONION_KEY_TYPE field is: -[01] NTOR: ONION_KEY is 32 bytes long. +\[01\] NTOR: ONION_KEY is 32 bytes long. The ONION_KEY field describes the onion key that must be used when extending to the rendezvous point. It must be of a type listed as @@ -428,11 +428,11 @@ will have: ``` The same rules for multiplicity, ordering, and handling unknown types -apply to the extension fields here as described [EST_INTRO] above. +apply to the extension fields here as described \[EST_INTRO\] above. <a id="rend-spec-v3.txt-3.3.1"></a> -### Introduction handshake encryption requirements [INTRO-HANDSHAKE-REQS] +### Introduction handshake encryption requirements \[INTRO-HANDSHAKE-REQS\] When decoding the encrypted information in an INTRODUCE2 cell, a hidden service host must be able to: @@ -504,7 +504,7 @@ and computes: ``` Substituting those fields into the INTRODUCE1 cell body format -described in [FMT_INTRO1] above, we have +described in \[FMT_INTRO1\] above, we have ```text LEGACY_KEY_ID [20 bytes] @@ -522,7 +522,7 @@ described in [FMT_INTRO1] above, we have MAC [MAC_LEN bytes] ``` -(This format is as documented in [FMT_INTRO1] above, except that here +(This format is as documented in \[FMT_INTRO1\] above, except that here we describe how to build the ENCRYPTED portion.) Here, the encryption key plays the role of B in the regular ntor @@ -570,7 +570,7 @@ introduction point encryption key 'b' to compute: ``` These fields will be sent to the client in a RENDEZVOUS1 cell using the -HANDSHAKE_INFO element (see [JOIN_REND]). +HANDSHAKE_INFO element (see \[JOIN_REND\]). The hidden service host now also knows the keys generated by the handshake, which it will use to encrypt and authenticate data @@ -580,7 +580,7 @@ AES-128 and SHA1 for this hop, we use AES-256 and SHA3-256. <a id="rend-spec-v3.txt-3.4"></a> -## Authentication during the introduction phase. [INTRO-AUTH] +## Authentication during the introduction phase. \[INTRO-AUTH\] Hidden services may restrict access only to authorized users. One mechanism to do so is the credential mechanism, where only users who @@ -601,7 +601,7 @@ the number of keys a user needs to have.) To authenticate with an Ed25519 private key, the user must include an extension field in the encrypted part of the INTRODUCE1 cell with an -EXT_FIELD_TYPE type of [02] and the contents: +EXT_FIELD_TYPE type of \[02\] and the contents: ```text Nonce [16 bytes] @@ -610,8 +610,8 @@ EXT_FIELD_TYPE type of [02] and the contents: ``` Nonce is a random value. Pubkey is the public key that will be used -to authenticate. [TODO: should this be an identifier for the public -key instead?] Signature is the signature, using Ed25519, of: +to authenticate. \[TODO: should this be an identifier for the public +key instead?\] Signature is the signature, using Ed25519, of: ```text "hidserv-userauth-ed25519" |