[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
- [secdir] draft-zheng-mpls-ldp-hello-crypto-auth-0… Donald Eastlake