Authors, Feedback on version -12:
: Auth-Key : : This field carries the 32-bit (4 octet) ISAAC output which is associated : with the Sequence Number. The ISAAC PRNG MUST be configured and initialized : as given in section TBD, below. Fill in the TBD. : While the rest of the contents of the BFD packet are unauthenticated and may be : modified by an attacker, the same is true of stronger Auth Types, such as : MD5 or SHA1. The Auth Type methods are not designed to prevent such attacks. : Instead, they are designed to prevent an attacker from spoofing identities, : and an attacker from artificially keeping a session "Up". The above is not true. For MD5/SHA1, the digest is calculated over the entirety of the PDU. Changes to PDU contents are thus noted. Most importantly, the text in section 5 covers what we need to say about when state changes are done, and only using this for Up. Thus, simply delete the above cited paragraph. 5.1 Seeding and Operation of ISAAC: The substantive portion of my feedback is covered here. However, I think we're very close in all other respects. The text starts with: : Note that switch to a different AuthType method does not affect the values : of the bfd.RcvAuthSeq or bfd.XmitAuthSeq variables. The variables MUST : continue on from their previous values which were using the previous : AuthType method. We move to: : That is, when changing AuthTypes in a session, the current value of the : bfd.RcvAuthSeq and bfd.XmitAuthSeq variables is used as the initial value(s) : for the new AuthType. And finally to: : The origin of the Seed field is discussed later in this document. For now, : we note that each time a new Seed is used, the bfd.XmitAuthSeq value MUST be : set to zero. The Seed MUST be changed when a BFD session transitions into : the "Up" state. In order to prevent continuous rekeying, the Seed MUST NOT : be changed while a session is in the "Up" state. So, twice "don't change it" and once to "set it to zero when we use a seed". RFC 5880 defines : bfd.XmitAuthSeq : : A 32-bit unsigned integer containing the next sequence number for : Keyed MD5 or SHA1 Authentication to be transmitted. This variable : MUST be initialized to a random 32-bit value. Thus, the intention is that we start with a random value. If the session is Up with one of the existing types with a known sequence number, and then we switch to Meticulous Keyed ISAAC, what is likely happening is: 1. We learn the Seed for this session for the first time. This somewhat argues we need a bfd.MetKeyIsaacKnown variable. We require it to not change. Note that it's critical that we say that we're setting it only after ISAAC authentication has succeeded. 2. We need to generate the ISAAC table from the existing sequence number. It can't simply be sequence 0 because that's attackable. 3. Since we can't set it to zero, and we don't want to generate all intervening ISAAC pages to "catch up" to our random sequence number we started with, we need to treat this somewhat analogously to TCP's initial sequence number. How could we do that? 3a. Each ISAAC page is 256 numbers. Thus, floor(seq# / 256) will give us the zeroth sequence number for a page. Store this in a new variable, bfd.MetKeyIsaacPageBase. 3b. The page-based value in the ISAAC table can thus be selected as the index: seq# - bfd.MetKeyIsaacPageBase. (With appropriate wrap protection.) 5.2: : RECOMMENDED to use differnet secret Keys for each Auth Type. s/differnet/different. 5.3: : the respective values used by a sending system. For recieving s/reieving/receiving/ The procedures here use the input tuple: <Seed, Your Discriminator, Secret Key> I suspect that Secret Key is intended to be able to be selected from a table of Meticulous Keyed ISAAC based on Auth Key ID? If so, it's worth adding a sentence to that effect. Section 6 covers the necessary procedure in detail. 6. Meticulous Keyed ISAAC Authentication : Receipt using Meticulous Keyed ISAAC Authentication : : If the received BFD Control packet does not contain an Authentication : Section, or the Auth Type is not correct (TBD2 for Meticulous Keyed ISAAC), : then the received packet MUST be discarded. This is also TBD1, I believe. 7. IANA Considerations : Note to RFC Editor: this section may be removed on : publication as an RFC. It's traditional to leave in the IANA considerations section in the document. The RFC Editor will work with IANA to update the section and the voicing of the request from a request to what they did. 8.2 : If we recommend different keys, then it is possible for the two keys to be : configured differently on each side of a BFD lin. For example. lin? -- Jeff On Wed, Nov 29, 2023 at 05:23:07PM -0800, internet-dra...@ietf.org wrote: > Internet-Draft draft-ietf-bfd-secure-sequence-numbers-12.txt is now available. > It is a work item of the Bidirectional Forwarding Detection (BFD) WG of the > IETF. > > Title: Secure BFD Sequence Numbers > Authors: Alan DeKok > Mahesh Jethanandani > Sonal Agarwal > Ashesh Mishra > Ankur Saxena > Name: draft-ietf-bfd-secure-sequence-numbers-12.txt > Pages: 15 > Dates: 2023-11-29 > > Abstract: > > This document describes a new BFD Authentication mechanism, > Meticulous Keyed ISAAC. This mechanism can be used to authenticate > BFD packets with less CPU time cost than using MD5 or SHA1, with the > tradeoff of decreased security. This mechanism cannot be used to > signal state changes, but it can be used as an authenticated signal > to maintain a session in the the "Up" state. This document updates > RFC 5880. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-12 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-secure-sequence-numbers-12 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts >
