[zeromq-dev] Curvezmq guide on handshake etc. could use some clarifications

Jonas Thiem jonasthiem at googlemail.com
Thu Oct 2 16:32:32 CEST 2014


Hi,

Thanks for your response!

Since you referred me to zauth functionality instead of answering the 
question, I took the time to dig out the only manual section on zauth 
which I could find:

http://czmq.zeromq.org/manual:zauth

If there is also some sort of guide for czmq similar to the one on curve 
or libzmq itself which explains this in more detail, then sorry that I 
didn't find it - I'm happy to give it a read if there is one!

The question I have doesn't seem to be answered in that specific manual 
section. It only mentions "curve authentication", which I could find 
only here: http://curvezmq.org/page:read-the-docs#toc19

But that part of the guide doesn't say if verifying a client by public 
key means it needs to own the according private key, or if that just 
means it will be sent data by the server encrypted with that public key 
and it won't be able to do much without the correct private key after 
the login phase anyway but still will be able to connect as long as it 
brings up that public key during the login (which makes a huge 
difference to our project).

So does zauth also verify that the client owns the according private key 
and is able to decrypt stuff properly? What does "happens automatically" 
(as you formulated it) mean here? It would be helpful if you could 
elaborate.

I suppose the most obvious guess is that the private key needs to be 
owned by the clients just to authenticate, but we'd rather have a 
definite answer on this instead of guessing.

Furthermore I'd suggest:

1. This question should be made more clear on either the zauth page I 
linked or the curve authentication section, since it only vaguely speaks 
of verification by public key but not of this specific issue

2. The zauth unit test should maybe also include a negative case for the 
full zmq auth case, right? I tried to write one up which should 
illustrate what I'm after:

     // Generate an invalid client cert where the private key part is off:
     // (assuming a scenario where we got the valid public key, and made up
     //  some random unsuitable private key which cannot actually decrypt
     //  things)
     byte *new_client_cert_public = zcert_public_key (client_cert);
     zcert_t *invalid_client_cert = zcert_new();
     byte *new_client_cert_private = zcert_secret_key (invalid_client_cert);
     zcert_t *client_cert_invalid_private_key = zcert_new_from (
         new_client_cert_public, new_client_cert_private);

     // Full client authentication, negative case:
     zcert_apply (server_cert, server);
     zcert_apply (client_cert_invalid_private_key, client);
     zsocket_set_curve_server (server, 1);
     zsocket_set_curve_serverkey (client, server_key);
     zcert_save_public (client_cert, TESTDIR "/mycert.txt");
     zauth_configure_curve (auth, "*", TESTDIR);
     success = s_can_connect (ctx, &server, &client);
     assert (!success);

