Re: Deb Cooley's Discuss on draft-ietf-bfd-secure-sequence-numbers-25: (with DISCUSS and COMMENT)

Fri, 17 Oct 2025 22:17:36 -0700 

https://github.com/mjethanandani/bfd-secure-sequence-numbers/pull/61

Deb,
The above pull request attempts to address your point about random numbers in the reply below. 

On 10/12/25 14:48, Deb Cooley wrote:


    > Section 10:  In addition to ISAAC, a system is required to have
    a second CSPRNG
    > to generate session seeds?

    "Insert random number here, your choice of how it's random."
[DC] so here's the rub... if you use the same CSPRNG for both values not transmitted (seeds, secret keys) and for fields that are transmitted  (sequence numbers, discriminators) you give away RNG state, in the transmitted fields.  For example a failed noisy diode (commonly used as a RNG) will have long strings, which the attacker can see in sequence numbers and thus use to more easily guess the values not transmitted.  This is why I make the comment about a second CSPRNG.  At the very minimum this has to be acknowledged in the Sec Consid section or one has to require the use of two CSPRNGs (which I can't quite imagine).
Attached find a new security considerations sub-section that attempts to address randomness.  Tersely: 

- BFD and ISAAC in BFD uses random numbers in these three places

- These things aren't generated fast, use something "strong".
- If you can't use something strong (for perverse reasons), don't re-use existing ISAAC parameters for a BFD session.
I suspect for that last point you'd rather not even suggest it's possible, but you're really asking for "well, if you did, here's why that sucks".
I suspect the suggested text could use polishing from experienced security reviewers. 




    >
    > Section 15:  Please add a section about CSPRNGs. Describe the
    requirements for
    > strength and assurance.  There are multiple mentions of CSPRNG
    for all the
    > various fields used in BFD (Session Seeds, Secret Keys, Sequence
    Numbers).
    > What are the consequences of using a sub par PRNG? What are the
    mitigations?

    No text has been added - perhaps Alan has something in mind.

    That said, this seems like a generic issue for IETF standard
    documents.  Is there not a general bit of recommendation about
    such things already?  If not, you're surely not asking BFD authors
    to create that?
[DC]  It is a generic issue, and normally, I would have pointed to RFC 4086.  But that RFC is pretty long in the tooth (old - 2005 vintage).  In this case, in the absence of an O/S and easily accessible things like 'cryptgenrand' or /dev/random (or /dev/urandom), it might still be appropriate.
I'd like to explicitly point out the irony of complaining about a 20 year old mechanism when much earlier complaint about ISAAC was about a 30 year old mechanism. :-)
Similar to prior comments, this is a place the security directorate should consider the creation of appropriate boilerplate. 

-- Jeff
Title: Diff: draft-ietf-bfd-secure-sequence-numbers-26.txt - draft-ietf-bfd-secure-sequence-numbers-27.txt
  draft-ietf-bfd-secure-sequence-numbers-26.txt   draft-ietf-bfd-secure-sequence-numbers-27.txt
   
   
   
   
  Network Working Group A. Dekok   Network Working Group A. Dekok
  Internet-Draft InkBridge Networks   Internet-Draft InkBridge Networks
  Intended status: Experimental M. Jethanandani   Intended status: Experimental M. Jethanandani
  Expires: 11 April 2026 Kloud Services   Expires: 17 April 2026 Kloud Services
  S. Agarwal   S. Agarwal
  Cisco Systems, Inc   Cisco Systems, Inc
  A. Mishra   A. Mishra
  Aalyria Technologies   Aalyria Technologies
  J. Haas   J. Haas
  HPE   HPE
  8 October 2025   14 October 2025
   
   
  Meticulous Keyed ISAAC for BFD Optimized Authentication   Meticulous Keyed ISAAC for BFD Optimized Authentication
  draft-ietf-bfd-secure-sequence-numbers-26   draft-ietf-bfd-secure-sequence-numbers-27
   
  Abstract   Abstract
   
  This document describes a BFD Optimized Authentication Mode,   This document describes a BFD Optimized Authentication Mode,
  Meticulous Keyed ISAAC Authentication. This mode can be used to   Meticulous Keyed ISAAC Authentication. This mode can be used to
  authenticate some BFD packets with less CPU time cost than using MD5   authenticate some BFD packets with less CPU time cost than using MD5
  or SHA1, with the tradeoff of decreased security. This mechanism   or SHA1, with the tradeoff of decreased security. This mechanism
  cannot be used to signal state changes, but it can be used to   cannot be used to signal state changes, but it can be used to
       
