[zeromq-dev] Message source identification/authentication

[Randall Nortman]

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).