--- 1/draft-ietf-dhc-anonymity-profile-04.txt 2016-01-13 17:15:28.300918917 -0800 +++ 2/draft-ietf-dhc-anonymity-profile-05.txt 2016-01-13 17:15:28.360920363 -0800 @@ -1,53 +1,52 @@ Network Working Group C. Huitema Internet-Draft Microsoft Intended status: Standards Track T. Mrugalski -Expires: April 4, 2016 ISC +Expires: July 16, 2016 ISC S. Krishnan Ericsson - October 2, 2015 + January 13, 2016 Anonymity profile for DHCP clients - draft-ietf-dhc-anonymity-profile-04.txt + draft-ietf-dhc-anonymity-profile-05.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. The anonymity profile is designed for clients that wish to remain anonymous to the visited network. The profile provides guidelines on the composition of DHCP or DHCPv6 requests, - designed to minimize disclosure of identifying information. This - draft updates RFC4361. + designed to minimize disclosure of identifying information. 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 April 4, 2016. + This Internet-Draft will expire on July 16, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 @@ -70,21 +69,21 @@ 3.2. Client IP address field . . . . . . . . . . . . . . . . . 9 3.3. Requested IP address option . . . . . . . . . . . . . . . 10 3.4. Client hardware address field . . . . . . . . . . . . . . 10 3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11 3.6. Parameter Request List Option . . . . . . . . . . . . . . 12 3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 12 3.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 13 3.9. UUID/GUID-based Client Identifier Option . . . . . . . . 13 3.10. User and Vendor Class DHCP options . . . . . . . . . . . 14 4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 14 - 4.1. Option encoding and avoiding fingerprinting . . . . . . . 15 + 4.1. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 15 4.2. Do not send Confirm messages, unless really sure where . 15 4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 16 4.3.1. Anonymous Information-Request . . . . . . . . . . . . 16 4.4. Server Identifier Option . . . . . . . . . . . . . . . . 16 4.5. Address assignment options . . . . . . . . . . . . . . . 17 4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17 4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18 4.6. Option Request Option . . . . . . . . . . . . . . . . . . 18 4.6.1. Previous option values . . . . . . . . . . . . . . . 18 4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19 @@ -644,36 +643,36 @@ In the stateless scenario, clients configure addresses using a combination of client managed identifiers and router-advertised prefixes, without involving the DHCPv6 services. Different ways of constructing these prefixes have different implications on privacy, which are discussed in [I-D.ietf-6man-default-iids] and [I-D.ietf-6man-ipv6-address-generation-privacy]. In the stateless scenario, clients use DHCPv6 to obtain network configuration parameters, through the INFORMATION-REQUEST message. - The choice between the stateful and stateless scenario depends on + The choice between the stateful and stateless scenarios depends on flag and prefix options published by the "Router Advertisement" messages of local routers, as specified in [RFC4861]. When these options enable stateless address configuration hosts using the anonymity profile SHOULD choose it over stateful address configuration, because stateless configuration requires fewer information disclosures than stateful configuration. When using the anonymity profile, DHCPv6 clients carefully select DHCPv6 options used in the various messages that they send. The list of options that are mandatory or optional for each message is specified in [RFC3315]. Some of these options have specific implications on anonymity. The following sections provide guidance on the choice of option values when using the anonymity profile. -4.1. Option encoding and avoiding fingerprinting +4.1. Avoiding fingerprinting There are many choices for implementing DHCPv6 messages. As explained in Section 3.1, these choices can be use to fingerprint the client. The following sections provide guidance on the encoding of options. However, this guidance alone may not be sufficient to prevent fingerprinting from revealing information, such as the device type, vendor type or OS type and in some cases specific version, or from revealing whether the client is using the anonymity profile. @@ -766,25 +765,25 @@ the Identity Association for Non-temporary Addresses Option (IA_NA, code 3). The IA_NA option includes an IAID parameter that identifies a unique identity association for the interface for which the Address is requested. Clients interested in protecting their privacy MUST ensure that the IAID does not enable client identification. They also need to conform to the requirement of [RFC3315] that the IAID for that IA MUST be consistent across restarts of the DHCP client. We interpret that as requiring that the IAID MUST be constant for the - association, as long as the link layer Address remains constant. + association, as long as the link layer address remains constant. Clients MAY meet the privacy, uniqueness and stability requirement of - the IAID using by constructing it as the combination of one byte - encoding the interface number in the system, and three bytes of the + the IAID by constructing it as the combination of one byte encoding + the interface number in the system, and the first three bytes of the link layer address. The clients MAY use the IA Address Option (code 5) but need to balance the potential advantage of "address continuity" versus the potential risk of "previous address disclosure." A potential solution is to remove all stored addresses when a link-layer address changes, and to only use the IA Address option with addresses that have been explicitly assigned through the current link-layer address. 4.5.1. Obtain temporary addresses @@ -981,69 +980,61 @@ Working Group Last Call: 1. In Section 3, tightened the normative language and the use of message codes. 2. In Section 3.3, clarified the reference to the INIT-REBOOT scenario. 3. Revised the writing of Section 4.5 for greater clarity. + Changes from draft-04 to draft-05 address comments received after + Working Group Last Call: + + 1. Changed the title of Section 4.1 to "Avoiding fingerprinting" to + align with Section 3.1. + + 2. Fixed editing nits in Section 4.5, and added specification that + the IAID is composed of the interface identifier and the first + three bytes of the HW address. This matches the implementation + in Windows 10, and insures that variations will not be used to + fingerprint the client software. + + 3. Dropping "This draft updates RFC4361" from the Abstract, since + this draft does not actually update RFC4361. + + 4. Pruned the list of normative references. + 10. References 10.1. Normative References - [I-D.ietf-dhc-rfc3315bis] - Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., - Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host - Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf- - dhc-rfc3315bis-01 (work in progress), July 2015. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . - [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, - . - [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . - [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for - Dynamic Host Configuration Protocol version 4 (DHCPv4)", - RFC 3925, DOI 10.17487/RFC3925, October 2004, - . - - [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client - Identifiers for Dynamic Host Configuration Protocol - Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361, - February 2006, . - [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option", RFC 4702, DOI 10.17487/RFC4702, October 2006, . - [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for - IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) - Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, - . - [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . @@ -1051,49 +1042,74 @@ [CNBC] Weston, G., Greenwald, G., and R. Gallagher, "CBC News: CSEC used airport Wi-Fi to track Canadian travellers", Jan 2014, . [I-D.ietf-6man-default-iids] Gont, F., Cooper, A., Thaler, D., and S. LIU, "Recommendation on Stable IPv6 Interface Identifiers", - draft-ietf-6man-default-iids-07 (work in progress), August - 2015. + draft-ietf-6man-default-iids-08 (work in progress), + October 2015. [I-D.ietf-6man-ipv6-address-generation-privacy] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", draft-ietf-6man-ipv6-address-generation-privacy-08 (work in progress), September 2015. [I-D.ietf-dhc-dhcp-privacy] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy - considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-01 - (work in progress), August 2015. + considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-02 + (work in progress), December 2015. [I-D.ietf-dhc-dhcpv6-privacy] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy considerations for DHCPv6", draft-ietf-dhc- - dhcpv6-privacy-01 (work in progress), August 2015. + dhcpv6-privacy-02 (work in progress), December 2015. + + [I-D.ietf-dhc-rfc3315bis] + Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., + Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host + Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf- + dhc-rfc3315bis-02 (work in progress), October 2015. [IETFMACRandom] Zuniga, JC., "MAC Privacy", November 2014, . + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, + . + + [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for + Dynamic Host Configuration Protocol version 4 (DHCPv4)", + RFC 3925, DOI 10.17487/RFC3925, October 2004, + . + + [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client + Identifiers for Dynamic Host Configuration Protocol + Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361, + February 2006, . + [RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", RFC 4578, DOI 10.17487/RFC4578, November 2006, . + [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for + IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) + Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, + . + [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, DOI 10.17487/RFC6355, August 2011, . [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", RFC 7618, DOI 10.17487/RFC7618, August 2015, .