Last Call Review of draft-ietf-mpls-ldp-hello-crypto-auth-05
review-ietf-mpls-ldp-hello-crypto-auth-05-secdir-lc-sheffer-2014-05-22-00
Request | Review of | draft-ietf-mpls-ldp-hello-crypto-auth |
---|---|---|
Requested revision | No specific revision (document currently at 10) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2014-05-21 | |
Requested | 2014-05-08 | |
Authors | Lianshu Zheng , Mach Chen , Manav Bhatia | |
I-D last updated | 2014-05-22 | |
Completed reviews |
Genart Last Call review of -05
by Vijay K. Gurbani
(diff)
Secdir Last Call review of -05 by Yaron Sheffer (diff) Opsdir Telechat review of -08 by Linda Dunbar (diff) |
|
Assignment | Reviewer | Yaron Sheffer |
State | Completed | |
Request | Last Call review on draft-ietf-mpls-ldp-hello-crypto-auth by Security Area Directorate Assigned | |
Reviewed revision | 05 (document currently at 10) | |
Result | Has issues | |
Completed | 2014-05-22 |
review-ietf-mpls-ldp-hello-crypto-auth-05-secdir-lc-sheffer-2014-05-22-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document proposes to add cryptographic authentication to LDP "all routers" Hello messages, which are transported as unicast UDP. Summary The document may be ready to publish, but this reviewer has major issues with the selected solution. Details • The main issue is that only a symmetric crypto option is defined. IMHO, adding a public-key based scheme would be invaluable. Public keys do not necessarily imply certificates, and can be used with little added complexity compared to the current proposal. As far as I can see, the current use is not so performance constrained to preclude public key operations. And public keys would enable much easier and more secure deployment in many cases: ∘ Different organizations can accept messages from one another, without needing to share the same keys. So even if groups keys are used (which is certainly not the best practice), public keys have an advantage. ∘ Revocation is much simpler: to be able to revoke each individual sender (e.g. when a router is decomissioned), you need N**2 SAs in the symmetric case, vs. N keys when public keys are used. • Managing the 32-bit SAID manually in a large network is extremely onerous. So in practice keys would be rarely on never changed. • 2.2: the authentication algorithm and the authentication key are not "independent", because the algorithm normally determines the key length. • 2.2: the various time values included in the SA essentially require (rough) time synchronization between the nodes. If this is the case, time values could have been used for replay protection, which would have been much simpler to implement than the 64-bit sequence number which needs to persist across reboots. • 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This reviewer does not have the appropriate background to critique the proposed solution, but there must be an overwhelming reason to reopen cryptographic primitives. • 7: 128-bit keys are OK (or overkill) for some algorithms, but too short for others. In general, the recommended key length is not constant. It depends on the algorithm. • "The mechanism described herein is not perfect and does not need to be perfect." This is kind of vague, and would be better replaced by your security goals. Thanks, Yaron