[zeromq-dev] Authentication with curve

[Drew Crawford]

I opened issue https://github.com/zeromq/libzmq/issues/802.

Maybe it would be possible to write an API like this:

/**Upon successful completion, returns the public key used for the message, if available, or else the null pointer. */
char *zmq_msg_who (zmq_msg_t *msg);



On Jan 1, 2014, at 3:24 PM, Pieter Hintjens <ph at imatix.com> wrote:

> Hmm... this isn't going to be that easy. The connection doesn't have
> an identity until after it's authenticated. This means the only
> plausible solution is to provide authentication metadata to the
> zmq_msg API.
> 
> On Wed, Jan 1, 2014 at 10:19 PM, Pieter Hintjens <ph at imatix.com> wrote:
>> There's no issue open for this. Feel free to create one (we use the
>> github issue tracker now). I'll start by changing ZAP to provide the
>> client id.
>> 
>> On Wed, Jan 1, 2014 at 9:04 PM, Drew Crawford <drew at sealedabstract.com> wrote:
>>> Ok. Is there an issue open for this?
>>> 
>>> I'd be happy to take a run at it if that will help get it in the next release, although I can see from this thread that I'm probably not qualified to get it right the first time.
>>> 
>>> Drew
>>> 
>>>> On Jan 1, 2014, at 8:18 AM, Pieter Hintjens <ph at imatix.com> wrote:
>>>> 
>>>> On Wed, Jan 1, 2014 at 1:12 PM, Drew Crawford <drew at sealedabstract.com> wrote:
>>>> 
>>>>>> 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.
>>>> 
>>>> Maybe it's curious, yes. I'm thinking the ZAP handler has all the
>>>> information we need to correlate client IDs (the first frame on the
>>>> ROUTER message) with metadata and can provide this to apps in some
>>>> way.
>>>> 
>>>> Either it's via libzmq, or it's via another inproc:// path to apps.
>>>> There are a few plausible patterns for that.
>>>> 
>>>> Passing the client ID back out in replies is probably silly, yes.
>>>> 
>>>> -Pieter
>>>> _______________________________________________
>>>> 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