Re: [secdir] secdir review of draft-jabley-dnsext-eui48-eui64-rrtypes

["Murphy, Sandra" <[e-mail]>]

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: [e-mail] [[e-mail]] on behalf of Murphy, Sandra [[e-mail]]
Sent: Thursday, July 11, 2013 5:42 AM
To: [e-mail]; [e-mail]; [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview