[rrd-developers] [PATCH] rrdcached server-side authentication

[Florian Forster]

Hi Kevin, Tobi, Sebstian and list,

thanks Kevin for this initial implementation :) I didn't read the source
code yet, so please forgive me if I misunderstand some details.

On Wed, Apr 29, 2009 at 03:14:18AM +0000, kevin brintnall wrote:
> A user connecting on a low-privilege socket may upgrade to high
> privilege upon successful authentication.  See L<AUTHENTICATION>
> below.

I'm not very happy about this choice, because it doesn't allow one to
enforce authentication for *any* type of interaction with the daemon.
Allowing unauthenticated flushing might be used as a DoS or similar, so
I'd aim for a more flexible solution.

I think a good compromise between unnecessary bloated feature and
flexibility would be to allow the administrator to specify which
commands are allowed on each socket and which commands require
authentication. I could picture the user interface (in form of command
line arguments) somewhat like this:
 rrdcached … --commands @flush,update,fetch
Where commands are comma-separated and all commands prepended with ‘@’
can be used without authentication.

This would allow to configure the daemon for fairly complex scenarios,
for example:
 - allow `update' only authenticated from the local network
   and unauthenticated via the UNIX domain socket
 - allow `fetch' unauthenticated from the local network only
 - allow `flush' only authenticated from anywhere

> +=item B<Successful authentication>
> +
> +    client: AUTHSTART
> +    server: 1 challenge follows
> +    server: <nonce>
> +    client: AUTH <response>
> +    server: 0 ok

I think this is a design bug which should be resolved before the
protocol is (widely) adopted: The *session* is authenticated but the
integrity of the data is not checked at all. An attacker could, for
example, hijack the TCP connection after authentication has taken place
and do whatever he likes. Let's say submit a value far in the future to
obscure an attack that would otherwise show up on graphs.

I propose the following protocol instead:
 client: AUTHSTART <username>
 server: 1 challenge follows
 server: <iv>
 client: AUTHCMD <sig_0> <cmd_0>
 server: <response>
 client: AUTHCMD <sig_1> <cmd_1>
 server: <response>
 ...
 client: AUTHCMD <sig_n> <cmd_n>
 server: <response>

Where:
 <sig_n> == HMAC-SHA1 (<nonce_n>, <cmd_n>)
 <nonce_0> == <iv>
 <nonce_n> == SHA1 (<nonce_{n-1}>)

This way each line/command is authenticated and a attacker cannot modify
commands or submit own commands without the server and/or client
noticing (and denying) it.

To do this right, the server's response should be signed as well.
Otherwise the attacker cannot send/query arbitrary data to/from the
server, but can modify data/replies sent by the server. I'm sure this is
important to people doing monitoring with this data.

Once we're at that point, adding encryption is a free lunch:
 client: ENCRSTART <username> <iv>
 server: 0 go ahead
 client ENCRCMD <cyphertext>
 server <encrypted response>

(Assuming Kevin used a library for the HMAC-SHA1 stuff. Otherwise we'd
need to implement/copy a implementation of AES (or whatnot) and some
mode of operation. I have recently used the gcrypt library and can
recommend it; it has a nice, clean and easy to use interface.)

I think that, all things considered, using TLS for authentication is
probably the easier and more professional choice. In big installations a
CA is usually already installed and the whole mechanism is well
understood. After all, we'd be in one boat with MTAs (Exim, Postfix, …),
MDAs (Cyrus, Dovecot), Web-Servers (Apache, lighttpd), Jabber-Servers,
OpenVPN, and many more. The only daemon I have installed which uses
another encryption mechanism (and TCP) is SSH.

On a more technical side the benefits would be that certificates are
used instead of a shared secret, so we'd only need to read a file.
Putting that file in place is done by the configuration management
software (which, again, is already in place in most big installation). A
sort of soft-migration as for passwords is therefore not required but
realized using the CA and certificates.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090503/d5feef8a/attachment-0001.bin