[secdir] secdir review of draft-ietf-dhc-access-network-identifier-08

Catherine Meadows <catherine.meadows@nrl.navy.mil> Thu, 25 June 2015 14:56 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DDD1A89FC; Thu, 25 Jun 2015 07:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmzecNwCDbea; Thu, 25 Jun 2015 07:56:17 -0700 (PDT)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F2C1A8A11; Thu, 25 Jun 2015 07:56:17 -0700 (PDT)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t5PEuFoU029399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Jun 2015 10:56:16 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7124DE79-BC50-4B4F-86CD-478563904C33"
Date: Thu, 25 Jun 2015 10:56:11 -0400
Message-Id: <D2D64A55-212E-4EED-8545-F0E3ACF8F0CD@nrl.navy.mil>
To: draft-ietf-dhc-access-network-identifier.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/CwPKBnxzGEI2GlXhXhP2K9OJAlY>
Subject: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 25 Jun 2015 14:56:19 -0000

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 draft specifies the format and mechanisms used for encoding network identifiers in DHCPv4 and DHCPv6 by defining new access identifier options and sub-options.
The Security Considerations section gives a discussion of the security risks in using DHCP and their mitigation.  However, what needs to be go in the Security Considerations
Section is a discussion of the security risks raised by *this* document and possible mitigation.  The information about DHCP security risks is useful, but not of primary importance.

My impression is that this document gives formats for presenting fields whose use is already discussed in previous RFC’s, e.g. RFC3315, in which case there are no new
security considerations.  If that is so, then the Security Considerations Section should
include (preferably begin with) a statement to the effect that, since this document only gives instructions for formatting and encoding fields whose use has already been specified
in these previous RFC’s, it presents no additional security considerations beyond what is covered in those RFCs.  If that is not the case, you should say what new security risks are introduced
by *this* draft, e.g. does it enable a use of DHCP that was not possible before and could cause a new type of security risk if DHCP was used without authentication?

Recommendation:  Ready With Issues

Cathy Meadows


Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil