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

[Tobias Oetiker]

Hi Florian,

Yesterday Florian Forster wrote:

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

you ware right ... I think, when authentication is active, users
should only be allowed todo authentication related operations
without being authenticated ...

> 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

I would realy like to get 1.4 out ... how about makeing it even
more strict for now as outlined above, and then have a more
elaborate privileges system in place for 1.5 ... kevin has also
mentioned some ideas in this direction ...

> > +=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.

As mentioned in my answer to Sebastians mail, I agree that for
'hardening' the connection we are best served by SSL since we don't
have to re-invent the whele.

The current AUTH patch solves the problem of connecting two
instances of rrdtool running on two multi-user hosts with minimal
technical effort and sans extra  dependencies.

I see the path ahead regarding authentication as follows:

* add username support to the AUTH protocol

* make sure that un-authed users may not do anything when
  authentication is active

-> release 1.4

* add SSL support to guard against 3rd parties doing funney things
  on the network level.

* add configurable per-operation/per-file privileges

* add support for certificate based authentication

-> release 1.5

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900