Early Review of draft-zheng-mpls-ldp-hello-crypto-auth-
review-zheng-mpls-ldp-hello-crypto-auth-secdir-early-eastlake-2012-08-01-00

Request Review of draft-zheng-mpls-ldp-hello-crypto-auth
Requested rev. no specific revision (document currently at 05)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2012-08-01
Requested 2012-06-19
Draft last updated 2012-08-01
Completed reviews Secdir Early review of -?? by Donald Eastlake
Assignment Reviewer Donald Eastlake
State Completed
Review review-zheng-mpls-ldp-hello-crypto-auth-secdir-early-eastlake-2012-08-01
Review result Ready with Nits
Review completed: 2012-08-01

Review
review-zheng-mpls-ldp-hello-crypto-auth-secdir-early-eastlake-2012-08-01

As requested I have done an early review this document as part of the
security directorate's ongoing efforts.

There are no big problems with this draft but I have some medium,
small, and tiny comments below.

Medium Comments:

   Suggest removing the last sentence of Section 4.1 and adding to end
   of the first sentence of the second paragraph of the Security
   Considerations section something like ", and proper key handling.
   For example, unencrypted keys MUST NOT be exposed to adversaries
   through inclusion in unencyrpted Hellos or other messages."

   The draft is worded in such a way as to imply that only an "HMAC
   hash" would ever be used for authentication. It would seem better
   to word things so as just to say that a Message Authentication Code
   (MAC) will be calculated and verified. Then, somewhat separately,
   say that the MAC algorithms currently specified for this use are
   only HMACs based on the SHA family of hash algorithms. For example,
   in the second paragraph of 4.1, replace "HMAC Hash" with "MAC" and
   make other appropriate wording changes.

   Section 4.1, second paragraph, suggest replaceing "current
   authentication key" with "authentication key to be used".

   Section 4.2, 2nd paragraph, suggest replacing "configured
   authentication key" with "authentication key known to the
   receiver".  There might, in the future, be some mechanism to
   neogitate a key rather than always having it configured.

   In Security Considerations, suggest adding a reference after
   "random values" to [RFC4086].

Small Comments:

   Suggest adding a reference to [RFC6234].

   There should be postal addresses and phone numbers with the
   Authors' Addresses information.

Tiny Comments:

   Last paragraph of Security Considerations, "represents a
   significant increase in" -> "significantly increases".

   There seems to be this empty "8.2 References" section between the
   Normative References and Informative References Sections. It should
   be removed.

   I really suggest striking both occurance of the word "really" in
   the draft.

   I'm not sure all of Section 3 is needed, since it seems to me that
   lots of it is duplicated from referenced documents...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 at gmail.com