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

[Ondrej Zajicek]

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

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.


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.


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