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

[George Kadianakis <desnacked@xxxxxxxxxx>]

George Kadianakis <desnacked@xxxxxxxxxx> writes:

> [ text/plain ]
> Nick Mathewson <nickm@xxxxxxxxxxxxxx> 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.
>>
>> =============
>>
>> Let every client generate a curve25519 keypair, and tell the hidden
>> service operator about the public key.  This keypair takes the place
>> of the long-term shared secret.  For some client C, denote the secret
>> key as x_X and the public key as X_C.
>>
>> For every descriptor, the hidden service generates a fresh keypair <y,
>> Y>, and includes Y in the the outer encrypted layer.
>>
>> Now, for each client, the hidden service computes curve25519(X_C, y)
>> and uses this as the input for two KDF functions. Call these outputs
>> K1_C and K2_C.  The hidden service generates an auth-client line for
>> each client as follows:
>>
>>    "auth-client" SP client-id SP encrypted-cookie
>>
>> This is the same as in George's proposal, except that client-id is
>> derived from a truncated version of K1_C, and the encrypted-cookie
>> portion is encrypted based on K2_C.
>>
>>
>> When the client receives the descriptor, it decrypts the outer layer,
>> then sees the value of Y that the hidden server advertised.  It
>> computes curve25519(Y, x_c), and derives K1_C and K2_C.  It uses K1_C
>> to find the appropriate entry on the list, and then uses K2_C to
>> decrypt it and find the descriptor cookie.
>>
>> =============
>>
>> Advantages:
>>   * managing public keys can be easier than managing shared secrets.
>>   * The encoding is slightly shorter, since no IV is needed, since K2
>> is different every time.
>>   * probably others?
>>
>> Disadvantages:
>>   * Curve25519 costs more computationally than non-public-key operations
>>   * probably others?
>>
>>
>
> Hey Nick,
>
> thanks for the feedback on the torspec patch and this scheme. I'll wait
> to figure out if we want to use this scheme before updating the torspec
> patch further.
>
> This proposed scheme seems like a good idea. It basically switches the
> identity of authed clients from symmetric keys to x25519 keys, which
> seems more intuitive and correct.
>       
> I wonder if clients could/should use the same keypair for intro-layer
> authentication as well. Section 3.4.2 currently specifies how to do
> intro-layer auth using ed25519 keys, so perhaps we can use a single
> curve25519 key (and switch it between ed25519 and x25519) to perform
> both descriptor-layer and intro-layer authentication?
>
> WRT the suggested scheme, I think my biggest concern here is the UX, and
> specifically this phrase
>
>   "Let every client generate a curve25519 keypair, and tell the hidden
>   service operator about the public key".
>
> The client auth UX currently involves the HS operator passing
> credentials to the clients, not the other way around. This is good for
> UX since it means that all configuration is performed by the HS operator
> (who can be assumed technical), instead of its clients (who should be
> assumed to be non-technical). All clients need to do is copy-paste the
> auth line to their torrc. I feel like this UX should be maintained,
> except if there is a very strong reason to break it.
>

OK, I think sooner or later we needed to have a UX discussion about HS
client authorization!

The current rend-spec.txt specifies the torrc options for client auth in
sections 2.3/2.4. We don't do this in prop224 yet, but I think it's
useful because figuring out the torrc format now will help us understand
if the scheme we are making is useful.

Here is a rough proposed UX for prop224 client auth, using Nick's idea
from the top post of this thread. FWIW, I've used the same torrc option
naming as we currently have but we should probably introduce new ones.

-- Hidden Service configuration

A hidden service uses the following torrc line to specify authed clients:

     HiddenServiceAuthorizeClient <auth-type> <client-name>,<client-name>,...

If this option is configured, Tor generates client authorization data
and creates a new "hs_client_auth.txt" file which contains lines with the
following format:

    client-name <client-name> NL
    HidServAuth <onion-address> <desc-x25519-privkey-b64> <intro-ed25519-privkey-b64>  NL

where <client-name> is a nickname for the authed client,
<desc-x25519-key-privb64> is an x25519 private key used to generate
descriptor encryption keys (as Nick specified in top mail), and
<desc-ed25519-privkey-b64> is an ed25519 private key used to perform the
INTRO1 authorization protocol (as specified in section 3.4.2 of prop224).

e.g.
    client-name alice
    HidServAuth a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion 2vMVLDEAu+rc0rXFONpnor9mfG5xj0ovSh+YWIvOAvQ= qtXjslfyvPokRGFkzGnTXK7ICUNnoFyQRMORN/Zn4ss= 
    client-name bob
    HidServAuth a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion /ADODiu4Dq6n+Oc5PGkmWmS72OEO9J46DTIWh8Omkck= QlQf+Bsukgjp8iGbdCuCihHHrbp6csN3yDFe8SSaTXU=
    client-name charlie
    HidServAuth a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion /ADODiu4Dq6n+Oc5PGkmWmS72OEO9J46DTIWh8Omkck= QlQf+Bsukgjp8iGbdCuCihHHrbp6csN3yDFe8SSaTXU=

The idea here is that HS operators find the right HidServAuth line and
paste it to their clients out-of-band, who then copy pastes it into
their torrc file (or ideally plug it through tor browser in the future).

We should also make it possible for clients to provide their own private
keys. We should introduce a keygen command for clients which generates a
"HidServAuth" line, and then they can pass it to the HS operator, who
puts it in their hs_client_auth.txt. Unclear what's the best UX way to
do this; probably it should be a tor browser utility or sth...

-- Client configuration

For client configuration, we use the HidServAuth format intact from
above. So basically, clients can add HS client auth information by
placing the following lines in their torrc:

    HidServAuth <onion-address> <desc-x25519-privkey-b64> <intro-ed25519-privkey-b64>

where format is as explained above.

-- Discussion

Here are some topics for discussion:

- Can we improve the service-side file format for hs_client_auth.txt?
  It kind of sucks big time...

  Perhaps a new file should be made for each authed client and put in a
  special client-auth/ dir? Or perhaps we have already lost the UX game
  here, and we should instead provide a utility for services and clients
  that handles the authorization credential encoding and configuration?

- What's up with the username/password intro-level auth specified in
  prop224 section 3.4.1? I guess the whole point for having
  username/password auth is so that they are memorable. However, if we
  always require a descriptor-level x25519 auth key anyhow, we don't get
  much by making the intro-level credentials human memorable.

  Should we just ditch the username/password method completely for now?
  Or alternatively (and more crazy) we should generate x25519 private
  keys using the low-entropy human-memorable username/password combo.

- What changes do we need in tor browser to make hidden service
  authorization more useful? We should probably involve the UX team
  here.

- Should we use a single curve25519 public key for client-auth and
  transform it between ed25519 and curve25519 instead of having two
  separate keys? I decided to go with the conservative approach, as the UX
  benefits are not that great.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev