Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols
RFC 6094
Note: This ballot was opened for revision 04 and is now closed.
(Ron Bonica) Yes
(Adrian Farrel) (was Discuss) Yes
Comment (2010-09-29 for -)
No email
send info
send info
Moved one small point from my previous Discuss. WOuld be nice to get it fixed. You have caught most cases of ... In order for ... implementations to interoperate, they must support one or more authentication schemes in common. ... with good change to include "with the use of security" However, I still see issues in sections 2.2 (first line), 3.2 (first line), 5.2 (first line)
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
Comment (2010-09-22 for -)
No email
send info
send info
For consistency, add citations to the defining RFCs that define the use of HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 in the various routing protocols; e.g., Implementations may start providing support for HMAC-SHA-256/HMAC- SHA-384/HMAC-SHA-512 [RFC5310] as these algorithms may be necessary in the future. at the end of section 3.2
(Lars Eggert) No Objection
Comment (2010-09-22 for -)
No email
send info
send info
INTRODUCTION, paragraph 3: > Cryptographic Authentication Algorithm Implementation > Best Practices for Routing Protocols It is odd to see the term "best practices" in the title of a document that is not actually targeted as a BCP. Plus, the contents of the document aren't best practices, they are rather suggestions to implementors to avoid potential future interoperability issues. Suggest to reword the title. Section 4.1, paragraph 4: > all conformant implentations MUST support this. Nit: s/implentations/implementations/ Section 11.1, paragraph 2: > [ISO] "Intermediate system to Intermediate system routeing Nit: s/routeing/routing/
(Russ Housley) No Objection
Comment (2010-09-19 for -)
No email
send info
send info
Two spellings are used: "Null authentication" and "NULL authentication". Please pick one. In the Introduction, I think it is better to talk about the overall technique before particular algorithms like MD5. Below I suggest rewording for 3rd and 4th and 5th paragrahs of the introduction. In a cryptographic authentication scheme, routers share a secret key which is used to generate a message authentication code for each of the protocol packets. Today, message authentication codes often use a keyed MD5 digest. The recent escalating series of attacks on MD5 raise concerns about its remaining useful lifetime. These attacks may not necessarily result in direct vulnerabilities for keyed MD5 digests as message authentication codes because the colliding message may not correspond to a syntactically correct protocol packet. There is a however a need felt to deprecate MD5 in favor of stronger message authentication code algorithms.
(Tim Polk) (was Discuss) No Objection
Comment (2010-09-23)
No email
send info
send info
I support Sean's discuss issue #4
(Dan Romascanu) No Objection
(Robert Sparks) (was Discuss) No Objection
(Sean Turner) (was Discuss) No Objection
Comment (2010-09-23)
No email
send info
send info
1) The RFC editor will make you scrub the references (i.e., [RFCXYZ]) from the abstract. Move them to the Introduction. 2) Section 2 and the "conventions used in this document" section are the same. Keep the 2nd (that's where the RFC editor will put it). 3) It's probably worth adding a reference to SHS (for the SHA family): [SHS] National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008. 4) Sec 6: Is there something missing from the end of this sentence maybe "packet": If the Address Family Identifier of the first (and only the first) entry in the message is 0xFFFF, then the remainder of the entry contains the authentication. 5) Sec 3.1: r/scheme as provides no/scheme as it provides no