Re: [babel] [Babel-users] MAC auth. for Babel in babeld

[Toke Høiland-Jørgensen <[e-mail]>]

Antonin Décimo <[e-mail]> writes:

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

Haha, yeah :)

>> >> - 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?
>
> It is standard. If the key length is smaller than the output (block)
> size, then the key is padded with zeroes. If the key length is bigger,
> then it is pre-hashed. See https://tools.ietf.org/html/rfc2104#section-2

Ah, good to know!

> Right know, babeld requires keys to be of the exact output size of the
> hash.

I ended up with something similar, except for HMAC keys it allows
OUTPUT_SIZE <= key size <= BLOCK_SIZE:

https://github.com/tohojo/bird/blob/babel-mac-02/proto/babel/config.Y#L112

>> 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 want to use the 'default' pseudo interface so that each keyset that
> is added to the default interface is automatically added to each
> interface.

Yes, that does make things simpler, but still requires explicit
assignment of a key, even if it's just to the default interface. Maybe
you could add a keyword to the key definition itself ('default'?) that
does this without a separate keyset line?

>> 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...
>
> It’s not clear when this check should be, because keys could be added
> from another channel, for instance a local socket but not the
> babeld.conf file.
> I can add warnings when signing and verifying packets if there are no
> key available.

Yeah, dynamic config does make things a bit more complicated, but I
still think it's possible to add a check that will prevent most errors.
I don't think warning on processing is enough, it has to be on config
time (or an operator can still restart the daemon, not get an error, and
forget to check the logs).

You could simply reject 'mac true' if no key is configured (i.e., reject
interface bring-up or reconfig, as appropriate depending on context).
This imposes constraints on the ordering of config stanzas, but I think
that is better than allowing an interface to accidentally run without
mac enforcement because there is no key.

If you want to relax the ordering in the config file, you could defer
the check until you've read the whole thing, which would mean the
ordering constraint only exists on dynamic reconfig; but not sure that's
even necessary, forcing people to put the key definition first is not
that onerous...

-Toke