Ondrej Zajicek <[email protected]> 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
