On Mon, Jan 13, 2014 at 07:04:15PM +0100, Pieter Hintjens wrote:
On Mon, Jan 13, 2014 at 3:01 PM, Goswin von Brederlow goswin-...@web.de
wrote:
1) How does the client detect a login failure (as opposed to an
unreachable, unresponsive, crashing server?
It's explained in the ZMTP RFC.
On Tue, Jan 14, 2014 at 9:30 AM, Goswin von Brederlow goswin-...@web.de wrote:
It's explained in the ZMTP RFC. It's an area we're changing, to avoid
specifically the problem you experienced. An authentication failure
will result in an explicit ERROR reply rather than a disconnect.
will as in
Hi,
I'm started playing around with the CURVE examples posted on [1] but
in python and everything looked promising. But when I implemented
something myself I run into some problems:
I first start a ZAP class as a seperate thread to handle
authentication and create the server socket and bind it.
On Mon, Jan 13, 2014 at 3:01 PM, Goswin von Brederlow goswin-...@web.de wrote:
1) How does the client detect a login failure (as opposed to an
unreachable, unresponsive, crashing server?
It's explained in the ZMTP RFC. It's an area we're changing, to avoid
specifically the problem you
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 d...@sealedabstract.com wrote:
I
I’m still mystified about this line
and then each message will report the
authenticated sender.
Can you explain?
On Jan 1, 2014, at 5:28 AM, Pieter Hintjens p...@imatix.com wrote:
The ZAP handler gets the identity of the client (along with all
metadata) and can validate it. So you can use
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 p...@imatix.com wrote:
The ZAP
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
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
On Wed, Jan 1, 2014 at 1:12 PM, Drew Crawford d...@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
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 p...@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 d...@sealedabstract.com wrote:
Ok. Is there an issue open for this?
I'd be happy to take a run at it
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 p...@imatix.com wrote:
There's no
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
Le 31/12/2013 03:32, Pieter Hintjens a écrit :
You don't authenticate a peer based on its identity. You authenticate
based on public key and optionally the server socket domain. ZAP
authentication happens before any recv() and you cannot depend on any
correlation between the two, except
You can set the ZMQ_IDENTITY sock opt on the client prior to connecting.
On Dec 31, 2013, at 6:18 AM, Nicolas Delaby tico...@free.fr wrote:
Le 31/12/2013 03:32, Pieter Hintjens a écrit :
You don't authenticate a peer based on its identity. You authenticate
based on public key and
Le 31/12/2013 13:01, Lindley French a écrit :
You can set the ZMQ_IDENTITY sock opt on the client prior to connecting.
I'm in a client/server architecture where I do not trust the client.
I want to make sure a client can not impersonate another client when
both clients use their own curve
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?”.
Drew
On Dec 31, 2013, at 6:27 AM, Nicolas Delaby tico...@free.fr
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,
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
On 12/31/2013 07:08 PM, Drew Crawford 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
Hi all,
I would like to know how I can reliably authenticate a peer based on its
curve public_key value and its identity (assuming the zap_handler is
coupled with a ROUTER socket) ?
As the zap handler receive only the public_key value but client socket
identity. Is it safe to consider that the
Hi all,
I would like to know how I can reliably authenticate a peer based on its
curve public_key value and its identity (assuming the zap_handler is
coupled with a ROUTER socket) ?
As the zap handler receive only the public_key value but client socket
identity. Is it safe to consider that
On Mon, Dec 30, 2013 at 6:18 PM, Nicolas Delaby tico...@free.fr wrote:
I would like to know how I can reliably authenticate a peer based on its
curve public_key value and its identity (assuming the zap_handler is
coupled with a ROUTER socket) ?
As the zap handler receive only the public_key
24 matches
Mail list logo
