From: Karsten Loesing Date: Fri, 1 Aug 2008 11:19:43 +0000 (+0000) Subject: Proposal 121: Use first part of Diffie-Hellman handshake for replay protection instea... X-Git-Tag: tor-0.2.1.3-alpha~3 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=666e179ded27e5fa8d3c2f63d3049e65af6790be;p=thirdparty%2Ftor.git Proposal 121: Use first part of Diffie-Hellman handshake for replay protection instead of rendezvous cookie. svn:r16327 --- diff --git a/doc/spec/proposals/121-hidden-service-authentication.txt b/doc/spec/proposals/121-hidden-service-authentication.txt index 971572dd12..149ba7affb 100644 --- a/doc/spec/proposals/121-hidden-service-authentication.txt +++ b/doc/spec/proposals/121-hidden-service-authentication.txt @@ -28,6 +28,8 @@ Change history: with Nick 31-Jul-2008 Limit maximum descriptor size to 20 kilobytes to prevent abuse. + 01-Aug-2008 Use first part of Diffie-Hellman handshake for replay + protection instead of rendezvous cookie. Overview: @@ -385,10 +387,13 @@ Details: When receiving a v3 INTRODUCE2 cell, Bob checks whether a client has provided valid authorization data to him. He also requires that the timestamp is no more than 30 minutes in the past or future and that the - rendezvous cookie has not been used in the past 60 minutes to prevent - replay attacks by rogue introduction points. If all checks pass, Bob - builds a circuit to the provided rendezvous point and otherwise drops the - cell. + first part of the Diffie-Hellman handshake has not been used in the past + 60 minutes to prevent replay attacks by rogue introduction points. (The + reason for not using the rendezvous cookie to detect replays---even + though it is only sent once in the current design---is that it might be + desirable to re-use rendezvous cookies for multiple introduction requests + in the future.) If all checks pass, Bob builds a circuit to the provided + rendezvous point and otherwise drops the cell. 1.4. Summary of authorization data fields