Re: Regarding keyed MD5/SHA1 authentication for BFD (RFC 5880)

Gļebs Ivanovskis <glebs@mikrotik.com> Thu, 28 April 2022 09:37 UTC

Return-Path: <glebs@mikrotik.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88ACFC159A23; Thu, 28 Apr 2022 02:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.755
X-Spam-Level:
X-Spam-Status: No, score=-3.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.857, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dtv-0Mfnu5v6; Thu, 28 Apr 2022 02:37:11 -0700 (PDT)
Received: from plekste.mt.lv (bute.mt.lv [IPv6:2a02:610:7501:2000::195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453EBC159A22; Thu, 28 Apr 2022 02:37:10 -0700 (PDT)
Received: from [2a02:610:7501:ffff:234f:e6bb:2ea9:b0ae] by plekste.mt.lv with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <glebs@mikrotik.com>) id 1nk0aB-0005xW-Gg; Thu, 28 Apr 2022 12:37:07 +0300
Content-Type: multipart/alternative; boundary="------------l2nvG6LwREXxohQogZv03gf1"
Message-ID: <4e9bb1fe-028f-e981-9df3-27a2a714b055@mikrotik.com>
Date: Thu, 28 Apr 2022 12:37:07 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Regarding keyed MD5/SHA1 authentication for BFD (RFC 5880)
Content-Language: en-US
To: Alan DeKok <aland@deployingradius.com>
Cc: rtg-bfd@ietf.org, draft-ietf-bfd-secure-sequence-numbers@ietf.org
References: <b4a3419f-b465-90fd-0f92-7385fa5595c4@mikrotik.com> <03DC02BB-FBC4-4820-83D3-AAC309E16117@deployingradius.com>
From: Gļebs Ivanovskis <glebs@mikrotik.com>
In-Reply-To: <03DC02BB-FBC4-4820-83D3-AAC309E16117@deployingradius.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/uh2KF3I3ltNSn6729_6jo39cYgc>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2022 09:37:13 -0000

Hi, Alan!
>> Furthermore, I would like to suggest going back to original ordering with digest/hash verification being done before examining Sequence Number, because it simplifies the algorithm. I don't think that checking Sequence Number first provides much protection against CPU exhaustion attacks, because Sequence Numbers are transmitted in clear text and it wouldn't be that difficult for an attacker to come up with a valid Sequence Number to pass "cheap" check.
>    Yes.
>
>    The "secure sequence numbers" draft attempts to address these issues.

Thank you for the pointer. It seems that the "secure sequence numbers" 
draft makes the same mistake as RFC 5880 of putting bfd.AuthSeqKnown and 
bfd.RcvAuthSeq manipulations before FNV-1a digest calculation in Section 
7. 
<https://www.ietf.org/archive/id/draft-ietf-bfd-secure-sequence-numbers-09.html#name-meticulous-keyed-fnv1a-auth> 
"Meticulous Keyed FNV1A Authentication" (part "Receipt Using Meticulous 
Keyed FNV1A Authentication"):

    Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
    1, and bfd.RcvAuthSeq MUST be set to the value of the received
    Sequence Number field.

    Replace the contents of the Digest field with zeros, and calculate
    the FNV-1a digest as described below. If the calculated FNV-1a
    digest is equal to the received value of the Digest field, the
    received packet MUST be accepted. Otherwise (the digest does not
    match the Digest field), the received packet MUST be discarded.

Best regards,
Glebs