Re: [secdir] secdir review of draft-jabley-dnsext-eui48-eui64-rrtypes
"Murphy, Sandra" <Sandra.Murphy@sparta.com> Thu, 11 July 2013 10:02 UTC
Return-Path: <Sandra.Murphy@sparta.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 3CC6721F9CAC for <secdir@ietfa.amsl.com>; Thu, 11 Jul 2013 03:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 ILK58w3X-bfF for <secdir@ietfa.amsl.com>; Thu, 11 Jul 2013 03:01:59 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2889121F9CF8 for <secdir@ietf.org>; Thu, 11 Jul 2013 03:01:59 -0700 (PDT)
Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r6BA1wRi013427 for <secdir@ietf.org>; Thu, 11 Jul 2013 05:01:58 -0500
Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r6BA1wen029230 for <secdir@ietf.org>; Thu, 11 Jul 2013 05:01:58 -0500
Received: from CVA-MB001.centreville.ads.sparta.com ([fe80::58b4:c7c2:f9d:dff9]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Thu, 11 Jul 2013 06:02:44 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: secdir review of draft-jabley-dnsext-eui48-eui64-rrtypes
Thread-Index: Ac5+GumGNRYPxviKTWiCYPIIjmd3zQAAgg/W
Date: Thu, 11 Jul 2013 10:02:43 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6749A56DB@CVA-MB001.centreville.ads.sparta.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F6749A56A9@CVA-MB001.centreville.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6749A56A9@CVA-MB001.centreville.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.62.8.137]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [secdir] secdir review of draft-jabley-dnsext-eui48-eui64-rrtypes
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: Thu, 11 Jul 2013 10:02:03 -0000
A further comment, for secdir consideration only. IPv6 addresses are in some cases derived from the MAC address, which would seem to make facilitating MAC cloning also facilitate IP address spoofing. But I haven't worked out a way that cloning MAC addresses and thereby spoofing the corresponding IPv6 address results in some *new* risk, particularly since finding the MAC address in the Canadian DOCSIS case requires knowing the IP address to begin with in order to look up the EUI in the reverse DNS, if I understand NTRE038 correctly. If the EUI RR were associated with some other DNS name (not the reverse zone), then the bad guy could look up that DNS name, find the EUI, construct the corresponding IPv6 address and misuse the IPv6 address. But that additional risk would apply only to an application in which there was a DNS name was associated with an EUI record but not an A record. Given the tendency to stuff everything into DNS, I can't say that *won't* happen. Perhaps someone here more inventive can see an exploit. I'm only uneasy, not really worried. --Sandy ________________________________________ From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] on behalf of Murphy, Sandra [Sandra.Murphy@sparta.com] Sent: Thursday, July 11, 2013 5:42 AM To: secdir@ietf.org; iesg@ietf.org; draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org Subject: [secdir] secdir review of draft-jabley-dnsext-eui48-eui64-rrtypes 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 suggests two new DNS RRtypes that could encode IEEE EUI-48 and EUI-64 layer-2 addresses. There is at least one known use case of a Canadian required reverse DNS mapping of IP addresses to MAC addresses. The draft is simple and straight forward and follows the usual procedure for requesting a new RRtype. Security concern. You might want to mention that publication of the EUI's could facilitate MAC cloning. This isn't original to me. I followed the reference to the Canadian CRTC decision NTRE038D and looked at the various company "contributions" that led to that decision. One contribution from Clearcable (NTCO0362, see http://www.crtc.gc.ca/public/cisc/nt/NTCO0362.pdf) speaks of the risk that publication of EUI addresses in the global reverse DNS would facilitate the theft of service that arises from cloning the MAC address of a valid subscriber. DOCSIS modem MAC cloning does seem to be a known problem and concern, so perhaps this should be mentioned. The draft recommends restricting access to zones containing EUI64 addresses to limit the privacy exposure. This is similar to the recommendation in the NTRE038D to use a split-view reverse DNS service. The draft's recommendation would also limit the exposure of valid EUI-64 addresses to MAC cloners, so I don't think you need to describe additional countermeasures. Nits and even more anal comments: Section 9 says "with the Global bit zero". I presume you mean the next-to-least-significant-bit in the first octet. RFC 5342 calls this bit the "Local bit" and the "Local/Global bit". RFC4291 calls this the "universal/local" bit. The IEEE 802 standard talks about "universal" and "local" without actually naming the bit, but lots of online documentation says "universal/local" and "U/L". So you and the RFC Editor can decide what term to use. IMHO: Continuing to call it the "Global bit" is my least favorite choice. Consistency with RFC5342 or RFC4291 would be preferable. Section 9 says: Publication of EUI-48 or EUI-64 addresses in the global DNS may result in privacy issues in the form of unique trackable identities. The privacy concern arises not just from the uniqueness of the EUI but from the fact that it is a more permanent identifier than the IP address associated with the subscriber (as the next paragraph notes). So "in the form of unique, permanent trackable identities" is probably more accurate. Similarly in the next paragraph "EUI-64 addresses normally provide a unique identifier" - the point is that the IP address "typically change over time" so "provide a unique permanent identifier" is what you mean. I think. The details of the IEEE references are incomplete. I might have recommended copying the references in RFC5342 but those references look to be out of date. I did find "Guidelines for 64-bit Global Identifier (EUI-64)" http://standards.ieee.org/develop/regauth/tut/eui64.pdf. The URL shown in RFC5342 for [EUI-64] redirects to that URL. --Sandy _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
- [secdir] secdir review of draft-jabley-dnsext-eui… Murphy, Sandra
- Re: [secdir] secdir review of draft-jabley-dnsext… Murphy, Sandra