[collectd] Authentication/Encryption for the network plugin.

[Florian Forster]

Hi Sam,

On Mon, Apr 13, 2009 at 04:59:36PM -0700, Sam Quigley wrote:
> If the collectd server supported multiple encryption/signing keys
> concurrently, key rotation wouldn't be very hard to implement
> manually, without the need for a separate control channel.  The
> process would be:
...
> Preparation:
> 	Clients sign with key_0
> 	Admin prepares for key rotation by adding key_1 to server
> 	Server accepts key_0 and key_1

If adding another configuration option, something like
 <Listen "localhost">
   SecurityLevel "encrypt"
   Secret "shuZ5fo8"
   LegacySecret "Taobia6N"
 </Listen>
would be all you wanted, implementing this is easy and shouldn't be a
problem.

Adding a secondary key at runtime, i. e. while the daemon is accepting
packets and decrypting them, would be considerably more work. To do that
“right” would require to solve these problems:

 - Secure channel from the outside into the network plugin.
 - Persistency: When restarting the daemon, the last used key(s) should
   be accepted.

But if we go this far, it's probably not a bad idea to think about a
username / password theme, too. This is probably best implemented using
a password file which is re-read whenever its mtime changes. I could
picture this somewhat like this:

 server# collectpasswd --user foobar --grace 300
 New password: 
 Password for user foobar updated.
 Old password will be accepted until Tue Apr 14 07:54:27 2009.
 server#
 
 client# collectpasswd --user foobar
 New password: 
 Password for user foobar updated.
 client#

Where:

 - ‘collectpasswd’ is a script to update /etc/collectd/network.passwd
 - ‘--grace <seconds>’ specifies how long the old password is accepted
   as secondary password.

> To implement this, as Thorsten notes, all that's really required is
> that the server have the ability to recognize which key was used to
> sign a given packet -- ie, another field in the packet header that
> carries the encryption key's ID (username / key serial number / etc).

If we use the first way (simply adding ‘LegacySecret’) we could simply
try both keys in order. If we user usernames, they must be included in
the packet in plain, of course.

> While you're adding headers, though, it may be useful to consider one  
> that specifies which encryption/signing scheme is being used.

Actually, this is done using the ‘type’ header. The current ‘types’ are
named “TYPE_SIGN_SHA256” and “TYPE_ENCR_AES256”. It's straight forward
to add new types for different hashing / encryption algorithms, for
example “TYPE_SIGN_RMD160” or “TYPE_ENCR_TWOFISH”. Selecting which to
use (on the client) and which to accept (on the server) is the tricky
part.

> Other protocols sometimes overload the Type or Key ID field to
> achieve this -- but I think that's kinda gross.

What's wrong with using the type field for this? Each ‘part’ is parsed
according to that field, and since the encryption and signing functions
make very strong assumptions about the cypher's key and block sizes, you
can't have one generic ‘encrypt’ function anyway.

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://mailman.verplant.org/pipermail/collectd/attachments/20090414/ea626fb6/attachment.pgp