Meticulous Keyed ISAAC for BFD Optimized Authentication
draft-ietf-bfd-secure-sequence-numbers-27

Update:  Many thanks to the authors for the tremendous amount of work done to address my discuss.  [Note:  I've left my comments below as I wrote them initially, just for historical purposes.]


Thanks to Rich Salz for their secdir review.

Section 1:  Please mention earlier in the specification that this technique can only be used in conjunction with draft-ietf-bfd-optimizing-authentication.  As it stands, there is no use for this specification without that specification.

Section 1:  Please add a little bit more explanation to remind the reader why these normally fast hashes are too slow/hard.  Please address both speed of the transmission and capability of the device performing the hashes.

Section 1, Paragraph 3 and many other places: significant cryptanalysis/some cryptanalysis (2 documented efforts over 30 years is hardly 'significant').  I'm not sure who the authors are trying to convince.

Section 2:  Please define CSPRNG (I don't care where).  This draft currently makes the assumption that everyone knows what a CSPRNG is. [Note:  even though RFC 4086 is a decade younger than ISAAC, it is not considered to be up-to-date]

Section 4.1, sequence number and Section 6, para 1:  It is unclear to me how an unprotected sequence number prevents a replay attack.  Certainly the attacker can change the sequence number, or replay a packet with a modified sequence number.  The only protection against replay attacks for this system is via the Auth Key.  The sequence number is merely helpful for the recipient to attempt to determine the place on the table (and that only works if the packet hasn't been replayed).

Section 4.2 and 4.3:  These sections are merely repeats of sections in draft-ietf-bfd-optimizing-authentication?

Section 6, 'The Auth key field:  Where the sequence number is merely an index into the table of 256 values, no?  The sequence number is not part of the seeding of ISAAC.

Section 7:  Some of the state variables defined here have been used earlier in the specification.  Consider moving this section up to a place before the variables are used.

Section 8, para 2:  Multiple Secret Keys:  If this specification doesn't want to explain how they are used, then one should say they are 'out of scope'.  Please put the 'MUST NOT' sentence second in the paragraph (and remove the 'however'.  This puts the requirement where it will be more easily seen (i.e. don't bury the lead).

Section 8, para 3:  This could easily be put in Security Considerations.

Section 8:  How are the per party secret keys generated, distributed, protected?  If that is in scope, please describe.  If it is out of scope, please add appropriate guidance to Security Considerations.  

Section 9, para 8,9,&10:  Starting a paragraph with 'However' isn't clear.  Remove the 'However', add the word 'state' to variables, and combine the paragraphs/sentences.  Remove the last paragraph, or move it into Section 10.

Section 10, para 1:  This is the very first mention of 'Your Discriminator' field.  No where in the previous sections is this field discussed, defined.  In addition My Discriminator and Your Discriminator changes depending on perspective.  Does the sending and receiving systems use the same field (presumably with different values)?

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

Section 11.2, para 1:  This paragraph is not about multiple keys, but about key distribution. Please rename this to 'Secret Key Distribution' (if indeed this section is about Secret Keys).  What keys are being discussed here?  The Secret Key?  Are you saying that distribution of the Secret Key (aka password) is out of scope?  

Section 11.2, para 2:  The discussion of multiple keys needs to be defined to be out of scope too (again?).

Section 12:  I thought that draft-ietf-optimizing-authentication required that 'strong' authentication was used periodically, see Section 5.  'Thousands of packets' doesn't seem to be what was being proposed in that draft.  Please make these estimation of number of packets (currently thousands and hundreds) more realistic.

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?  

Section 15:  If the Secret Key is basically a password (see Section 10 test vectors) please explain how that generation should be accomplished.  Also please explain why a PBKDF isn't used to distribute what little entropy is in that password.  Or alternatively, explain how a PBKDF could be used.  Note:  since this is virtually the only value not transmitted across the network in the clear, it is the only unknown value to the attacker on the network.

Section 15.1, last paragraph:  Please tone down the 'analyzed for almost 3 decades' language.  I'm also curious about the perceived ineffectiveness of AES (which is commonly a standard cell in most CPUs).  The choice of AES in a stream cipher mode might have been just as quick, and certainly has almost 3 decades of real analysis.

Section 15.1.1, last paragraph:  More accurately, this technique prevents the attacker from spoofing UP packets.  It absolutely does not do anything to protect availability, injection of spoofed packets can take down a link (the definition of availability, right?).  If there is an ability to modify/block packets will destroy the link in very little time.  Please correct.

Section 15.1.2:  Are you recommending that the keys used for keyed MD5, keyed SHA1, and ISAAC be the same (aka the Secret Key)?  Please change this.  Any leak of any one of these keys (the ISAAC version is specified to be a password) would result in the attacker being able to construct any BFD packet, for any purpose.

# Internet AD comments for draft-ietf-bfd-secure-sequence-numbers-24
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3.1

* "and the numbers produced by it are secure"

  Claiming "are secure" seems a bit imprecise.  Perhaps "are sufficiently
  secure for the BFD authentication purposes here" or something?

### S8

* "makes these attacks unfeasable"

  Should this be more like "computationally infeasible" or
  "computationally intractable" or something?

## Nits

### S1

* "therefore define a Optimized" ->
  "therefore defines an Optimized"

### S3.1

* "rates of hundred of packets per second" ->
  "rates of hundreds of packets per second" ?

Thank you for preparing this I-D, and the careful text around how 
this provides an experimental change to BFD.

The I-D seems related to I-D.ietf-bfd-optimizing-authentication.
Whereas the current I-D in general is carefully constructed around 
the wording of security properties, the words here do not explain 
"optimizing" or "optimized" - which appear not to relate to security 
properties. For example, the following text states:

     "When the bfd.SessionState value is Up, packets MAY use an
      optimized authentication method (Optimizing BFD Authentication..."
 
- As noted to the Editors of I-D.ietf-bfd-optimizing-authentication,
I do wonder if this would be better described as lightweight/reduced processing 
requirements. 

I do not have any additional transport-related comments for this I-D.

Best wishes,
Gorry

Hi Jeff, all,

Thanks for addressing the DISCUSS/COMMENT points [1]. I trust that you will move 8177 to be listed as normative, though.

Cheers,
Med

[1] https://github.com/mjethanandani/bfd-secure-sequence-numbers/pull/49 and https://github.com/bfd-wg/optimized-auth/pull/73/

I support Deb's DICSUSS.
If it weren't this late in the process, I would have suggested to use SipHash instead of ISAAC.
https://en.wikipedia.org/wiki/SipHash