3. The test on the page I linked seems to be included in zauth.c in CZMQ 
2.2.0. However, it fails if actually executed on Ubuntu 14 LTS:
lt-czmq_selftest: zsockopt.c:286: zsocket_set_curve_server: Assertion 
`rc == 0 || zmq_errno () == (156384712 + 53)' failed.
(without my test modifications)
I wanted to try it on Fedora 21 too but couldn't, see below.

4. CZMQ 2.2.0 doesn't build at all on Fedora 21 with gcc 4.9.1, maybe 
someone should look into that :-)
   CC     zauth.lo
In file included from /usr/include/ctype.h:25:0,
                  from ../include/czmq_prelude.h:203,
                  from ../include/czmq.h:19,
                  from zauth.c:25:
/usr/include/features.h:148:3: error: #warning "_BSD_SOURCE and 
_SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp]
  # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use 
_DEFAULT_SOURCE"
    ^
cc1: all warnings being treated as errors

Regards,
Jonas Thiem

On 09/22/2014 08:49 AM, Pieter Hintjens wrote:
> The authenticator uses the same model as CZMQ's zauth module. That is,
> you provide it with the list of valid client keys, and the rest
> happens automatically.
>
> On Mon, Sep 22, 2014 at 7:58 AM, Jonas Thiem <jonasthiem at googlemail.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Pieter,
>>
>> Thanks for clearing those things up!
>>
>> Regarding client verification, I am not entirely sure how the PyZMQ
>> authenticator works:
>> http://zeromq.github.io/pyzmq/api/zmq.auth.html#zmq.auth.Authenticator
>>
>> Does it use the ZAP handler as you described? If I submit a public key
>> list with the location parameter, will it actually ensure the client
>> has the according secret key by sending it some challenge value to
>> decrypt and send back or something? Or is that something which PyZMQ
>> expects me to do myself?
>>
>> Regards,
>> Jonas Thiem
>>
>> On Sat, Sep 20, 2014 at 10:11 AM, Pieter Hintjens <ph at imatix.com> wrote:
>>> Hi Jonas,
>>>
>>> Sorry for the slow answer.
>>>
>>>> 1. Is the initial HELLO from the client to the server
>>>> unencrypted?
>>>
>>> Partially, yes. The client sends an encrypted signature box that
>>> only the server can decode.
>>>
>>>> 2. Is the client ever required to have his secret key to read
>>>> something during the handshake process?
>>>
>>> No, the client long-term secret key is never used. The long term
>>> public key is sent, encrypted in INITIATE, and is used for
>>> authentication. In cases where authentication is not done, clients
>>> are anonymous and their long-term keys are irrelevant. We do not
>>> use the long term keys (server or client) for messages. All
>>> traffic is encrypted using transient keys.
>>>>
>>>> That would mean for a protocol where sending administration
>>>> commands under some client identity without necessarily reading
>>>> the response, curve zmq wouldn't sufficiently ensure the client's
>>>> identity.
>>>
>>>> 3. If the client's identity isn't ensured, does the zmq
>>>> authenticator - given a list of valid public keys - do this?
>>>
>>> The client sends its long term public key encrypted in INITIATE.
>>> The server can authenticate this, or accept it blindly, as it
>>> like. In libzmq this happens in the ZAP handler.
>>>
>>> -Pieter _______________________________________________ zeromq-dev
>>> mailing list zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJUH7p9AAoJEBIDTbbx8YkeQ94QAMQ2R/D/tBRq4kqrWbYUwmO6
>> UhvTnu7udbfTdD08rgM4XGt3BlL71tLtl6+xDBDRfwvyCWm4EblA/ms3KHrDpI0r
>> xozIFHkZOfNRveVXyNxws0bZJ3S23SIiuSEjJW4Mue/H8X5V4GAlQNu4LTtx3boj
>> bf8F3VEL0y5bmCcb1IWyF4bCZB1H0c1ii3zecouSvVqualpUZfZyqgli7EVRDAcu
>> yeL05cuD7JH/87YEO0fhi8fHE+OgwNP7ri6DtKrv3+VsfOO3QPF6aUy/ZJuw+6+H
>> 3/XLDtNWDDC+PYHLwsSnF1sgyO8EFxZHHkLLTXt/hr6U6QOEJHyEC3TdL4/5hyuN
>> sYKbejAbfmE5vv2BwL2J9P3ZiC4VXtxSv8sYMKldr6SdLUg382tYzoHQ7KODxdzF
>> ZsWX3gIG3HHN/RP8dnm9MDKc+zvHgH+w7AmUpa979s7GYdjJVQQPkAknNI3gVu9h
>> 8SnSGbfRKm0QUfS8iYEkwjnrFOgWzBuK2c8Uk3bMYw9srX1d37tp6RS8PxtlG64Y
>> ufxV1+T+ElFOzlHnNKBFblLyNE11avGoMQ7wBWWfWC9q1DnYVi3Ow+jdam2/9pds
>> +v5KliDYmDUSlk3MNEvjw+gAaZNqUJAoIRs41Y0mtueaaluZI2/eJsKZbSly2zXb
>> ZehDSk8c4+v3o/GFdlr7
>> =3Q0x
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list