[secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

[Yaron Sheffer <[e-mail]>]

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