Internet DRAFT - draft-huitema-perpass-dhcp-identifiers

draft-huitema-perpass-dhcp-identifiers






Network Working Group                                         C. Huitema
Internet-Draft
Intended status: Informational                            March 13, 2014
Expires: September 14, 2014


       Unique Identifiers in DHCP options enable device tracking
             draft-huitema-perpass-dhcp-identifiers-00.txt

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 14, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Huitema                Expires September 14, 2014               [Page 1]

Internet-Draft         Unique Identifiers in DHCP             March 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Listening to DHCP traffic is easy . . . . . . . . . . . . . .   3
   3.  Managing Identifiers in DHCP Client Options . . . . . . . . .   3
     3.1.  Client IP address field . . . . . . . . . . . . . . . . .   5
     3.2.  Client hardware address . . . . . . . . . . . . . . . . .   5
     3.3.  Client Identifier Option  . . . . . . . . . . . . . . . .   5
     3.4.  Host Name Option  . . . . . . . . . . . . . . . . . . . .   6
     3.5.  Client FQDN Option  . . . . . . . . . . . . . . . . . . .   7
     3.6.  UUID/GUID-based Client Identifier Option  . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Reports surfaced recently of systems that would monitor the wireless
   connections of passengers at Canadian airports [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.

   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.

1.1.  Requirements

   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 [RFC2026].






Huitema                Expires September 14, 2014               [Page 2]

Internet-Draft         Unique Identifiers in DHCP             March 2014


2.  Listening to DHCP traffic is easy

   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.

   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.

   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.

   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.

   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.

3.  Managing Identifiers in DHCP Client Options

   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.





Huitema                Expires September 14, 2014               [Page 3]

Internet-Draft         Unique Identifiers in DHCP             March 2014


   Here is an example of DHCP message sent by a client, as captured by a
   network monitor.

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

   This can be parsed as:

      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

   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.



Huitema                Expires September 14, 2014               [Page 4]

Internet-Draft         Unique Identifiers in DHCP             March 2014


   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.

3.1.  Client IP address field

   Four bytes in the header of the DHCP messages carry the "Client IP
   address" (ciaddr) as defined in [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.

   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.

3.2.  Client hardware address

   Sixteen bytes in the header of the DHCP messages carry the "Client
   hardware address" (chaddr) as defined in [RFC2131].  The presence of
   this address is necessary for the proper operation of the DHCP
   service.

   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.

3.3.  Client Identifier Option

   The client identifier option is defined in [RFC2132] with option code
   61.  It is discussed in details in [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



Huitema                Expires September 14, 2014               [Page 5]

Internet-Draft         Unique Identifiers in DHCP             March 2014


   requests through several interfaces, and expect the DHCP server to
   provide consistent configuration data over multiple interfaces.

   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.

   The recommendations in [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.

   In contradiction to [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.

3.4.  Host Name Option

   The Host Name option is defined in [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.

   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.

   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




Huitema                Expires September 14, 2014               [Page 6]

Internet-Draft         Unique Identifiers in DHCP             March 2014


   an hexadecimal representation of the link layer address that will be
   used in the underlying connection.

3.5.  Client FQDN Option

   The Client FQDN option is defined in [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.

   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.

   When privacy considerations trump management considerations, DHCP
   clients should not include the Client FQDN option in their DHCP
   requests.

3.6.  UUID/GUID-based Client Identifier Option

   The UUID/GUID-based Client Machine Identifier option is defined in
   [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.

   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.

4.  Security Considerations

   This draft does not introduce new protocols.  It does present a
   series of attacks on existing protocols, and proposes an assorted set
   of mitigations.








Huitema                Expires September 14, 2014               [Page 7]

Internet-Draft         Unique Identifiers in DHCP             March 2014


5.  IANA Considerations

   This draft does not require any IANA action.

6.  Acknowledgments

   The inspiration for this draft came from discussions in the Perpass
   mailing list.

7.  References

7.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC4361]  Lemon, T. and B. Sommerfeld, "Node-specific Client
              Identifiers for Dynamic Host Configuration Protocol
              Version Four (DHCPv4)", RFC 4361, February 2006.

   [RFC4578]  Johnston, M. and S. Venaas, "Dynamic Host Configuration
              Protocol (DHCP) Options for the Intel Preboot eXecution
              Environment (PXE)", RFC 4578, November 2006.

   [RFC4702]  Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
              Configuration Protocol (DHCP) Client Fully Qualified
              Domain Name (FQDN) Option", RFC 4702, October 2006.

7.2.  Informative References

   [CNBC]     Weston, G., Greenwald, G., and R. Gallagher, "CBC News:
              CSEC used airport Wi-Fi to track Canadian travellers", Jan
              2014, <http://www.cbc.ca/news/politics/csec-used-airport-
              wi-fi-to-track-canadian-travellers-edward-snowden-
              documents-1.2517881>.

Author's Address








Huitema                Expires September 14, 2014               [Page 8]

Internet-Draft         Unique Identifiers in DHCP             March 2014


   Christian Huitema
   Clyde Hill, WA  98004
   U.S.A.

   Email: huitema@huitema.net














































Huitema                Expires September 14, 2014               [Page 9]