Subject: [babel] MAC and key size

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 09 Mar 2021 16:46:44 +0100

Dear Barbara,

HMAC is defined using two keys:

  - K, which is the original key provided by the user;
  - K', which is exactly the block size of the underlying hash.

K' is defined as

  - K' = K·0⋯0 if |K| < block size
  - K' = K     if |K| = block size
  - K' = H(K)  if |K| > block size

Now it looks like Ben and us disagree about which key should be stored in
the information model: 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.

A possible compromise would be to allow the hashing to happen in the
management interface (i.e. to allow the information model to store
K rather than K'), but add a note to the RFC saying that for security
reasons the key SHOULD be no larger than the underlying hash's block size,
it SHOULD be at least the digest size, and put a reference to Section 7 of
RFC 8967.

— Juliusz

---

From: Antonin Décimo <[email-masked]>
Date: Tue, 9 Mar 2021 18:43:47 +0100

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.

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

-- Antonin

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 9 Mar 2021 21:14:32 +0000

> blake2s, but that could be relaxed. Babeld only understands

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 10 Mar 2021 20:58:45 +0000

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

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