[tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[s7r]

Hello,

George Kadianakis wrote:
> Nick Mathewson <nickm at torproject.org> writes:
> 
>> [ text/plain ]
>> Hi!  I thought I'd write this up while it was fresh in my mind.  It
>> could be used as an alternative method to the current proposed client
>> authentication mechanism.  We could implement both, or just this, or
>> just the other.
>>
>> My description here will be a bit terser than we'd want in a proper
>> proposal, but I wanted to share it.
>>
>> This design is based on George Kadianakis's client authentication
>> design; it won't make sense unless you've read it.
>>
> 
> OK people,
> 
> I have a more mature torspec branch now for your eyes and only.  Please
> see branch `prop224_client_auth_4` in my torspec repo:
>        https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4
> 
> The changes are based on the feedback and discussion on this thread.
> 
> The only real changes from `prop224_client_auth_3` is that it increases
> the max descriptor size to 50k, and it removes the username/password
> intro-level authorization.
> 
> Please let me know of anything that seems off, or anything that can make
> the proposal more readable. Otherwise, we should merge this upstream and
> move forward with fixing the already merged prop224 HSDir code.
> 
> Thanks!

It is very good. The hard limit raised to 50k is justified, and
excellent to remove the username/password intro-level authorization.

I would like to state, since I seen it in older posts on this thread,
that I dislike the idea of generating at client side low entropy ed25519
key pairs based on simple passwords. It may sound simple and good from
UX point of view, but we are decreasing the security of a very secure
auth scheme with it and enabling an over-the-hand practice that keys
come from client to HS and not vice-versa.

My 2 cents here are that keys should always be generated randomly by the
HS server, and distributed to clients (I think it's over the hand for
the HS server to use keys generated by clients, because the purpose is
for the HS server to secure itself against _everyone_ except some
users). For this I am thinking of a very simple tool, that reads the
auth-client data file in $DataDirectory/ that will just show a table like:

[ADD A CLIENT]
HS | client | pubkey | privkey | notes| actions             | date
                                       [revoke] [change key]

(of course available in console mode also with keyboard shortcuts for
commands)

Since we have no real reason to see the privkey of a client ever again
at the HS server side (unless the client loses it, but in this case we
regenerate fresh keys for security reasons), client privkeys can not be
written to disk at HS server side.

For saved authorized clients we display "******" on privkey column. When
a client is added, highlight the row with red or something signaling
privkey distribution phase and only keep the keys in RAM. After the
privkey has been copied and user checked a box with 2 confirmation
dialogs that state something like "I have distributed the key to the
client and i understand that it will be permanently deleted, and I could
need to regenerate the key for this client if he didn't get it." save
the pubkey, client name, etc to file and permanently delete the privkey.

If anything happens (client manager app is closed, power failure,
reboot, etc.) start over with new key pair. Same when a key for a client
needs to change, we only keep the client name from the table and create
fresh key following the same protocol.

The client mode of the auth tool will look like:

[ADD An ONION]
HS | notes | privkey | actions             | date
                      [delete] [change key]

(of course available in console mode also with keyboard shortcuts for
commands)

Here the auth tool will only append/modify data from client's torrc.

It's OK to save the privkeys in plain text at client side from my point
of view. We could do encryption with a passphrase but it will be
annoying: either the auth management tool needs to be a plugin of Tor
Browser so that it asks for the passphrase only one time on start /
first connection (otherwise is _very_ annoying for UX) - not everyone
uses Tor Browser and more important not everyone uses HS for web
browsing - maybe it's a ssh server, either the tool itself needs to run
in background all the time.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161125/146d8d5d/attachment.sig>