Proposal: New PROTOCOLINFO command for controllers

[Nick Mathewson]

On Fri, Aug 24, 2007 at 02:00:27AM -0400, Roger Dingledine wrote:
> On Tue, Aug 14, 2007 at 02:29:41PM -0400, Nick Mathewson wrote:
> > >   Here we describe how to help controllers locate the cookie
> > >   authentication file when authenticating to Tor, so we can a) require
> > >   authentication by default for Tor controllers and b) still keep
> > >   things usable.
> > 
> > Also, this is an extensible, general-purpose mechanism that
> > controllers use to learn what kind of authentication is
> > needed/protocol is spoken before authenticating.
> 
> Matt has pointed out that right now Tor doesn't let you configure both
> CookieAuthentication and HashedControlPassword. I can't think of a
> reason for this -- it seems to me that if both are configured, then Tor
> should allow auth by either approach. Maybe in situations with multiple
> controllers, some of them would find reading a cookie file easier,
> and some would find remembering a password easier. We should let that
> happen; let me know if you see a reason not to. Nick also spoke of
> allowing multiple HashedControlPassword lines, and thus supporting
> several passwords (any of which will work).

This seems like a fine idea to me, and I don't see any reason not to
do it.

> 
> The next observation was that it's a bit hard for Tor to know *how* you're
> attempting to authenticate to it. Right now it looks at the argument to
> AUTHENTICATE, and if the first character is hex then it thinks you're
> trying a password, and if it's a quote then it thinks you're trying a
> cookie, and if it's empty it thinks you're trying a null
> authenticate.
> 
> > >   AuthMethod =
> > >     "NULL"           / ; No authentication is required
> > >     "HASHEDPASSWORD" / ; A controller must supply the original password
> > >     "COOKIE"         / ; A controller must supply the contents of a cookie
> 
> I suggest the AUTHENTICATE line should also allow you to say
> HASHEDPASSWORD=foo or COOKIE="bar" as arguments. This will let us one day
> add another type of auth that can't be distinguished just by the encoding
> of its argument. I guess for completeness we might accept NULL= as well.
> Since the current Tors won't accept the new more explicit approach,
> controllers should only use it when the protocolinfo response indicates
> a new enough Tor version.
> 
> Plausible?

This may be silly, but I was planning on just testing the provided
password against every configured authentication method, in order.
First, if we have a cookie, see if they gave us the cookie.  Then, for
each hashedpassword, hash the provided password with the same salt and
see whether it matches. Finally, if 'null' is set, then accept an
empty password.

reasonable?
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070824/1f72967e/attachment.pgp>