Deb Cooley has entered the following ballot position for draft-ietf-bfd-secure-sequence-numbers-25: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Discuss: A discuss is merely the start of a conversation. The terseness of this review reflects on my history (37 years as a security evaluator). I believe it is possible to get this draft to publication, but it will take real work (I'm happy to help). This is a list of the areas that I believe are poorly specified: 1. operating situation: Fast networks speeds combined with inadequate CPU capability will drive the solution which is practical. Please explain this. 2. Use of previously unheard of 30 year old algorithms: In this particular case, because the security requirements are rudimentary at best, this is ok. But the draft needs to reduce the language leading the reader to overestimate the strength or assurance provided by this algorithm. This includes 'significant evaluation', 'strong authentication', etc. Security Considerations needs to state clearly that this algorithm is approved only for this use case, under these operating conditions (speed of network, capability of CPU) and no others. 3. key management: There is very little information in this draft that outlines how various keys (per party Secret keys, per session seeds, initial sequence numbers) are handled. This includes generation, distribution, storage, and removal. While there are many references to a 'cryptographically strong pseudo-number generator', it is never defined. The test data in Section 10 apparently encourages operators to use a password as a Secret Key without any further processing (no pbkdf required, apparently). There is no mention in the Security Considerations to caution the implementer on what care needs to be taken with respect to these values, and their handling. My comments below may point back to this discuss. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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.
