[secdir] draft-zheng-mpls-ldp-hello-crypto-auth-05.txt

Donald Eastlake <d3e3e3@gmail.com> Sun, 29 July 2012 06:45 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C5E11E8097 for <secdir@ietfa.amsl.com>; Sat, 28 Jul 2012 23:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.513
X-Spam-Level:
X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlzLrPCD6InY for <secdir@ietfa.amsl.com>; Sat, 28 Jul 2012 23:45:50 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF72B11E8072 for <secdir@ietf.org>; Sat, 28 Jul 2012 23:45:49 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so7941888obb.31 for <secdir@ietf.org>; Sat, 28 Jul 2012 23:45:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=bgd5bRqhZ866+m7vGCum4oEOUAX4uMwA05ADUI6+//c=; b=ODu4gfCoizySCI+7Ugqglpxof4rdP2NeHvMFbu+Jbm+c5eYNuSs0JJF4wDGQDOrGym EgnJOpo1QjoEElF/iMFqu1jgQNW8sFqw+M7aH+ofh+4c+HTFVf3TCuxE5vnhI8ZogOZl 1Ui/GPpCaWwQJ8TfuvD2ZJbRTDb6TeJ/l6fri7asfUrRdN/Ryc76JBLuC6eZHOw/75b2 G/l81yOXuT9OYvabzBij6Mys/yEi92CPZyT8w+CUgRFI0dNSq8eYn8qwvZocOLzsptci GIu2I6oh1Pqo47E+Oj5x1GeutUxYuE4doyG7/PcIXiXqS8KpK0BIWcjcq0d7lQj1LCJT TTXQ==
Received: by 10.50.34.200 with SMTP id b8mr8388914igj.50.1343544349429; Sat, 28 Jul 2012 23:45:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.70.227 with HTTP; Sat, 28 Jul 2012 23:45:29 -0700 (PDT)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 29 Jul 2012 02:45:29 -0400
Message-ID: <CAF4+nEFRqm+Mo2cu_jYMt13_kTBM=G3iH_ymFi4ghPcG2Uu4xg@mail.gmail.com>
To: draft-zheng-mpls-ldp-hello-crypto-auth.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Cc: secdir@ietf.org
Subject: [secdir] draft-zheng-mpls-ldp-hello-crypto-auth-05.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Jul 2012 06:45:50 -0000

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@gmail.com