[Babel-users] MAC auth. for Babel in babeld

[Toke Høiland-Jørgensen]

Antonin Décimo <antonin.decimo at gmail.com> writes:

> Hello Toke,
>
>> I've done basic interoperability testing with the latest version of my
>> MAC implementation for Babel in Bird. They can successfully exchange
>> messages with both hmac-sha256 and blake2s hash algorithms configured.
>
> Yay! Thank you very much! I’m glad it worked (on the first try) :-)

Well, I did test an earlier version of your code against an earlier
version of me, so not quite first try ;)

>> - You don't enforce a minimum key length.
>
> This was on purpose, but maybe it was a bad idea.
>
>> For blake2s this means the key will effectively be zero-padded up to
>> the block size of 32 bytes (not sure what hmac-sha256 does).
>
> hmac-sha256 is the same. Under the block size, the key is padded with
> zeroes, above, the key is pre-hashed.

Yeah, that's what the Bird implementation is doing too. I'm also
limiting the *max* length of keys to avoid the pre-hashing as I figured
that would be an interoperability issue. But if it's standard practice
maybe that is not necessary?

>> For Bird I'm enforcing that the key size must match the hash output
>> size (32 bytes for both blake2s and hmac-sha256). This is based on
>> the security considerations section in the draft; should babeld do
>> the same?
>
> Now babeld requires keys of 32 bytes for both algorithms.

Great!

>> - I think the configuration is a bit verbose. This was the minimal
>> config I needed to enable MAC in babeld:
>>
>> key name test algorithm hmac-sha256 value
>> 7465737474657374746573747465737474657374746573747465737474657374 use
>> both
>> keyset test
>> keyset-add-key test test
>> interface veth0 mac true add-keyset test
>>
>> The two middle lines feel like they are a bit redundant; could we go
>> without them for simple configs?
>
> You’re right; at least the line `keyset test` can go, keysets are now
> implicitly created. I don’t see how I can further simplify without
> losing the idea that interfaces may share keysets and keysets may
> share keys.

The obvious thing would be to assign keys to a "default" keyset if no
explicit keyset is configured, and assign that default keyset to all
interfaces that don't specify one?

I think that would be safer anyway, as right now it's quite easy to
think you've configured authentication, but it's not actually enabled
because there was not key assigned. So I think the interface config
should be bailing out if 'mac true' is set but no key is available...

> One thing that is still buggy in my implementation is to use the
> "default" pseudo-interface with keysets and keys, this may simplify
> the configuration for common usecases.

Yeah, for more complex configurations that will help, of course. I did
not test the config interface extensively, just did the minimum to get
things working ;)

-Toke