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

[Burak Arslan]

On 07/28/10 01:35, Pieter Hintjens wrote:
> 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.
>
>   

oy, sasl. in my experience, cyrus-sasl is not trivial to deploy. and
i've no idea about how you'd do sasl on windows. maybe it's natively
supported there?


> 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?
>
>   

logging should be the responsibility of whatever is securing the
communication. so if you rely on zeromq for security, i think it should
be able to handle logging as well. but if zeromq gets to distribute
ciphertext, then there's no point in polluting zeromq with logging.

the line has to be drawn somewhere, and it only depends on the amount of
resources you're willing to spend on zeromq.

ssl is not designed to be used as a secure logging scheme. but i guess
you'd store the key sequence next to the data, encrypted by the
certificate of the sending party. key distribution is like conventional
ssl where you'd have to produce a certificate authenticated by a trusted
third party to retrieve the logs.

i don't think using ssl for secure logging is a good idea though.

>> 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
> wrong:
>
> 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.
>
>   

http has solved authentication problem with client certificates. my
proposition was for a pub/sub (multicast) model, which http isn't. i
don't see why you mention http here.

burak