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

"Sri Gundavelli (sgundave)" <> Fri, 10 July 2015 16:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 92F4D1B2CF0; Fri, 10 Jul 2015 09:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TgzkgXcI7wHB; Fri, 10 Jul 2015 09:19:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79ECA1B2CE8; Fri, 10 Jul 2015 09:19:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10999; q=dns/txt; s=iport; t=1436545188; x=1437754788; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cEGsdcYlCqQY0JdyD3yZ1Il3BHn9dDgw8zNLlsSBGhE=; b=dMbL8xhUI4PQd0qGTuuKod7d4tYFvqw7o+jryqQAwznkFYY/NciEL3gT Dqp2U4QqXKNCziBsrFJEE5Nsq7B/SruuD0+caCkC93giRyn0u6XEkQ8B0 FD/xfZJF0H48MB46hIpecPUVaTysskFEhXdnRw7reH0anq9xa6rPYifQD s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,447,1432598400"; d="scan'208,217";a="167148088"
Received: from ([]) by with ESMTP; 10 Jul 2015 16:19:38 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t6AGJcJJ025172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jul 2015 16:19:38 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 10 Jul 2015 11:19:38 -0500
From: "Sri Gundavelli (sgundave)" <>
To: Catherine Meadows <>, "" <>, "" <>, "" <>
Thread-Topic: secdir review of draft-ietf-dhc-access-network-identifier-08
Thread-Index: AQHQr1cxQgFsakfaFEigKP+HYJIb8p3U2DaA
Date: Fri, 10 Jul 2015 16:19:37 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D1C53A5B1CA8B1sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jul 2015 16:19:50 -0000

Hi Catherine,

Thanks for the review.

> 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.

Agree with this comment. The  draft is defining some new information elements that are carried between the DHCP entities and any new security considerations are around exposing that data to third parties.

"The information elements that this draft is exposing is the client’s access-network information. These pertains to the access network to which the client is attached, such as Access Technology Type (Ex: WLAN, Ethernet…etc), Access Point Identity (Name, BSSID), Operator Id/Realm. Exposing these information elements to  has no implication on the end-user security. But, in deployments where this information is considered secure and when such threat cannot be mitigated using the currently available security tools, then the administrators have to consider disabling this capability on the DHCP entities."

Is this sufficient ?


From: Catherine Meadows <<>>
Date: Thursday, June 25, 2015 at 7:56 AM
To: "<>" <<>>, "<>" <<>>, "<>" <<>>
Cc: Catherine Meadows <<>>
Subject: secdir review of draft-ietf-dhc-access-network-identifier-08
Resent-From: <<>>
Resent-To: <<>>
Resent-Date: Thursday, June 25, 2015 at 7:56 AM

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