[collectd] Authentication/Encryption for the network plugin.

[Sam Quigley]

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:

Start:
	Clients sign with key_0
	Server accepts only key_0

Preparation:
	Clients sign with key_0
	Admin prepares for key rotation by adding key_1 to server
	Server accepts key_0 and key_1

Rotation period:
	Admin begins updating clients to use key_1
	Some clients use key_1, and others still use key_0
	Server accepts key_0 and key_1

Finishing up:
	Admin finishes updating clients and removes key_0 from server
	All clients use key_1
	Server only accepts key_1

This is a reasonably common pattern for key rotation, and doesn't  
require anything special in the way of control channels.  (Well, I  
guess that admins need to be able to update the collectd  
configurations on clients, of course -- but that's already true...)   
The process above would be pretty straightforward to automate with  
Puppet, for example.

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

While you're adding headers, though, it may be useful to consider one  
that specifies which encryption/signing scheme is being used.  The  
current scheme would presumably be "1" -- but in the future, something  
might motivate changing to a new scheme.  Maybe you decide to switch  
between cipher modes, or someone breaks AES...  If the packet header  
doesn't specify what scheme is being used, a backward compatible  
server would have to try decrypting the payload with every scheme ever  
used.  Other protocols sometimes overload the Type or Key ID field to  
achieve this -- but I think that's kinda gross.

Anyway; just a thought.

-sq

On Apr 13, 2009, at 7:26 AM, Thorsten von Eicken wrote:

> Just to throw yet another interesting consideration into the mix: how
> about key rotation? In a unidirectional protocol I believe it requires
> some external "control channel" which is outside of collectd most
> likely. But it would be good if the receiver had the capability to
> recognize packets that use different keys. This way the receiver can  
> be
> prepped with new keys and the senders can switch to a new key in a
> loosely coupled manner.
> I'll ask some more crypto-oriented folks than me about what's out  
> there
> that we could copy...
> 	TvE
>
> Florian Forster wrote:
>> Hi,
>>
>> On Sun, Apr 12, 2009 at 08:41:17PM +0200, Florian Forster wrote:
>>> Encryption is done without initialization vector (IV) and AES is set
>>> up to work in cipher-block chaining mode (CBC). When talking with
>>> Sebastian yesterday we realized that this allows for known plaintext
>>> attacks if you have the network plugin set up to forward data using
>>> encryption. So I will probably add a 16 byte IV and possibly  
>>> rearrange
>>> the parts a bit.
>>
>> actually, I didn't think enough. Using an IV doesn't help against  
>> known
>> plaintext attacks. While the use of an IV doesn't prevent an  
>> attacker to
>> use known plaintext attacks, it should prevent chosen plaintext  
>> attacks
>> on the cypher itself, so it's probably a good thing nonetheless.
>>
>> Currently, the use of an IV is implemented using this layout:
>> +-+-+----+-+------+---------+
>> !T!L! IV !l! Hash ! Padding !
>> +-+-+----+-+------+---------+
>>           ^^^^^^^^^^^^^^^^^^
>>  IV == initialization vector (16 bytes)
>> The part marked with ‘^’ is encrypted. Maybe we could improve the
>> situation by using no IV and simply encrypt the ‘IV’ field in the
>> header.
>>
>> We should think about using a different mode of operation, though:
>> Output feedback mode (OFB) doesn't require input data to be a  
>> multiple
>> of 16 bytes long, so we could avoid all that padding business. It
>> results in some opaque buffer length calculations and feels quite  
>> error
>> prone.
>>
>> Regards,
>> -octo
>
> _______________________________________________
> collectd mailing list
> collectd at verplant.org
> http://mailman.verplant.org/listinfo/collectd