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
signature.asc
Description: Digital signature
_______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers