One document matched: draft-huitema-perpass-dhcp-identifiers-00.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY rfc2026 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>

<!ENTITY rfc791 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml'>
<!ENTITY rfc2131 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'>
<!ENTITY rfc2132 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'>
<!ENTITY rfc3942 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3942.xml'>
<!ENTITY rfc3315 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY rfc4361 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4361.xml'>

<!ENTITY rfc4702 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4702.xml'>

<!ENTITY rfc4578 PUBLIC ''
   'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4578.xml'>



]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>

<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>

<rfc category="info" 
     docName="draft-huitema-perpass-dhcp-identifiers-00.txt" 
     ipr="trust200902">

<front>
    <title abbrev="Unique Identifiers in DHCP">
      Unique Identifiers in DHCP options enable device tracking
    </title>

   <author fullname="Christian Huitema" initials="C." surname="Huitema">
      <organization> </organization>
      <address>
        <postal>
          <street> </street>
          <city>Clyde Hill</city>
          <code>98004</code>
          <region>WA</region>
          <country>U.S.A.</country>
        </postal>
        <email>huitema@huitema.net</email>
      </address>
    </author>

    <date year="2014" month="March"/>

    <abstract>
        <t> 
Some DHCP options carry unique identifiers. These identifiers can enable device tracking
even if the device administrator takes care of randomizing other potential 
identifications like link-layer addresses or IPv6 addresses. This document reviews these options 
and proposes solutions for better management.
        </t>
    </abstract>
</front>

<middle>
<section title="Introduction">
<t>
Reports surfaced recently of systems that would monitor the wireless connections of 
passengers at Canadian airports <xref target="CNBC" />. We can assume that these are either fragments
or trial runs of a wider system that would attempt to monitor Internet users as they roam through 
wireless access points and other temporary network attachments. We can also assume that privacy 
conscious users will attempt to evade this monitoring, for example by ensuring that low level 
identifiers like link-layer addresses are "randomized," so that the devices do not broadcast a unique identifier
in every location that they visit.
</t>
<t>
The IETF may or may not be in charge of the actual process for changing link-layer addresses as the mobile nodes 
move. But the IETF is in charge of protocols like DHCP or IPv6 neighbor discovery that use low level 
identifers and associate them with IPv4 or IPv6 addresses. The present note identifies specific issues 
with DHCP options that could be used to identify and track a device, even if the link-layer identifiers
were randomized.
</t>
<section title="Requirements">
<t>
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in <xref target="RFC2026" />.
</t>
</section>
</section>
<section title="Listening to DHCP traffic is easy">
<t>
The use of unique identifiers in DHCP is very much "by design." DHCP enables administrators to
easily configure network parameters of connected devices, and efficient management requires that the 
devices be well identified. However, this requirement of easy management conflicts with the desire to
maintain the privacy of the users when they visit "untrusted" networks. 
</t>
<t>
DHCP traffic is carried over multicast groups, and is thus very easy to monitor by anyone with access to 
the local link. A node that joins multicast group 224.0.0.12 and listen to traffic over port 68 will receive
a copy of all packets sent by clients to DHCP servers. Joining multicast group 224.0.0.12 and listening to 
port 67 will provide access to all packets sent by DHCP servers to clients.
</t>
<t>
In theory, it might be possible to modify the DHCP protocol to use unicast instead of multicast. Clients 
could perhaps discover the link layer address of the DHCP servers or relays, and servers or relays could 
send traffic directly to the link layer address of clients. This would make the traffic somewhat harder
to listen to, but would probably only be a minimal speed bump for pervasive monitoring agencies, who
can simply listen to all the link layer traffic, whether unicast or anycast.  
</t>
<t>
In theory, it might also be possible to negotiate some form of encryption between DHCP servers and DHCP 
clients. This would protect the privacy of DHCP clients, as long as pervasive monitoring agencies
do notpressure network operators to give them a copy of their DHCP traffic. But this would probably 
have a high deployment cost, as standard solutions like TLS or IPSEC can
only be deployed after the client has acquired an IP address through DHCP. 
</t>
<t>
Instead of proposing changes to the DHCP transport, or proposing encryption of the DHCP traffic, we consider 
here a simpler solution. The monitoring risk derives mostly from a set of DHCP options that carry unique
identifiers of the clients. It can be mitigated by careful management of the information sent in these options,
as explained in the next section. 
</t>
</section>
<section title="Managing Identifiers in DHCP Client Options">
<t>
The DHCP protocol consists of message excahnges between clients and servers. In the following discussion, we
will concentrate on the analysis of messages sent by the DHCP clients, which contain identifying information
provided by the client to the server.
</t>
<t>
Here is an example of DHCP message sent by a client, as captured by a network monitor. 
</t>
<figure>
<artwork align="left"><![CDATA[
......,........l  1 1 6 0 dd112cdb  0 080 0 c0a8 06c
................  0 0 0 0  0 0 0 0  0 0 0 0 e89a8fb3
K............... 4bad 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
................  0 0 0 0  0 0 0 0  0 0 0 0  0 0 0 0
............c.Sc  0 0 0 0  0 0 0 0  0 0 0 0 63825363
5..=......K...ic 35 1 83d  7 1e89a 8fb34bad  c 66963
ebox<.MSFT 5.07. 65626f78 3c 84d53 46542035 2e3037 d
....,./.!y.+....  1 f 3 6 2c2e2f1f 2179f92b fcff 0 0
............      0 0 0 0  0 0 0 0  0 0 0 0
]]></artwork>
</figure>
<t>
This can be parsed as:
</t>
<figure>
<artwork align="left"><![CDATA[
   ohhh:  1 1 6 0
   xid: dd112cdb
   secs:  0 0
   flags: 80 0
   ciaddr: 192.168.0.108
   yiaddr: 0.0.0.0
   siaddr: 0.0.0.0
   giaddr: 0.0.0.0
   chaddr: e89a8fb34bad 0 0 0 0 0 0 0 0 0 0
   sname:
   file:
   Message Type(53): 8
   Client Id(61):  1e89a8fb34bad
   Host name(12): icebox
   Vendor Class Id(60): MSFT 5.0
   Req. List(55): 1, 15, 3, 6, 44, 46, 47, 31, 33, 121, 249, 43, 252
]]></artwork>
</figure>
<t>
In this example, four fields
can be considered client identifiers: the "client IP address," the "channel address" (chaddr) which carries the link 
layer identifier, the "client ID," 
and the "host name." The vendor class identifier and the request list provide information about the type of device and
the software version that it uses, but do not directly identify the client.
</t> 
<t>
The DHCP message above was sent by a computer running Windows 7, and is fairly typical. Analysis of the published RFC 
shows a list of other options that may be used more rarely, but do also carry unique identifiers, such as the Client 
FQDN option and the UUID/GUID-based Client Identifier Option. 
</t>
<section title="Client IP address field">
<t>
Four bytes in the header of the DHCP messages carry the "Client IP address" (ciaddr) as defined in <xref target="RFC2131"/>. 
In DHCP, this field is used by the clients to indicate the address that they used previously, so that as much as
possible the server can allocate them the same address.  
</t>
<t>
There is very little privacy implication of sending this address in the DHCP messages, except in one case, on a
new connection to a new network. If the DHCP client somehow repeated the address used in a previous network attachment,
monitoring services might use the information to tie the two network locations. DHCP clients should ensure that
the field is cleared when they know that the network attachment has changed, and in particular of the link layer 
address is reset by the device's administrator.
</t>
</section>
<section title="Client hardware address">
<t>
Sixteen bytes in the header of the DHCP messages carry the "Client hardware address" (chaddr) as defined 
in <xref target="RFC2131"/>. The presence of this address is necessary for the proper operation of the
DHCP service.
</t>
<t>
Hardware addresses, called "link layer address" in many RFC, can be used to uniquely identify a device, especially
if they follow the IEEE 802 recommendations. These unique identifiers can be used by monitoring services to
track the location of the device and its user. The only plausible defense is to somehow reset the hardware
address to a random value before visiting an untrusted location. If the hardware address is reset to a new value, 
or randomized, the DHCP client should use the new randomized value in the DHCP messages.
</t>
</section>
<section title="Client Identifier Option">
<t>
The client identifier option is defined in <xref target="RFC2132"/> with option code 61. It is discussed in
details in <xref target="RFC4361"/>. The purpose of the client identifier option is to identify the client in
a manner independent of the link layer address. This is particularly useful if the DHCP server is expected to 
assign the same address to the client after a network attachment is swapped and the link layer address changes.
It is also useful when the same nodes issues requests through several interfaces, and expect the DHCP server
to provide consistent configuration data over multiple interfaces. 
</t>
<t>
The considerations for hardware independence and strong client identity have an adverse effect on the privacy 
of mobile clients, because the hardware independent unique identifier obviously enables very efficient tracking of the
client's movements.
</t>
<t>
The recommendations in <xref target="RFC4361"/> are very strong, stating for example that "DHCPv4
clients MUST NOT use client identifiers based solely on layer two addresses that are hard-wired to 
the layer two device (e.g., the ethernet MAC address). These strong recommendations are in fact a tradeoff 
between ease of management and privacy, and the tradeoff should depend on the circumstances. 
</t>
<t>
In contradiction to <xref target="RFC4361"/>, when privacy considerations trump management considerations, 
DHCP clients should use client identifiers based solely on the link layer address that will be used in the 
underlying connection. This will ensure that the DHCP client identifier does not leak any information that
is not already available to entities monitoring the network connection. It will also ensure that a 
strategy of randomizing the link layer address will not be nullified by DHCP options.
</t>
</section>
<section title="Host Name Option">
<t>
The Host Name option is defined in <xref target="RFC2132"/> with option code 12. Depending on implementations,
the option value can carry either a fully qualified domain name such as "node1984.example.com," or a simple
host name such as "node1984." The host name is commonly used by the DHCP server to identify the host, and
also to automatically update the address of the host in local name services.   
</t>
<t>
Fully qualified domain names are obviously unique identifiers, but even simple host names can provide a 
significant amount of information on the identity of the device. They 
are typically chosen to be unique in the context where the device is most often used. If that context is
wide enough, in a large company or in a big university, the host name will be a pretty good identifier of
the device. Monitoring services could use that information in conjunction with traffic analysis and quickly
derive the identity of the device's owner. 
</t>
<t>
When privacy considerations trump management considerations, DHCP clients should always send a non-qualified 
host name instead of a fully qualified domain name, and should consider randomizing the
host name value. A simple solution would be to set the host name value to an hexadecimal representation 
of the link layer address that will be used in the underlying connection.
</t>
</section>
<section title="Client FQDN Option">
<t>
The Client FQDN option is defined in <xref target="RFC4702"/> with option code 81. The option allows the 
DHCP clients to advertize to the DHCP their fully qualified domain name (FQDN) such as "mobile.example.com." This
would allow the DHCP server to update in the DNS the PTR record for the IP address allocated to the client. 
Depending on circumstances, either the DHCP client or the DHCP server could update in the DNS the A record
for the FQDN of the client.
</t>
<t>
Obviously, this option uniquely identifies the client, exposing it to the DHCP server or to anyone listening to
DHCP traffic. In fact, if the DNS record are updated, the location of the client becomes visible to anyone with 
DNS lookup capabilities. 
</t>
<t>
When privacy considerations trump management considerations, DHCP clients should not include the Client FQDN 
option in their DHCP requests.
</t> 
</section>

