Re: [babel] MAC and key size

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

I've been pondering and have a new suggestion.

Here's what I'm thinking as a proposal for the parameter 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 MUST be between 0 and an upper limit that is at least the size of the output length (where "HMAC-SHA256" output length is 32 octets as described in [RFC4868]). Longer lengths MAY be supported but are not necessary if 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). If the algorithm is "BLAKE2s-128", the length MUST be between 0 and 32 bytes inclusive as specified by [RFC7693].

In the Security Considerations I propose adding, after the sentence "See the Security Considerations section of [RFC8967] for additional considerations related to MAC keys.": 

The fifth paragraph of that security Considerations section makes some specific key value recommendations that should be noted. It says that if it is necessary to derive keys from a human-readable passphrase, "only the derived keys should be communicated to the routers" and "the original passphrase itself should be kept on the host used to perform the key generation" (which would be the management system in the case of a remote management protocol). It also recommends that keys "should have a length of 32 octets (both for HMAC-SHA256 and BLAKE2s), and be chosen randomly".

I need to get an email sent to Ben today. If I hear nothing, I'll propose this to him later today.
Barbara

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