[PATCH 0/4] Add MAC authentication support to the Babel protocol

[Toke Høiland-Jørgensen]

Ondrej Zajicek <santiago at crfreenet.org> writes:

> On Tue, Feb 25, 2020 at 05:35:50PM +0100, Toke Høiland-Jørgensen wrote:
>> > 1) The documentation says:
>> >
>> >   protocol will only accept HMAC-based algorithms or one of the Blake
>> >   algorithms, and the length of the supplied password string must match the
>> >   key size used by the selected algorithm.
>> >
>> > This is not true for regular HMAC scheme, which does hashing of key as a
>> > part of HMAC computation, so you can have longer password, and generally
>> > should have, as you want password entropy (not its length) matching the
>> > key size of the algorithm.
>> 
>> Well, I was just taking this advice from the 'security considerations'
>> of the Babel MAC draft literally (section 7, 5th paragraph):
>> 
>>   This protocol exposes large numbers of packets and their MACs to an
>>   attacker that is able to capture packets; it is therefore vulnerable
>>   to brute-force attacks.  Keys must be chosen in a manner that makes
>>   them difficult to guess.  Ideally, they should have a length of 32
>>   octets (both for HMAC-SHA256 and Blake2s), and be chosen randomly.
>>   If, for some reason, it is necessary to derive keys from a human-
>>   readable passphrase, it is recommended to use a key derivation
>>   function that hampers dictionary attacks, such as PBKDF2 [RFC2898],
>>   bcrypt [BCRYPT] or scrypt [RFC7914].  In that case, only the derived
>>   keys should be communicated to the routers; the original passphrase
>>   itself should be kept on the host used to perform the key generation
>>   (e.g., an administators secure laptop computer).
>> 
>> I guess we could interpret it as a *minimum* size of 32 bytes?
>
> Hmm, it seems that Babel MAC draft is commited to entropy-dense
> human-unreadable keys. And unfortunately, i did not notice any suggested
> canonical way of human-readable encoding for these keys (e.g. some
> hexadecimal blocks), so it is possible that we end with different
> implementations using different encodings/representations.

Yeah, I did realise that might end up being an issue, without really
figuring out what to do about it. For testing I have been using a key
like this:
password "testtesttesttesttesttesttesttest" { algorithm hmac sha256; };

which is input to babeld like this:

key id 1 type hmac-sha256 value 7465737474657374746573747465737474657374746573747465737474657374

>> > I am not familiar with used MAC scheme (as it seems Blake is just a hash
>> > function and one needs some scheme to convert it to MAC algorithm). Does
>> > it really require matching key size? That was the case in the keyed-hash
>> > scheme used in old OSPF authentication and it is one reason why HMAC is
>> > better than old keyed-hash scheme.
>> 
>> The Blake2 algorithm itself does not allow key sizes larger than the key
>> block size (32 bytes for Blake2s, 64 bytes for Blake2b). See details in
>> Section 2.9 of https://blake2.net/blake2.pdf.
>> 
>> I guess the Bird wrapper could do the hashing before initialising
>> the Blake2 state, similar to what hmac_init() already does? I guess we
>> need to deal with that anyway, otherwise blake2s_bird_init() can
>> silently fail :/
>> 
>> So how about this: I'll change the config enforcement to just enforce a
>> static minimum key length of 32 bytes (in line with the spec), and fix
>> the blake*_bird_init() functions to hash the key first if it is longer?
>
> The initial hashing in hmac_init() is a part of HMAC algorithm. If this
> MAC algorithm does not do hashing, then we should not do additional
> hashing, otherwise we would have interoperability issues.

Oh, right, good point.

> For blake2s_bird_init(), IMHO it should behave like other keyed-hash,
> i.e. pad with zeroes (for shorter) or ignore rest (for longer).
>
> Perhaps we should have some hook or flag in MAC auth description
> structure that is used to validate keys based on used algorithm (so it
> would warn for bad-length keys for Blake2, but only for short keys for
> HMAC based ones.

The Blake2 implementation already 0-pads short keys. But I'm not sure if
it's a good idea to allow that; even if it's zero-padded it's still a
low amount of entropy, no?

> It seems to me that in order to handle Blake2s MACs (and other MACs that
> require entropy-dense keys), the proper solution is to have a option to
> specify a key in some form of binary-to-text encoding (e.g. hexadecimal):
>
>   password 70:61:73:73:77:64
>
> instead of:
>
>   password "passwd"

Yes, I think this is a good idea (or, well, we could allow both). Should
we use the colon-separated format, or a straight hex string for easy
copy-paste to babeld? E.g.,

password 0x7465737474657374746573747465737474657374746573747465737474657374

could be synonymous with

password "testtesttesttesttesttesttesttest"? Or even drop the 0x prefix
and just interpret a non-quoted string directly as hex bytes?

-Toke