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: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
