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

[Sebastian Harl]

Hi,

On Wed, Apr 29, 2009 at 03:14:18AM +0000, kevin brintnall wrote:
> Added challenge-response authentication to rrdcached.
[...]
> Sending this along RFC while I finish up the client code..  -kbrint

Quite frankly, I'm quite surprised that you ask for comments, while, on
the other hand, you have not replied to any of Florian's comments and
technical concerns that he has raised in the original discussion on that
topic ...

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

Hrm ... from a quick look at your patch, it looks like the remainder of
the session does not use any further crypto mechanisms (like signing
data, see below). If I did not miss anything, this approach makes man-
in-middle attacks fairly easy:

An attacker might intercept the communication between a client and a
server, forward the nonce to the client and then forward the response to
the server. The attacker would then be allowed to send _any_ command to
the server. If it also takes care of forwarding requests from the
client, the client would not even be able to notice the attack.

This could be solved by, for example, any of the following: adding
support for encryption (that's what Florian already requested a couple
of times) and / or signing the communication. Both cases could (and
should) be further improved by adding support for client and server
certificates.

When signing the communication, other users on the network could still
read along the communication and, thus, get all information (e.g. data
that's about to be added to some RRD file). So, people should be aware
that this protects against unauthorized _write_ actions but basically
does not protect against _read_ "access". When Florian provided his set
of patches to allow fetching data from the daemon, Tobi requested that
this kind of access ought to be protected. So, I suppose, that
protecting write access only is not an option. That is to say, we need
encryption ...

On Wed, Apr 29, 2009 at 10:29:31PM +0200, Tobias Oetiker wrote:
> Today kevin brintnall wrote:
> > > Would it make sense to have a secret and a user name, so that the
> > > communication would look like this?
> >
> > A user name may reduce the number of SHA1 comparisons (since we'll be able
> > to terminate the search earlier).  Currently we don't have any other
> > access restrictions or logging that would benefit from a user name.  Do
> > you foresee a need for any user-based authorization mechanisms?
> >
> > Do you foresee a need for a large number of secrets?
> 
> not at the moment, but florian has mentioned an idea for different
> levels of rights.
> 
> but I guess if this comes to pass the protocol could be enhanced by
> a second authentication key word which caters for authentication
> including a user name ...
> 
> for my use case, the present implementation is all I need.

This would also require another user / password database (in addition to
the auth_file that's required by the current implementation) since it's
not possible to enhance the auth_file in a backward-compatible way. So,
why not do it right from the beginning and avoid bloating the implemen-
tation and confusing users by having multiple different security
concepts?

To (again) cite Florian: security is something that should be done right
or not at all ...

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090503/ad2b8178/attachment.bin