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

Toke Høiland-Jørgensen toke at toke.dk
Mon Sep 28 16:39:05 BST 2020


Juliusz Chroboczek <jch at irif.fr> writes:

>>> 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!
>
> It's also not a very good idea.
>
> MAC exposes large numbers of packets and their signatures to an attacker.
> It is therefore vulnerable to dictionary attacks.  HMAC keys should either
> be drawn randomly using a cryptographic RNG, or generated using a hashing
> procedure that is resistant to dictionary attacks.  This is expanded upon
> in the Security Considerations section of the draft.

Yeah, that discussion is why I added the restriction in Bird.

> I am of a divided mind on whether babeld should implement the RFC 2104
> procedure, as proposed by Antonin.  On the one hand, the procedure in
> RFC 2104 Section 2 is extremely naive from a modern point of view, and
> implementing it might induce people into deploying MAC in an insecure
> manner.  On the other hand, it is convenient, and inconvenient security
> protocols are less likely to be deployed in production (*cough*PGP*cough).

In any case, Blake2 does not have any such mechanism, so keys would have
to be a certain size there (or we'd end up inventing something new,
which is probably not a good idea). So I think restricting the key size
is fine; and, well, if users want to make that key be all zeroes (or
something equally insecure) we can't really stop that anyway...

> On the gripping hand, MAC only secures Babel traffic -- it does nothing to
> protect neighbour discovery, let alone data traffic.  One might therefore
> argue that Babel-MAC and Babel-DTLS are both pointless, and that Babel
> should be deployed over secure links.  There is some merit to this position,
> and we should consider doing some work on integrating babeld with Wireguard.
> Please see the discussion on
>
>   https://github.com/jech/babeld/issues/58

Ah cool, I've been wanting to add wg support to Bird as well; maybe we
should write a spec for how that is supposed to work with the Babel
protocol (I don't agree with the reporter of that bug that this will
need changes to wireguard, if we allow plaintext discovery outside of
the tunnel, babel can just to unicast peers on the inside).

-Toke



More information about the Babel-users mailing list