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

[Ondrej Zajicek]

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.


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

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.

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"

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."