On Tue, Jul 27, 2010 at 11:10 PM, Burak Arslan <[email protected]> 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 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. > 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 solution. However the question was how to do secure (to whatever level required) data distribution with 0MQ today. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
