[zeromq-dev] Authentication with curve

[Drew Crawford]

There is some vocabulary in here that is new to me, so please forgive me for asking a few stupid questions.  

> we extend ZAP to add the client socket id to request

I think what you’re saying here is “the bytes that come in the first frame of a message on a router socket (before the delimiter frame)… those should appear in the ZAP request at the time the socket is authenticated.”  I agree with you there.

>  and reply

I’m a little mystified as to why the ZAP handler needs to copy those bytes onto the reply.  I mean, it’s not difficult, it just seems curious as a person not well-versed in the design.  Do you expect the ZAP handler to be interested in changing the identity in some fashion?  Is that legal?

> 2. we publish all ZAP replies to a secondary inproc:// socket (PUB-SUB)

This also seems curious.  I’m wondering if you’re envisioning a more complicated ZAP handler in some faraway module as “typical” than the one I plan on writing.  Basically my entire interest in ZAP is in using it to solve this “who is sending me / are they allowed to send me this message” problem.  If ZAP isn’t the right way to do that, it’s probably worth me learning what ZAP is actually for, as that means my mental model isn’t right.

Drew


On Jan 1, 2014, at 5:53 AM, Pieter Hintjens <ph at imatix.com> wrote:

> 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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev