[zeromq-dev] Authentication with curve

[Pieter Hintjens]

OK, I remember how this is supposed to work. :-)

(BTW, happy 2014 to everyone!)

Here are our main constraints (in theory at least):

* We cannot send the metadata before authentication and final key
exchange as that would make it vulnerable to attacks.

* The canonical identification for the client is its long term key,
and any metadata associated with it (as in a certificate), rather than
anything sent/claimed by the client on its connection.

* The ZAP handler, as part of authentication, will also retrieve
metadata for the client long term key, and make that available to the
server-side application.

This moves away from using client identities, which mix two layers
(routing and identity), and thus are rather fragile. E.g. limited to
one connection per client, difficulty of recovery when a connection
dies, etc.

Now, what is missing is an API to recover metadata from the ZAP
handler. I can think of a few options. We could extend the zmq_msg API
to carry a metadata reference around with each message. We could
leverage the zmq_monitor API somehow.

Or, we could use another inproc:// protocol. That seems simplest... we
can do that without modifying libzmq at all.

1. we extend ZAP to add the client socket id to request and reply
2. we publish all ZAP replies to a secondary inproc:// socket (PUB-SUB)

Applications can now subscribe to ZAP replies and use those to
maintain their own tables of authenticated clients. They can then use
that to map each message to metadata.

The alternative is to maintain ZAP reply metadata internally per
connection in libzmq and make it available via a new API call. In any
case we need to add client socket ID to the ZAP request.

Thoughts?

-Pieter





On Wed, Jan 1, 2014 at 12:30 PM, Pieter Hintjens <ph at imatix.com> wrote:
> Oops. I'm wrong... the client metadata (including identity) is not
> sent until after authentication. There is no way for the ZAP handler
> to authenticate based on that. I'll think about how to solve this...
> sorry.
>
>
>
> On Wed, Jan 1, 2014 at 12:28 PM, Pieter Hintjens <ph at imatix.com> wrote:
>> The ZAP handler gets the identity of the client (along with all
>> metadata) and can validate it. So you can use client identity + public
>> key authentication, and then each message will report the
>> authenticated sender.
>>
>> On Tue, Dec 31, 2013 at 7:08 PM, Drew Crawford <drew at sealedabstract.com> wrote:
>>> I think I can supply a patch that is at least good enough to get cleaned up and merged by a zmq dev.  The open question at this point is which way the correlation should get resolved.  One possibility is to populate the ZAP identity with the router identity instead of the empty string.  Another possibility is to populate the userid from ZAP somewhere in the router.  There are other possibilities that have not occurred to me.
>>>
>>> I know enough to make a run at any of these, but not enough to identify the best solution from the set of options.  I’m hoping a dev can pop out of the woodwork and identify which solution is the one that should be tried.
>>>
>>> Drew
>>> On Dec 31, 2013, at 11:51 AM, Nicolas Delaby <ticosax at free.fr> wrote:
>>>
>>>> On 12/31/2013 06:30 PM, Drew Crawford wrote:
>>>>> Hi Nicolas,
>>>>>
>>>>> I’m reasonably sure we have the same problem, and I’ve gotten somewhat further along without solving it.  We may want to compare notes.  Take a look at my thread "How do I find out which ZAP user I'm talking to?”.
>>>>
>>>> Hi Drew,
>>>> Yes indeed, we are facing same issue.
>>>> So far I'm using an ugly hack assuming that the immediate next recv()
>>>> contains the identity of the peer I just authorized within my
>>>> zap_handler. This code is not used yet on production, so I believe it
>>>> works only by chance. I wanted to have confirmation from zeromq dev.
>>>>
>>>> My attitude on open-source project is to come with a pull request when
>>>> my needs are not fulfilled. But unfortunately C++ is way far beyond my
>>>> skills. So I hope to find here new ideas I didn't thought about it.
>>>>
>>>> Your testimony doesn't make me feel more confident :)
>>>>
>>>> As an ultimate workaround I will probably fallback on zmq.PLAIN + stunnel.
>>>>
>>>> Cheers,
>>>> Nicolas
>>>> _______________________________________________
>>>> 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