[collectd] Authentication/Encryption for the network plugin.

[Bruno Prémont]

On Sun, 12 April 2009 Florian Forster <octo at verplant.org> wrote:
> First off: The network packet consists of “parts”, which all have the
> following form:
>  +-+-+----------+
>  !T!L! Data ... !
>  +-+-+----------+
>  T == type of data (2 bytes)
>  L == length of the part (including the two header fields, 2 bytes)
> 
> Parts of an unknown type are skipped. This is possible, because the
> length of the part is known and ensures forward-compatibility.
> 
> > I'm assuming the signature is something like:
> >    SHA1(shared_secret + ":" + unsigned_data)
> > and the resulting packet becomes
> >    unsigned_data + signature
> 
> It is now HMAC-SHA-256, so the call would be something like this in
> pseudocode:
>  hash = hmac_sha256 (shared_secret, data)
> I've learned, that simply doing “hash = sha256 (secret + data)” is
> prone to attacks. Since libgcrypt offers the HMAC functions, I'm
> using those. The “part” looks like this:
>  +-+-+------+
>  !T!L! Hash !
>  +-+-+------+
>  Hash == HMAC-SHA-256 hash (32 bytes => L = 36)
> Currently the signature is assumed to sign ALL following data, i. e.
> everything following the “part”. This way, older servers receiving
> such a signature can simply skip it.
> 
> An alternative would be to put the signed data as payload into the
> part, i. e. something like this:
>  +-+-+------+---------+
>  !T!L! Hash ! Payload !
>  +-+-+------+---------+
>  L == 36 + length(Payload)
> The advantage would be that you could mix signed and unsigned data in
> the packet or sign some data with one key and some other data with
> some other key.
> 
> I think compatibility to older clients is worth the slightly inelegant
> design of the first (and implemented) approach and that the mentioned
> (now impossible) features are not important enough to break compati-
> bility. It would, however, be very easy to add another part-type which
> behaves according to the second description, making both possibilities
> available.

To retain the possibility of multiple signatures in a single packet one
could do something like this:

- part
- part T=sig_start, D=id+hash
- part (covered by signature)
- ...
- part T=sig_end, D=id

This would also allow signing at multiple hops:
- part
- part T=sig_start, D=id+hash
- part (covered by signature)
- ...
- part T=sig_start, D=id1+hash
- part (covered by signature 0 and 1)
- ...
- part T=sig_end, D=id1
- part (covered by signature 0)
- ...
- part T=sig_end, D=id

The end-of-packet would also be implicit sig_end for all non-closed
signature parts.


Bruno