[zeromq-dev] Authenticated pubsub (was Access control)

Pieter Hintjens ph at imatix.com
Wed Jul 28 00:35:37 CEST 2010

On Tue, Jul 27, 2010 at 11:10 PM, Burak Arslan
<burak.arslan at arskom.com.tr> wrote:

> there seem to be many problems with below scheme, most serious being its
> ambiguity. e.g. what are "authentication credentials"? are you sending
> username/password as cleartext?

That's kind of an implementation detail.  If we're able to address
individual connections, asynchronously, using XREP sockets and
identities, then we can hold state per connection and implement SASL
challenge/response with whatever security mechanisms we want.

> also, what concern are you trying to address? integrity?
> confidentiality? (i'm not sure what a game would need) are you doing any
> sort of logging somewhere? if so, do you log messages as cleartext? if
> not, will they be decipherable 10 years from now? where would you store
> the keys?

The main concern I'm addressing is not sending data on TCP unicast
connections to subscribers who have not authenticated themselves. And
how to do this with 0MQ as it exists today.  A secondary concern is
how to do other routing patterns than the four built-in ones.

Logging does not seem relevant to the discussion.  Either server or
client can do logging, in plain text, as needed.  This is no different
than any other conventional protocol.  If you log encrypted SSH or TLS
traffic, will it be decipherable in 10 years from now?  Where would
you store the keys?

> i see two ways to add security to pub/sub model:
> 1) let anybody subscribe to any stream, but distribute decryption keys
> to only authenticated people (using 0mq or not). many key distribution
> schemes that address various needs exist. this will work without any
> change to the zeromq protocol. (same has here:
> http://lists.zeromq.org/pipermail/zeromq-dev/2010-July/004670.html just
> don't invent your own key distribution scheme)

Yes, we've been discussing this model for some time.  It seems to be
the right way to do encrypted multicast.  However it is... suboptimal
for TCP unicast.

Propose such a security scheme to a HTTP implementor, see how far you
get.  I will reiterate the problems with it, tell me if I got these

1. Waste of bandwidth as clients can request data they cannot use.
2. You need one endpoint per stream (i.e. per possible combination of
outgoing data).
3. As you point out, the ciphertext is (too) trivially captured for
future decoding.

> 2) if you're not comfortable publishing the ciphertext, or have other
> concerns like resource usage, the 0mq protocol must be extended to
> support (preferably pluggable) authentication / authorization mechanism.
> authentication for "who gets the messages" and authorization for "this
> guy gets which messages". the task of   designing a protocol that'll
> satisfy everyone's needs is daunting at best :)

Yes, I already asked that question (extending 0MQ with pluggable
authentication support) today.  It does seem like the right eventual

However the question was how to do secure (to whatever level required)
data distribution with 0MQ today.


More information about the zeromq-dev mailing list