diff options
author | Nick Mathewson <nickm@torproject.org> | 2023-12-14 19:45:40 +0000 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2023-12-14 19:45:40 +0000 |
commit | 34038400f099bcf5c540c7c6a90e24d4ac8051d9 (patch) | |
tree | fee37cf0c755985f285edc6ef8b144318f12518f | |
parent | 5281b86b9de0a2c244e9fc8017f25bd4b6b90616 (diff) | |
parent | 0b9508fa4407ca50aa6b737e6e10442809f7b556 (diff) | |
download | torspec-34038400f099bcf5c540c7c6a90e24d4ac8051d9.tar.gz torspec-34038400f099bcf5c540c7c6a90e24d4ac8051d9.zip |
Merge branch 'channel' into 'main'
negotiating-channels: rework followup from !226
See merge request tpo/core/torspec!238
-rw-r--r-- | spec/tor-spec/negotiating-channels.md | 83 |
1 files changed, 42 insertions, 41 deletions
diff --git a/spec/tor-spec/negotiating-channels.md b/spec/tor-spec/negotiating-channels.md index a95d4db..b428594 100644 --- a/spec/tor-spec/negotiating-channels.md +++ b/spec/tor-spec/negotiating-channels.md @@ -167,19 +167,7 @@ A CERTS cell MUST have no more than one certificate of any CertType. ### Authenticating the responder from its CERTS {#auth-responder} -The responder's CERTS cell is meant to prove -that the responder posses one or more -[relay identities](./relay-keys.md#identity). -It does this by containing certificate chains -from each relay identity key -to the TLS certificate presented during the TLS handshake. - -> The responder's ownership of that TLS certificate -> was already proven during the TLS hadnshake itself. - -From a CERTS cell, -an initiator has enough information to authenticate the responder. -To do so, the initiator MUST check that all of the following apply: +The responder's CERTS cell is as follows: - The CERTS cell contains exactly one CertType 4 Ed25519 `IDENTITY_V_SIGNING_CERT`. @@ -197,25 +185,56 @@ To do so, the initiator MUST check that all of the following apply: that was presented curing the TLS handshake. - All of the certs above must be correctly signed, and not expired. -It the above tests all pass, +The initiator must check all of the above. +If this is successful the initiator knows that the responder has the identity `KP_relayid_ed`. +> The responder's CERTS cell is meant to prove +> that the responder posses one or more +> [relay identities](./relay-keys.md#identity). +> It does this by containing certificate chains +> from each relay identity key +> to the TLS certificate presented during the TLS handshake. + +> The responder's ownership of that TLS certificate +> was already proven during the TLS hadnshake itself. ### Validating an initiator's CERTS {#validate-initiator-certs} +When required +by [other parts of this specification](./channels.md#does-initiator-authenticate); +to prove its identity, +the initiator must provide a CERTS cell. -An initiator's CERTS cell -differs from a responders CERTS cell -in that it contains a `SIGNING_V_LINK_AUTH` certificate -instead of a `SIGNING_V_TLS_CERT` certificate. +> Recall that +> [not all initiators authenticate themselves](./channels.md#does-initiator-authenticate); +> bridges and clients do not prove their identity. +The initiator's CERTS cell must conform to the rules +for the responder's CERTS cell (see above, +exchanging "initiator" and "responder") +except that: -> First, recall that -> [not all initiators authenticate themselves](./channels.md#does-initiator-authenticate); -> bridges and clients do not do so. -> -> Second, if the initiator *does* choose to authenticate: +**Instead** of containg a `SIGNING_V_TLS_CERT`, + +- The CERTS cell contains exactly one CertType 6 + `SIGNING_V_LINK_AUTH` certificate. + - This certificate must be signed with `KP_relayid_ed`. + (Its subject key is deemed to be `KP_link_ed`.) +- All of the certs above must be correctly signed, and not expired. + +The responder must check all of the CERTS cell's properties +(as stated here, and in the previous section). +If this is successful +**and** +the initiator later sends a valid +[AUTHENTICATE cell](#AUTHENTICATE-cells), +then the initiator has ownership of the presented `KP_relayid_ed`. + +> Note that +> the CERTS cell is _not_ yet sufficent to authenticate the channel, +> until AUTHENTICATE is received: > unlike the responder, > the initiator is not required to present a TLS certificate > during the TLS handshake. @@ -228,24 +247,6 @@ instead of a `SIGNING_V_TLS_CERT` certificate. > This key is later used to sign an "authentication challenge", > and bind it to the channel. -To process an initiator's CERTS cell, -the responder MUST procede as for a responder's certificates, -[as described above](#auth-responder), -except that **instead** of checking for a `SIGNING_V_TLS_CERT`, -it must verify that: - -- The CERTS cell contains exactly one CertType 6 - `SIGNING_V_LINK_AUTH` certificate. - - This certificate must be signed with `KP_relayid_ed`. - (Its subject key is deemed to be `KP_link_ed`.) -- All of the certs above must be correctly signed, and not expired. - -This is _not_ yet sufficent to authenticate the channel. -It only proves that -_if_ the initiator can send a valid -[AUTHENTICATE cell](#AUTHENTICATE-cells), -then the initiator has the presented `KP_relayid_ed`. - ### Authenticating an RSA identity (#auth-RSA) After processing a CERTS cell |