Skipping Skipping
  working documents as Internet-Drafts. The list of current Internet-   working documents as Internet-Drafts. The list of current Internet-
  Drafts is at https://datatracker.ietf.org/drafts/current/.   Drafts is at https://datatracker.ietf.org/drafts/current/.
   
  Internet-Drafts are draft documents valid for a maximum of six months   Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any   and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet-Drafts as reference   time. It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."   material or to cite them other than as "work in progress."
   
  This Internet-Draft will expire on 11 April 2026.   This Internet-Draft will expire on 17 April 2026.
   
  Copyright Notice   Copyright Notice
   
  Copyright (c) 2025 IETF Trust and the persons identified as the   Copyright (c) 2025 IETF Trust and the persons identified as the
  document authors. All rights reserved.   document authors. All rights reserved.
  This document is subject to BCP 78 and the IETF Trust's Legal   This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents (https://trustee.ietf.org/   Provisions Relating to IETF Documents (https://trustee.ietf.org/
  license-info) in effect on the date of publication of this document.   license-info) in effect on the date of publication of this document.
       
Skipping Skipping
  14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
  14.1. BFD Auth Types . . . . . . . . . . . . . . . . . . . . . 28   14.1. BFD Auth Types . . . . . . . . . . . . . . . . . . . . . 28
  14.2. IETF XML Registry . . . . . . . . . . . . . . . . . . . 28   14.2. IETF XML Registry . . . . . . . . . . . . . . . . . . . 28
  14.3. The YANG Module Names Registry . . . . . . . . . . . . . 28   14.3. The YANG Module Names Registry . . . . . . . . . . . . . 28
  15. Security Considerations . . . . . . . . . . . . . . . . . . . 29   15. Security Considerations . . . . . . . . . . . . . . . . . . . 29
  15.1. Protocol Security Considerations . . . . . . . . . . . . 29   15.1. Protocol Security Considerations . . . . . . . . . . . . 29
  15.1.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . 29   15.1.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . 29
  15.1.2. Re-Use of keys . . . . . . . . . . . . . . . . . . . 30   15.1.2. Re-Use of keys . . . . . . . . . . . . . . . . . . . 30
    15.1.3. Random Number Considerations . . . . . . . . . . . . 31
  15.2. YANG Security Considerations . . . . . . . . . . . . . . 31   15.2. YANG Security Considerations . . . . . . . . . . . . . . 31
  16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31   16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
  17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31   17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
  18. References . . . . . . . . . . . . . . . . . . . . . . . . . 31   18. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
  18.1. Normative References . . . . . . . . . . . . . . . . . . 31   18.1. Normative References . . . . . . . . . . . . . . . . . . 32
  18.2. Informative References . . . . . . . . . . . . . . . . . 32   18.2. Informative References . . . . . . . . . . . . . . . . . 33
  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
   
  1. Introduction   1. Introduction
   
  BFD [RFC5880] (Section 6.7) defines a number of authentication   BFD [RFC5880] (Section 6.7) defines a number of authentication
  mechanisms, including Simple Password, and various other methods   mechanisms, including Simple Password, and various other methods
  based on MD5 and SHA1 hashes. The benefit of using cryptographic   based on MD5 and SHA1 hashes. The benefit of using cryptographic
  hashes is that they are secure. The downside to cryptographic hashes   hashes is that they are secure. The downside to cryptographic hashes
  is that they are expensive and time consuming on resource-constrained   is that they are expensive and time consuming on resource-constrained
       
