What I am planning on using them for would not allow the secure exchange of keys and username/password. I want to have socket A doing curve+plain and this will allow the central zap server to learn a curve public key and authorize it using the plain auth data. Once completed all future connection will happen to socket B-Z will be based on curve only. This allows the plain the authorize the public key for future secure communication. With this system nothing is ever plaintext over the network and does not require external exchange of keys.
Looking at the code (nothing more at this point). Simple system without having to later auth would be create ZMQ_CURVE_PLAIN and when curve is finished this hands off the plain. The flow looks simple. The only hang up is zap and I think that can be handled better in the stream_engine. I completely understand about getting a release out, but this is something I would love to see in 4. Let me know planning on putting it together over the weekend and will keep it branched in my repo. On Aug 23, 2013, at 5:22 PM, "Pieter Hintjens" <[email protected]> wrote: > Hmm, the use of multiple security mechanisms was one thing we > considered and rejected when designing ZMTP 3.0. The problem is that > you would have to expand the message API to allow the reader to ask > the security level for each message. If you really want a PLAIN and a > CURVE mix, you can use two sockets. Allowing more than one mechanism > per socket makes _everything_ more complex and it's not clear that the > benefits are worth it. > > I'd really like to get 4.0 released with a minimal plausible security > model, and expand on it later. > > Also, if we did have multiple levels per socket, that would not change > ZAP. The server would just make multiple ZAP requests, one per > mechanism... > > -Pieter > > On Fri, Aug 23, 2013 at 7:44 PM, Jeremy Rossi <[email protected]> wrote: >> I have been spending sometime with zeromq and zap. With this I am thinking >> about refactoring the libzmq zap / security code a little to add some >> features and solve a problem I have. >> >> I think we should be able to stack mechanisms. So that you are are able to >> use ZMQ_CURVE and ZMQ_PLAIN on the same socket. This would allow secure >> transport of the username/password with out having to manage the keys. Also >> in my use case would allow the zap provider to learn the public key of a >> client while still providing authentication for that learning process. >> >> To achieve this I think the ZAP frame generation and processing should be >> moved to stream_engine.cpp and make calls into the mechanisms to gather the >> needed information to send to zap endpoint. >> >> Figured I would start the chat before working on code and get some feedback. >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