<section title="UUID/GUID-based Client Identifier Option">
<t>
The UUID/GUID-based Client Machine Identifier option is defined in <xref target="RFC4578"/>, with option code 97. 
The option is 
part of a set of options for Intel Preboot eXecution Environment (PXE). The purpose of the PXE system is to 
perform management functions on a device before its main OS is operational. The Client Machine Identifier carries 
a 16-octet Globally Unique Identifier (GUID), which uniquely identifies the device.
</t>
<t>
The PXE system is clearly designed for devices operating in a controlled environment, and its functions are 
not meant to be used by mobile nodes visiting untrusted networks. If only for privacy reasons, nodes visiting
untrusted networks should disable the PXE functions, and not send the corresponding options.
</t>
</section>

</section>

<section title="Security Considerations">
<t> 
This draft does not introduce new protocols. It does present a series of attacks on existing protocols, 
and proposes an assorted set of mitigations.
</t>
</section>

<section title="IANA Considerations" anchor="iana">
<t> 
This draft does not require any IANA action.
</t> 
</section>

<section title="Acknowledgments">
    <t> 
The inspiration for this draft came from discussions in the Perpass mailing list. 
    </t>
</section>
</middle>

<back>
<references title="Normative References">
    &rfc2026;
    &rfc2131;
    &rfc2132;
    &rfc4361;
    &rfc4578;
    &rfc4702;
</references>

<references title="Informative References">

    <reference anchor="CNBC" target="http://www.cbc.ca/news/politics/csec-used-airport-wi-fi-to-track-canadian-travellers-edward-snowden-documents-1.2517881">
        <front>
            <title>CBC News: CSEC used airport Wi-Fi to track Canadian travellers</title>
            <author initials="G" surname="Weston" fullname="Greg Weston" />
            <author initials="G" surname="Greenwald" fullname="Glenn Greenwald" />
            <author initials="R" surname="Gallagher" fullname="Ryan Gallagher" />
            <date month="Jan" year="2014" />
            <abstract>
	    <t>
            Electronic snooping was part of a trial run for U.S. NSA and other foreign services
            </t>
            </abstract>  
        </front>
    </reference>


</references>  

</back>
</rfc>