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

[Toke Høiland-Jørgensen]

Ondrej Zajicek <santiago at crfreenet.org> writes:

> On Sun, Feb 23, 2020 at 11:56:33PM +0100, Toke Høiland-Jørgensen wrote:
>> This series adds MAC authentication support to the Babel protocol as specified
>> in by the IETF Babel working group in draft-babel-hmac-10:
>> 
>> https://tools.ietf.org/html/draft-ietf-babel-hmac-10
>> 
>> An initial RFC patch series was posted here in July 2018[0]. Since then, the
>> protocol specification has progressed through the IETF, to the point where it is
>> now in the IESG publication queue as a proposed standard RFC. This version of
>> the patch series updates the implementation to correspond to the final version
>> of the draft, and also addresses the review comments from the initial RFC patch.
>> The major changes are:
>> 
>> Major updates to the specification (for a full list see the draft appendix):
>> 
>> - Added Blake2s as a recommended algorithm
>> - Updated terminology to use MAC everywhere instead of HMAC (since Blake is not
>>   an HMAC algorithm).
>> - Added expiration of neighbours and rate limiting of challenge replies
>> - Update TLV type numbers after IANA allocation
>
> Hi
>
> Thanks for the patch, i plan to review it soon.

Awesome, thanks! :)

> Just did a quick look and have a few questions:
>
>
> 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?

> 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?

> 2) The code calls kernel getrandom() (or equivalent) for every handshake.
>
> I wonder whether it is a good approach, or whether it would be better to
> use internal cryptographic pseudorandom number generator just seeded from
> getrandom() during start / first reguest. Not sure what is best practice.
> But i definitely would accept the existing code with the current approach,
> as it is something that could be easily changed later.

I wouldn't worry too much about that, at least not on Linux. getrandom()
is nonblocking (even at boot these days; see
https://lwn.net/Articles/802360/), so the amount of randomness needed to
generate nonces should be trivial. With the rate limiting it's at most
three challenges per second per peer, which comes to ~266 bps of
randomness. And since the sender address is part of the MAC (which is
checked before any challenges issued), there is no risk of arbitrary
spoofing from someone who doesn't know the key.

-Toke