[zeromq-dev] Message source identification/authentication

Pieter Hintjens ph at imatix.com
Sun May 12 19:12:11 CEST 2013


Hi Randall,

I think there's no real problem here, I'll explain why.

The one thing I wanted to disable by design in the protocol was mixing
different levels of security on one socket; so all clients at least
use the same security mechanism. Now, a mechanism like CurveZMQ will
allow the server to authenticate each client (we'd do this with
out-of-band messages), and attach an internal identifier to each
authenticated client, and then attach that to each incoming message.

Since 3.x we fixed the API to allow message properties (e.g.
zmq_msg_more) in a clean and extensible way. So when we get to this,
we can add zmq_msg_sender() that returns the authenticated client ID
for the current message.

Does this help?

-Pieter





On Sun, May 12, 2013 at 9:30 AM, Randall Nortman <rnzmq at wonderclown.net> wrote:
> On Sat, May 11, 2013 at 11:02:08PM -0500, Eric Hill wrote:
>>    [Trying again without using the J word to beat the profanity filter.
>>    �Really!?]
>>    > But what prevents one peer from
>>    > impersonating another? �Absolutely nothing, because by the time the
>>    > message gets to the application layer the authentication information
>>    > has been lost.
>>    The thing that prevents one peer from impersonating another is each peer
>>    should have a unique secret shared only with the server. �Any other client
>>    that attempts to send a message with a bogus client id will fail because
>>    it cannot authenticate the message (HMAC, etc) because it doesn't have the
>>    key.
> [...]
>
> This is what I referred to as putting the security on top of zeromq.
> Of course it can be done.  But if every application is doing this over
> again from scratch, most of those applications will do it wrong, and
> furthermore different applications will not be interoperable.  And if
> you ever want to change the algorithms you use (because your hashing
> algorithm is found to be insecure, or you want to use longer keys, or
> there was a bug in your design), you have a lot of code to change all
> over the place, and probably you need to update all of your systems
> all at the same time.
>
> Many people will already have security underneath zeromq, where peers
> are authenticated at or just above the transport layer in some way.
> But zeromq's API does not expose transport-layer identification
> information to the application, so then the app has to put it on top
> of zeromq, as you describe, which has the problems I mentioned
> (besides being redundant overhead).
>
> Even if only for implementing proper logging/auditing and debugging,
> knowing the source of a message is essential.
>
> If the API had something like the standard POSIX socket function
> recvfrom (which exposes transport-layer address information), then
> this problem could be avoided.  Another analogy would be the CGI
> environment variables (REMOTE_ADDR, REMOTE_HOST, REMOTE_USER,
> REMOTE_IDENT] set by web servers to pass information to CGI scripts.
> [Who uses CGI anymore?  But the data is still there somewhere even in
> most modern web frameworks, and occasionally even contain correct
> information.]  I would suggest that the zeromq version of recvfrom
> supply an address (using whatever address format is used by the
> underlying transport) and, if there is any authentication happening at
> the transport layer, should also provide the authenticated credentials
> in both a simplified, universal format that just provides a string
> identifier (could be the CN field from an X.509 certificate, for
> example, or a username/UID), and also optionally a pointer to (or copy of)
> a transport-dependent detailed structure (e.g., the entire X.509
> certificate).
> _______________________________________________
> 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