Re: [babel] info model: rehashing hashing

[Toke Høiland-Jørgensen <[e-mail]>]

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

> Hi Babel,
>
> The WG had 2 extensive discussions around configuring keys for MAC
> algorithms. First in January 2019 and then in August 2019. The
> language in the info-model draft reflects the consensus we reached
> after the August 2019 discussion:
>
>    babel-mac-key-value:  ...  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 the block size of the
>       underlying hash inclusive (where "HMAC-SHA256" block size is 64
>       bytes as described in [RFC4868]).  If the algorithm is "BLAKE2s-
>       128", the length MUST be between 0 and 32 bytes inclusive, as
>       described in [RFC7693].
>
> Ben Kaduk is pushing back on this. I've included our conversation, at
> the bottom. 4 "> > > >" or a single ">" precede my comments and
> nothing, 2 "> >", or 5 "> > > > >" precede Ben's. But to summarize the
> comment that concerns me most, he says the restriction on keys for
> HMAC-based algorithms to be less than the block size will not be short
> enough to avoid the problem we saw with the Bird implementation using
> OSPF code (which calculates the cryptographic key for long
> "Authentication Key" per OSPF RFC 5709 and not HMAC RFC 2104).
>
> Here is that specific part of the conversation:
> -------------------------------------

Couple of comments on this:

>> The Bird (language) implementation of Babel used existing code for
>> OSPF. That code was designed according to RFC 5709, which will hash
>> any "Authentication Key" (K) longer than the length of the hash (L)
>> to create a cryptographic key (Ko) that is exactly L octets long.
>> 
>> What RFC 5709 describes is different than what RFC 2104 (HMAC)
>> describes. RFC 2104 says to create a hash of the authentication key
>> (K) if it is longer than the block size of the hashing algorithm (B).
>> For SHA-256, B != L. Therefore, using RFC 5709 will get a different
>> value for the cryptographic key than RFC 2104, for authentication key
>> length between L and B. This difference was noted in RFC5709 errata.
>> RFC 7166 updated RFC 6506 wrt this. But RFC 7166 didn't update RFC
>> 5709. RFC 7474 updated RFC 5709 and kept the L boundary. We looked at
>> the Bird library code which does indeed do the calculation according
>> to RFC 5709.

This is not accurate wrt the Bird code. The relevant bit is here:

https://gitlab.nic.cz/labs/bird/-/blob/master/lib/mac.c#L105

It's hashing keys longer than the block length, not the output length,
which is not what RFC5709 says (unless I'm misreading something).

>> Fortunately, there is great consistency among the various RFCs around
>> zero-padding short authentication keys.
>> 
>> Furthermore, the Bird implementation allowed the key to be provided
>> via a GUI that treated the input sequence of characters as ASCII.
>> This was, again, from code that already existed for OSPF. But note
>> there is no requirement in any RFC for support of an authentication
>> key entered in ASCII format.

The latest version of my Bird patch series lifts this restriction, BTW;
it is now possible to enter raw hex bytes as well as ASCII text when
specifying the key.

> Thanks; this is really helpful information to know (and pretty unfortunate
> about the OSPF situation).
> But if issues with how an existing Babel implementation handles input keys
> longer than the output length of the hash are what motivate the key length
> restrictions, shouldn't the length restrictions reflect the hash output
> length rather than the hash block size?
> -------------------------------------
>
> Does the parameter description have the right length limits? Please
> help! Thx,

I believe it does (see above). The Bird implementation is stricter,
though: it enforces exactly 32 bytes as the key size for Blake2s, and
between 32 and 64 bytes for HMAC-SHA256.

-Toke