Re: [babel] info model: rehashing hashing

Toke Høiland-Jørgensen <> Tue, 02 March 2021 23:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FB4F3A1450 for <>; Tue, 2 Mar 2021 15:27:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z3PoMM7RUnz6 for <>; Tue, 2 Mar 2021 15:27:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A4813A142F for <>; Tue, 2 Mar 2021 15:27:51 -0800 (PST)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20161023; t=1614727666; bh=xTdLIZmTL/kZ8nUH4W51vC7BXwXoPFrBS/OSbzceKRI=; h=From:To:Subject:In-Reply-To:References:Date:From; b=AMEE7nMDzkZWCGKnDWLRcVUUNPRSy62KLrYQyY5PDoTDZeyzp/W2eFrtH9SEPF9jE qlnoHp1QnxDt3L4gHturviIvFADy94XJ+rv68necCGu+PiAJ6e3W5IExeukmVMKm/x lEQQa/eK37KCtPXWqBULDwmk6x8AnvIH5YusrGR5z69ncLUrI1FzjWOTTOu2s7IgPx rMBZa8AEYY5wecC3k9HNMjxTWspf1lFefzYgn7OKOmMcg54LFl5y9AW3RdLh4u+s0B IYDylt1LCpB60sd4DBSb7xiuMJG/5s/ANn8itn1GJogLY1yYALqL/LpG/7yp/naB9i UL4WTJCvlhZoA==
To: "STARK, BARBARA H" <>, "''" <>
In-Reply-To: <>
References: <>
Date: Wed, 03 Mar 2021 00:27:45 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [babel] info model: rehashing hashing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Mar 2021 23:28:00 -0000

"STARK, BARBARA H" <> 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:

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.