Skipping Skipping
   
  This document uses several placeholder values throughout the   This document uses several placeholder values throughout the
  document. Please replace them as follows and remove this note before   document. Please replace them as follows and remove this note before
  publication.   publication.
   
  RFC XXXX, where XXXX is the number assigned to this document at the   RFC XXXX, where XXXX is the number assigned to this document at the
  time of publication.   time of publication.
   
  2025-10-08 with the actual date of the publication of this document.   2025-10-14 with the actual date of the publication of this document.
   
  2. Experimental updates to RFC 5880   2. Experimental updates to RFC 5880
   
  This document describes an experimental update to BFD [RFC5880].   This document describes an experimental update to BFD [RFC5880].
  This experiment is intended to provide additional insights into what   This experiment is intended to provide additional insights into what
  happens when the authentication method defined in this document is   happens when the authentication method defined in this document is
  used.   used.
  This document is classified as Experimental and is not part of the   This document is classified as Experimental and is not part of the
       
Skipping Skipping
  This YANG module adds two identities defined in this document to the   This YANG module adds two identities defined in this document to the
  IETF Keychain Model [RFC8177]. One of them uses the Meticulous Keyed   IETF Keychain Model [RFC8177]. One of them uses the Meticulous Keyed
  MD5 as the more computationally intensive authentication and   MD5 as the more computationally intensive authentication and
  Meticulous Keyed ISAAC Keyed as the less computationally intensive   Meticulous Keyed ISAAC Keyed as the less computationally intensive
  authentication. The other uses the Meticulous Keyed SHA-1 as the   authentication. The other uses the Meticulous Keyed SHA-1 as the
  more computationally intensive authentication and Meticulous Keyed   more computationally intensive authentication and Meticulous Keyed
  ISAAC Keyed as the less computationally intensive authentication.   ISAAC Keyed as the less computationally intensive authentication.
   
  <CODE BEGINS> file "ietf-bfd-met-keyed-isaac@2025-10-08.yang"   <CODE BEGINS> file "ietf-bfd-met-keyed-isaac@2025-10-14.yang"
  module ietf-bfd-met-keyed-isaac {   module ietf-bfd-met-keyed-isaac {
  yang-version 1.1;   yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac";   namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac";
  prefix "bfd-mki";   prefix "bfd-mki";
   
  import ietf-key-chain {   import ietf-key-chain {
  prefix key-chain;   prefix key-chain;
  reference   reference
       
Skipping Skipping
  forth in Section 4.c of the IETF Trust's Legal Provisions   forth in Section 4.c of the IETF Trust's Legal Provisions
  Relating to IETF Documents   Relating to IETF Documents
  (https://trustee.ietf.org/license-info).   (https://trustee.ietf.org/license-info).
   
  This version of this YANG module is part of RFC XXXX   This version of this YANG module is part of RFC XXXX
  (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself   (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
  for full legal notices.";   for full legal notices.";
   
  revision "2025-10-08" {   revision "2025-10-14" {
  description   description
  "Initial Version.";   "Initial Version.";
  reference   reference
  "RFC XXXX: Meticulous Keyed ISAAC for BFD Optimized   "RFC XXXX: Meticulous Keyed ISAAC for BFD Optimized
  Authentication.";   Authentication.";
  }   }
   
  identity optimized-md5-meticulous-keyed-isaac {   identity optimized-md5-meticulous-keyed-isaac {
       
Skipping Skipping
   
  Implementations are therefore free to use the same key, or different   Implementations are therefore free to use the same key, or different
  keys. The use of the same key for for both more and less   keys. The use of the same key for for both more and less
  computationally intensive authentication is acceptable, as ISAAC is   computationally intensive authentication is acceptable, as ISAAC is
  keyed not only with the authentication key, but also depends on 32   keyed not only with the authentication key, but also depends on 32
  bits of random data, along with 32 bits of a Sequence Number. The   bits of random data, along with 32 bits of a Sequence Number. The
  use of this added randomness increases the difficulty of breaking the   use of this added randomness increases the difficulty of breaking the
  key.   key.
    15.1.3. Random Number Considerations
   
    BFD [RFC5880] and its Authentication mechanisms, including the
    Meticulous Keyed ISAAC authentication mode specified in this
    document, make use of random numbers. Such numbers are used in:
   
    * Per BFD session Local Discriminators (bfd.LocalDiscr -
    Section 6.8.1 of [RFC5880])
    * Initial Authentication sequence number (bfd.XmitAuthSeq -
    Section 6.8.1 of [RFC5880])
    * Meticulous Keyed ISAAC Authentication, ISAAC Format Seed
    (Section 4.1)
   
    The mechanism defined in this document creates an instance of ISAAC
    for each BFD session seeded by that session's Secret Key(s), and two
    locally generated random numbers: the session's Local Discriminator
    echoed back in the protocol as Your Discriminator, and a locally
    generated Seed. These random numbers are infrequently generated by
    comparison to the use case for BFD Optimized Authentication that
    ISAAC addresses. Thus, stronger random number generators with better
    guarantees of entropy can be used for these purposes.
   
    It is RECOMMENDED that these locally generated random numbers used
    for the BFD protocol and for initializing ISAAC utilize a non-ISAAC
    CSPRNG.
   
    Should an implementation for unknown reasons not have alternative
    CSPRNGs available, ISAAC could be utilized to provide local random
    numbers. In order to avoid inappropriate disclosure of local random
    number generator state, the random number generator for these locally
    generated values MUST NOT reuse instances of ISAAC initialized for
    use for BFD sessions.
   
  15.2. YANG Security Considerations   15.2. YANG Security Considerations
   
  This section is modeled after the template described in Section 3.7   This section is modeled after the template described in Section 3.7
  of [I-D.ietf-netmod-rfc8407bis].   of [I-D.ietf-netmod-rfc8407bis].
   
  The "ietf-bfd-met-keyed-isaac" YANG module defines a data model that   The "ietf-bfd-met-keyed-isaac" YANG module defines a data model that
  is designed to be accessed via YANG-based management protocols, such   is designed to be accessed via YANG-based management protocols, such
  as NETCONF [RFC6241] or RESTCONF [RFC8040]. These YANG-based   as NETCONF [RFC6241] or RESTCONF [RFC8040]. These YANG-based
  management protocols (1) have to use a secure transport layer (e.g.,   management protocols (1) have to use a secure transport layer (e.g.,
  SSH [RFC4252] TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use   SSH [RFC4252] TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use
  mutual authentication.   mutual authentication.
   
  The Network Configuration Access Control Model (NACM) [RFC8341]   The Network Configuration Access Control Model (NACM) [RFC8341]
  provides the means to restrict access for particular NETCONF or   provides the means to restrict access for particular NETCONF or
  RESTCONF users to a preconfigured subset of all available NETCONF or   RESTCONF users to a preconfigured subset of all available NETCONF or
  RESTCONF protocol operations and content.   RESTCONF protocol operations and content.
   
  The YANG module defines a set of identities. These identities are   The YANG module defines a set of identities. These identities are
  intended to be reused by other YANG modules. The module by itself   intended to be reused by other YANG modules. The module by itself
  does not expose any data nodes that are writable, data nodes that   does not expose any data nodes that are writable, data nodes that
       
Skipping Skipping
  The authors want to thank Ketan Talaulikar for his reviews and   The authors want to thank Ketan Talaulikar for his reviews and
  suggestions that have improved the document.   suggestions that have improved the document.
   
  18. References   18. References
   
  18.1. Normative References   18.1. Normative References
   
  [I-D.ietf-bfd-optimizing-authentication]   [I-D.ietf-bfd-optimizing-authentication]
  Jethanandani, M., Mishra, A., Saxena, A., Bhatia, M., and   Jethanandani, M., Mishra, A., Haas, J., Saxena, A., and M.
  J. Haas, "Optimizing BFD Authentication", Work in   Bhatia, "Optimizing BFD Authentication", Work in Progress,
  Progress, Internet-Draft, draft-ietf-bfd-optimizing-   Internet-Draft, draft-ietf-bfd-optimizing-authentication-
  authentication-33, 10 September 2025,   35, 8 October 2025,
  <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-   <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-
  optimizing-authentication-33>.   optimizing-authentication-35>.
   
  [ISAAC] Jenkins, R. J., "ISAAC",   [ISAAC] Jenkins, R. J., "ISAAC",
  http://www.burtleburtle.net/bob/rand/isaac.html, 1996.   http://www.burtleburtle.net/bob/rand/isaac.html, 1996.
   
  [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  Requirement Levels", BCP 14, RFC 2119,   Requirement Levels", BCP 14, RFC 2119,
  DOI 10.17487/RFC2119, March 1997,   DOI 10.17487/RFC2119, March 1997,
  <https://www.rfc-editor.org/info/rfc2119>.   <https://www.rfc-editor.org/info/rfc2119>.
   
  [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,   [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
  DOI 10.17487/RFC3688, January 2004,   DOI 10.17487/RFC3688, January 2004,
  <https://www.rfc-editor.org/info/rfc3688>.   <https://www.rfc-editor.org/info/rfc3688>.
   
  [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection   [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
  (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,   (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
  <https://www.rfc-editor.org/info/rfc5880>.   <https://www.rfc-editor.org/info/rfc5880>.
   
  [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for   [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
  the Network Configuration Protocol (NETCONF)", RFC 6020,   the Network Configuration Protocol (NETCONF)", RFC 6020,
  DOI 10.17487/RFC6020, October 2010,   DOI 10.17487/RFC6020, October 2010,
  <https://www.rfc-editor.org/info/rfc6020>.   <https://www.rfc-editor.org/info/rfc6020>.
       
Skipping Skipping
  [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)   [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
  Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,   Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
  January 2006, <https://www.rfc-editor.org/info/rfc4252>.   January 2006, <https://www.rfc-editor.org/info/rfc4252>.
   
  [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,   [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
  and A. Bierman, Ed., "Network Configuration Protocol   and A. Bierman, Ed., "Network Configuration Protocol
  (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,   (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
  <https://www.rfc-editor.org/info/rfc6241>.   <https://www.rfc-editor.org/info/rfc6241>.
   
  [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF   [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
  Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,   Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
  <https://www.rfc-editor.org/info/rfc8040>.   <https://www.rfc-editor.org/info/rfc8040>.
   
  [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration   [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
  Access Control Model", STD 91, RFC 8341,   Access Control Model", STD 91, RFC 8341,
  DOI 10.17487/RFC8341, March 2018,   DOI 10.17487/RFC8341, March 2018,
  <https://www.rfc-editor.org/info/rfc8341>.   <https://www.rfc-editor.org/info/rfc8341>.
   
  [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol   [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
  Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,   Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
  <https://www.rfc-editor.org/info/rfc8446>.   <https://www.rfc-editor.org/info/rfc8446>.
   
  [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based   [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
  Multiplexed and Secure Transport", RFC 9000,   Multiplexed and Secure Transport", RFC 9000,
  DOI 10.17487/RFC9000, May 2021,   DOI 10.17487/RFC9000, May 2021,
  <https://www.rfc-editor.org/info/rfc9000>.   <https://www.rfc-editor.org/info/rfc9000>.
       
Skipping Skipping
  United States of America   United States of America
  Email: [email protected]   Email: [email protected]
  URI: www.cisco.com   URI: www.cisco.com
   
   
  Ashesh Mishra   Ashesh Mishra
  Aalyria Technologies   Aalyria Technologies
  Email: [email protected]   Email: [email protected]
   
   
  Jeffrey Haas   Jeffrey Haas
  HPE   HPE
  Email: [email protected]   Email: [email protected]

Reply via email to