Re: [babel] MAC and key size

["STARK, BARBARA H" <[e-mail]>]

> There is indeed confusion in OSPF RFCs about the upper bound for the
> key in HMAC after which to start hashing. RFC 4634, 6234, Wikipedia,
> Bird (quoting Toke), and babeld use the block size. Babel-MAC links to
> RFC 6234. We are safe from that issue.
> 
> > HMAC is defined using two keys:
> > - K' = H(K)  if |K| > block size
> 
> HMAC and blake2s are slightly different, in particular blake2s
> *limits* the maximum size of the key and doesn't pre-hash it.
> 
> > Ben wants it to be K, while I would prefer it to be K', and any
> > hashing should be done before the key is inserted into the
> > management interface.
> 
> Note that reference implementations of hash algorithms take K as
> parameter. But there's not much to worry about: for hmac-sha256 it
> doesn't matter whether they are pre-hashed or not because of the HMAC
> construct, and for blake2s it doesn't matter because the key isn't
> hashed (and a pad is trivial).
> 
> I expect the user to be a bit confused to see the hashed key. If the
> management delivers the hashed key, it also means that the key
> derivation function is in the management interface. That would
> simplify a bit a Babel implementation.
> 
> > the key SHOULD be no larger than the underlying hash's block size,
> 
> For blake2s the key cannot be larger than half the hash's block size.
> 
> I'd be in favor of using the limits enforced by the hashing algorithm
> if they exist (the case of blake2s). If they don't, then use this
> SHOULD, although for hmac-sha256 we've already accepted that keys
> longer than 32 bytes (half the hash's block size) give no additional
> security. But does it really matter, as HMAC already handles
> arbitrary-sized keys?
> 
> > it SHOULD be at least the digest size
> 
> Seems like a good recommendation, but I think we're just guessing here.
> 
> 
> What matters most and where we had troubles was the digest size to
> use: it can be configured with blake2s, or generally the output can be
> truncated. Implementations using the same hashing algorithm must agree
> on a digest size beforehand, or verifying the signature of a packet
> simply will fail (and you don't want to check if digests are prefixes
> of each other). We are safe from that issue in Babel-MAC.
> 
> 
> Regarding the input format of a key, I've seen a mail exchange that
> flew a bit over my head, but remember that a key is just a big number,
> and we're looking for a practical symbolic representation of that
> number. An hexadecimal string seems to me the easiest human and
> machine wise. I don't see babeld accepting a raw binary sequence as a
> key (but I could be wrong).
> 
> Currently in babeld I enforce 32 bytes keys for both hmac-sha256 and
> blake2s, but that could be relaxed. Babeld only understands
> hexadecimal strings.

I think I'll stick with the binary datatype. That's what Juliusz had previously suggested (and we did discuss that). It's pretty trivial to go between hex and binary and to provide a UI for entering hex that then converts immediately to binary, if there were to be a UI. Or for the remote management code (on the router) to convert binary to hex before providing to a Babel implementation (if that were necessary). All bits are fully supported and represented in both datatypes. 

Here's what I'm thinking as a proposal for the description:

This value is of a length suitable for the associated babel-mac-key-algorithm. If the algorithm is based on the HMAC construction [RFC2104], the length SHOULD be between 0 and the block size of the underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes as described in [RFC4868]) for cases where the management system has the ability to generate a suitably random value (e.g., by randomly generating a value or by using a key derivation technique as recommended in [RFC8967] Security Considerations). While longer values could be provided, they do not increase security if the value is sufficiently random. If the algorithm is "BLAKE2s-128", the length MUST be between 0 and 32 bytes inclusive, as described in [RFC7693].

Barbara