[or-cvs] r19356: {tor} Update the port knocking SPA document to have more details. (tor/trunk/doc/spec/proposals/ideas)

[ioerror at seul.org]

Author: ioerror
Date: 2009-04-21 03:55:07 -0400 (Tue, 21 Apr 2009)
New Revision: 19356

Modified:
   tor/trunk/doc/spec/proposals/ideas/xxx-port-knocking.txt
Log:
Update the port knocking SPA document to have more details. Still needs a packet filter.


Modified: tor/trunk/doc/spec/proposals/ideas/xxx-port-knocking.txt
===================================================================
--- tor/trunk/doc/spec/proposals/ideas/xxx-port-knocking.txt	2009-04-21 04:06:49 UTC (rev 19355)
+++ tor/trunk/doc/spec/proposals/ideas/xxx-port-knocking.txt	2009-04-21 07:55:07 UTC (rev 19356)
@@ -35,7 +35,7 @@
 bridge. This should be done with Tor and if possible without the help of the
 firewall. It should be possible for a Tor user to enter a secret key into
 Tor or optionally Vidalia on a per bridge basis. This secret key should be
-used
+used to authenticate the bridge user to the private bridge.
 
 1.x Issues with low ports and bind() for ORPort
 
@@ -71,6 +71,23 @@
 possible to encode SPA as valid DNS requests. This should allow use of the
 public DNS infrastructure for authorization requests if desired.
 
+2.x Ghetto firewalling with opportunistic connection closing
+
+Until a user has authenticated with Tor, Tor only has a UDP listener. This
+listener should never send data in response, it should only open an ORPort
+when a user has successfully authenticated. After a user has authenticated
+with Tor to open an ORPort, only users who have authenticated will be able
+to use it. All other users as identified by their ip address will have their
+connection closed before any data is sent or received. This should be
+accomplished with an access policy. By default, the access policy should block
+all access to the ORPort.
+
+2.x Timing and reset of access policies
+
+Access to the ORPort is sensitive. The bridge should remove any exceptions
+to its access policy regularly when the ORPort is unused. Valid users should
+reauthenticate if they do not use the ORPort within a given time frame.
+
 2.x Additional considerations
 
 There are many. A format of the packet and the crypto involved is a good start.