Re: Proposal: New PROTOCOLINFO command for controllers

[Roger Dingledine <arma@xxxxxxx>]

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).

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?

--Roger