[tor-dev] HS v3 client authorization types

Fri Apr 27 20:08:14 UTC 2018

As I am currently implementing the client authorization for onion
service v3 (https://github.com/torproject/tor/pull/36), I found some
problems in how we should let the users configure the client auth for
their services.

Before getting into the problem, I will explain how it works first.

--
Each client will have two private keys to authenticate with the service.
One is x25519 key and the other is ed25519 key.

The x25519 one is used to decrypt the descriptor when the client wants
to access the service, so if the client is not authorized, it will never
know the introduction points, the intro auth keys, and so on, and then
it absolutely cannot access the service.

The ed25519 one is for another layer of authentication. Even if the
client can decrypt the descriptor using the x25519 private key, it still
need to have the ed25519 to authenticate itself directly to the service
using the extension field in INTRODUCE1 cell.

At first glance, it seems that the ed25519 one is not necessary because,
if the client is able to decrypt the descriptor, it already means the
client is already authenticated. Why do we need to have another layer of
authenticate?

The answer is that the ed25519 provides more find-grained access control
for example:

1) you could use it to revoke a client without the need to rotate all
the intro points and push new descriptor.
2) you can have more fine-grained control on your users and potentially
offer different types of access structure to different users using their
ed25519 keys as identifier.
--

The spec says that the client must have both keys and use both to
authenticate, but, for me, these two things are quite independent. I
think they can be considered two different authentication types. The
service should be able to enable one and disable the other. For example,
If I disable the x25519 while I enable ed25519, I can add a new client
immediately without the need to rotate the intro points.

If rotating intro points is not an issue and the only purpose of ed25519
is to have more fine-grained access control, the current spec is fine.
But if rotating intro points is an issue, we should rethink about this.

So, I created a PR for the change in torspec.
https://github.com/torproject/torspec/pull/7
(in the PR, the x25519 auth is called 'basic' and the ed25519 auth is
called 'intro')

We need your opinions about this.
Should we let the service enable one while disable the other?
Or should we require the service to enable both for all clients?

If you want to let the service be able to enable one while disable the
other, do you have any opinion on how to configure the torrc?

Cheers,
haxxpop

This is a discussion log that we had earlier.

[22:39:23] <meejah> v3 "basic" auth is different from v2 "basic" auth,
right? Perhaps a different name-string for the v3 one would be good?
[22:39:44] <asn> meejah: good point
[22:39:57] <asn> perhaps we can name it "pubkey" auth or something more UX-y
[22:40:35] <meejah> asn: sounds good to me (my perspective is to avoid
naming-weirdness for controllers and having to explain to users "well,
this 'basic' is different from this other 'basic' because you said
version=3")
[22:40:43] <asn> right
[22:40:44] <asn> makse sense
[22:40:51] <asn> haxxpop: ^ what do u think
[22:40:51] <asn> ?
[22:45:01] <haxxpop> meejah, asn yes I agreed. maybe we should change it
to something else
[22:46:10] <haxxpop> meejah, asn In fact, the word 'basic' appears only
once in the v3 spec !
[22:48:05] <asn> haxxpop: yeah... perhaps we can rename it to "pubkey"
which describes it pretty well for nerds. or to "standard" which is a
synonym for "basic" and it will confuse everyone.
[22:50:59] <haxxpop> asn, I think both "basic" and "intro" use pubkeys.
[22:51:26] <haxxpop> asn, I think if we call "basic" "pubkey", it may
imply that "intro" doesn't use pubkeys.
[22:51:35] <asn> true
[22:52:20] <asn> i'm still not sure if i like:
[22:52:20] <asn>  +        HiddenServiceAuthorizeClient basic
client-name,client-name,...
[22:52:20] <asn>  +        HiddenServiceAuthorizeClient intro
client-name,client-name,...
[22:52:30] <asn> mainly because it's gonna be quite hard to explain to
people what these two lines mean
[22:52:34] <asn> (to hs operators)
[22:52:37] <asn> like what's the difference
[22:52:42] <asn> and usually they should have both enabled
[22:52:53] <asn> what i imagined initially is that we would keep the
torrc logic the same
[22:53:04] <asn> and maybe expose a torrc option for advanced users to
do HiddenServiceDisableIntroAuth
[22:53:07] <asn> or something
[22:53:11] <asn> anyway i need to think about this!
[22:53:25] <haxxpop> asn, Nice point
[23:08:35] <meejah> asn: haxxpop: "pubkey" sounds good to me. People who
are "just clients" probably don't care what the string is (? maybe? UX
people?) and people running the services probably count as "nerds" :)
[23:08:59] <asn> agreed
[23:09:02] <meejah> (but, I don't personally understand what these
schemes are so maybe I shouldn't be naming them ;)
[23:09:08] <asn> ideally those things should not be exposed to the users
anyway
[23:09:19] <asn> they should be wrapped by the browser or something
[23:11:46] <meejah> asn: in txtorcon at least, they aren't really;
preferred new-API is "async with tor.onion_authentication(onion_host,
some_auth_object)" for py3, or "tor.add_onion_authentication(..)" --
ideally this can be used by "actual application" to transmit the
credentials to users in some way
[23:11:52] <meejah> (e.g. maybe via magic-wormhole)
[23:12:35] <meejah> I assume that *ideally* the clients generate
keypairs, and send pubkeys to the service..?
[23:22:45] <asn> meejah: yes ideally clients generate keypairs
[23:23:00] <asn> meejah: but service-generated keypairs can also be
done, to immitate current symmetric-key design
[23:26:08] <dmr> asn: there's lots of reasons to keep v2 "basic"
separate from v3 "basic" - limited bug reports, presentations, error/log
messages, internet searches, ...
[23:26:34] <dmr> like meejah I also don't know what the schemes are, so
that's the extent of my input :)
[23:26:51] <dmr> glad to hear it sounds like we're all in agreement to
use something other than "basic" for v3
[23:46:12] <meejah> asn: okay, ack. It would be neat to see an
application using magic-wormhole for an "invite a new client" flow;
perhaps I'll try a PoC when v3-auth is available; is it in master already??

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