--- 1/draft-ietf-dhc-anonymity-profile-03.txt 2015-10-02 10:15:00.288876275 -0700 +++ 2/draft-ietf-dhc-anonymity-profile-04.txt 2015-10-02 10:15:00.344877652 -0700 @@ -1,21 +1,21 @@ Network Working Group C. Huitema Internet-Draft Microsoft Intended status: Standards Track T. Mrugalski -Expires: March 4, 2016 ISC +Expires: April 4, 2016 ISC S. Krishnan Ericsson - September 1, 2015 + October 2, 2015 Anonymity profile for DHCP clients - draft-ietf-dhc-anonymity-profile-03.txt + draft-ietf-dhc-anonymity-profile-04.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 @@ -29,21 +29,21 @@ 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 March 4, 2016. + This Internet-Draft will expire on April 4, 2016. Copyright Notice Copyright (c) 2015 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 @@ -59,52 +59,53 @@ 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 2. Application domain . . . . . . . . . . . . . . . . . . . . . 3 2.1. MAC address Randomization hypotheses . . . . . . . . . . 4 2.2. MAC address Randomization and DHCP . . . . . . . . . . . 5 2.3. Radio fingerprinting . . . . . . . . . . . . . . . . . . 5 2.4. Operating system fingerprinting . . . . . . . . . . . . . 6 2.5. No anonymity profile identification . . . . . . . . . . . 6 2.6. Using the anonymity profiles . . . . . . . . . . . . . . 7 2.7. What about privacy for DHCP servers . . . . . . . . . . . 8 3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 - 3.1. Option encoding and avoiding fingerprinting . . . . . . . 9 + 3.1. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 9 3.2. Client IP address field . . . . . . . . . . . . . . . . . 9 3.3. Requested IP address option . . . . . . . . . . . . . . . 10 - 3.4. Client hardware address . . . . . . . . . . . . . . . . . 10 + 3.4. Client hardware address field . . . . . . . . . . . . . . 10 3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11 - 3.6. Parameter Request List . . . . . . . . . . . . . . . . . 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 . . . . . . . 14 + 4.1. Option encoding and avoiding fingerprinting . . . . . . . 15 4.2. Do not send Confirm messages, unless really sure where . 15 - 4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 16 + 4.5. Address assignment options . . . . . . . . . . . . . . . 17 4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17 - 4.6. Option Request Option . . . . . . . . . . . . . . . . . . 17 + 4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18 + 4.6. Option Request Option . . . . . . . . . . . . . . . . . . 18 4.6.1. Previous option values . . . . . . . . . . . . . . . 18 - 4.7. Authentication Option . . . . . . . . . . . . . . . . . . 18 - 4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 18 - 4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 18 + 4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19 + 4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 19 + 4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 19 5. Operational Considerations . . . . . . . . . . . . . . . . . 19 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 - 9. Changes from previous versions . . . . . . . . . . . . . . . 19 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 10.2. Informative References . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 9. Changes from previous versions . . . . . . . . . . . . . . . 20 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 10.2. Informative References . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 such @@ -212,22 +213,22 @@ the IP address remains constant, since it is tied to the DHCP identifier. Conversely, if the DHCP identifier changes but the link- layer address remains constant, the old and new identifiers and addresses can be correlated by listening to L2 traffic. The procedures documented in the following sections construct DHCP identifiers from the current link-layer address, automatically providing for this synchronization. The proposed anonymity profiles solve this synchronization issues by deriving most identifiers from the link-layer address, and generally - by making making sure that DHCP parameter values do not remain - constant after an address change. + by making sure that DHCP parameter values do not remain constant + after an address change. 2.3. Radio fingerprinting MAC address randomization solves the trivial monitoring problem in which someone just uses a Wi-Fi scanner and records the MAC addresses seen on the air. DHCP anonymity solves the more elaborated scenario in which someone monitor link-layer addresses and identities used in DHCP at the access point or DHCP server. But these are not the only ways to track a mobile device. @@ -309,21 +310,21 @@ care about privacy and servers do not object. We assume that the request for anonymity is materialized by the assignment of a randomized link-layer address to the network interface. Once that decision is made, the following guidelines will avoid leakage of identity in DHCP parameters or in assigned addresses. There may be rare situations where the clients want anonymity to attackers but not to their DHCP server. These clients should still use link-layer address randomization to hide from observers, and some form of encrypted communication to the DHCP server. This scenario is - not yet supported in this document. + out of scope for this document. To preserve anonymity, the clients need to not use stable values for the client identifiers. This is clearly a tradeoff, because a stable client identifier guarantees that the client will receive consistent parameters over time. An example is given in [RFC7618], where the client identifier is used to guarantee that the same client will always get the same combination of IP address and port range. Static clients benefit most from stable parameters, and can often be already identified by physical connection layer parameters. These static clients will normally not use the anonymity profile. Mobile clients, @@ -352,59 +353,67 @@ and [I-D.ietf-dhc-dhcpv6-privacy]. Mitigation of these issues is left to further study. 3. Anonymity profile for DHCPv4 Clients using the DHCPv4 anonymity profile limit the disclosure of information by controlling the header parameters and by limiting the number and values of options. The number of options depend on the specific DHCP message: - DISCOVER: The anonymized DISCOVER messages MUST contain the Message - Type, Client Identifier, and Parameter Request List options. It - SHOULD NOT contain any other option. + DHCPDISCOVER: The anonymized DHCPDISCOVER messages MUST contain the + Message Type, MAY contain the Client Identifier, and MAY contain + the Parameter Request List options. It SHOULD NOT contain any + other option. - REQUEST: The anonymized REQUEST messages SHOULD contain the Message - Type, Client Identifier, Requested IP address and Parameter - Request List options. If the message is in response to an OFFER, - it SHOULD contain the corresponding Server Identifier option. It - SHOULD NOT contain any other option. + DHCPREQUEST: The anonymized DHCPREQUEST messages MUST contain the + Message Type, MAY contain the Client Identifier, and MAY contain + the Parameter Request List options. If the message is in response + to a DHCPOFFER, it MUST contain the corresponding Server + Identifier option and the Requested IP address. If the message is + not in response to a DHCPOFFER, it MAY contain a Requested IP + address as explained in Section 3.3. It SHOULD NOT contain any + other option. - DECLINE: The anonymized DECLINE messages SHOULD contain the Message - Type, Client Identifier and Server Identifier options. + DHCPDECLINE: The anonymized DHCPDECLINE messages MUST contain the + Message Type, Server Identifier, and Requested IP address options, + and MAY contain the Client Identifier options. - RELEASE: The anonymized RELEASE messages SHOULD contain the Message - Type, Client Identifier and Server Identifier options. + DHCPRELEASE: The anonymized DHCPRELEASE messages MUST contain the + Message Type and Server Identifier options, and MAY contain the + Client Identifier option. - INFORM: The anonymized INFORM messages MUST contain the Message - Type, Client Identifier, and Parameter Request List options. It - SHOULD NOT contain any other option. + DHCPINFORM: The anonymized DHCPINFORM messages MUST contain the + Message Type, and MAY contain the Client Identifier and Parameter + Request List options. It SHOULD NOT contain any other option. Header fields and option values SHOULD be set in accordance with the DHCP specification, but some header fields and option values SHOULD be constructed per the following guidelines. - The inclusion of HostName and FQDN options in DISCOVER, REQUEST or - INFORM messages is discussed in Section 3.7 and Section 3.8. + The inclusion of HostName and FQDN options in DHCPDISCOVER, + DHCPREQUEST or DHCPINFORM messages is discussed in Section 3.7 and + Section 3.8. -3.1. Option encoding and avoiding fingerprinting +3.1. Avoiding fingerprinting There are many choices for implementing DHCPv4 messages. Clients can choose to transmit a specific set of options, pick particular encoding for these options, and transmit options in different orders. 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. + The following sections provide guidance on the encoding of options + and fields within the packets. 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. The client willing to protect its privacy SHOULD limit the subset of options sent in messages to the subset listed in the following sections. The client willing to protect its privacy SHOULD randomize options order before sending any DHCPv4 message. If this random ordering cannot be implemented, the client MAY arrange options by increasing order of option codes. @@ -440,30 +449,31 @@ regain the same IP address that was used in a previous connection. Doing so entails the risk of disclosing an IP address used by the client at a previous location, or with a different link-layer address. When using the anonymity profile, clients SHOULD NOT use the Requested IP address option in DHCPDISCOVER messages. They MUST use the option when mandated by the DHCP protocol, for example in DHCPREQUEST messages. - There are scenarios in which a client connects to a network when a - lease is still valid. In that state, the client that is concerned - with privacy SHOULD perform a complete four way handshake starting - with DHCPDISCOVER to obtain a new address lease. If the client can + There are scenarios in which a client connecting to a network + remembers previously allocated address, i.e. is in the INIT-REBOOT + state. In that state, the client that is concerned with privacy + SHOULD perform a complete four way handshake starting with + DHCPDISCOVER to obtain a new address lease. If the client can ascertain that this is exactly the same network to which it was previously connected, and if the link layer address did not change, the client MAY issue a DHCPREQUEST to try reclaim the current address. -3.4. Client hardware address +3.4. Client hardware address field 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 RFCs, 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. @@ -508,21 +518,21 @@ connection. It will also ensure that a strategy of randomizing the link layer address will not be nullified by DHCP options. There are usages of DHCP where the underlying connection is a point to point link, in which case there is no link layer address available to construct a non-revealing identifier. If anonymity is desired in such networks, the client SHOULD pick a random identifier that is unique to the current link, using for example a combination of a local secret and an identifier of the connection. -3.6. Parameter Request List +3.6. Parameter Request List Option The Parameter Request List (PRL) option is defined in [RFC2132] with option code 61. It list the parameters requested from the server by the client. Different implementations request different parameters.[RFC2132] specifies that "the client MAY list the options in order of preference." It practice, this means that different client implementations will request different parameters, in different orders. The choice of option numbers and the specific ordering of option @@ -745,70 +755,80 @@ When using the anonymity profile, DHCPv6 clients SHOULD use the Server Identifier Option (code 2) as specified in [RFC3315]. Clients MUST only include server identifier values that were received with the current link-layer address, because reuse of old values discloses information that can be used to identify the client. 4.5. Address assignment options When using the anonymity profile, DHCPv6 clients might have to use SOLICIT or REQUEST messages to obtain IPv6 addresses through the DHCP - server. The clients SHOULD only use the options necessary to perform - the requested DHCPv6 transactions, such as Identity Association for - Non-temporary Addresses Option (code 3) or Identity Association for - Temporary Addresses Option (code 4). + server. Clients interested in privacy SHOULD request addresses using + 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. + + 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 + 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. - The interaction between prefix delegation and anonymity require - further study. For now, the simple solution is to avoid using prefix - delegation when striving for anonymity. When using the anonymity - profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of - address assignment. - 4.5.1. Obtain temporary addresses - [RFC3315] defines a special container (IA_TA) for requesting + [RFC3315] defines a special container (IA_TA, code 4) for requesting temporary addresses. This is a good mechanism in principle, but there are a number of issues associated with it. First, this is not a widely used feature, so clients depending solely on temporary addresses may lock themselves out of service. Secondly, [RFC3315] does not specify any lifetime or lease length for temporary addresses. Therefore support for renewing temporary addresses may vary between client implementations, including not being supported at all. Finally, by requesting temporary addresses a client reveals its desire for privacy and potentially risks countermeasures as described in Section 2.5. - Clients interested in their privacy SHOULD NOT use IA_TA. They - should simply send an IA_NA with a randomized IAID. This, along with - the mitigation technique discussed in Section 4.4, will ensure that a - client will get a new address that can be renewed and can be used as - long as needed. To get a new address, it can send Request message - with a new randomized IAID before releasing the other one. This will - cause the server to assign a new address, as it still has a valid - lease for the old IAID value. Once a new address is assigned, the - address obtained using the older IAID value can be released safely, - using the Release message or it may simply be allowed to time out. + Because of these Clients interested in their privacy SHOULD NOT use + IA_TA. - This solution may not work if the server enforces specific policies, - e.g. only one address per client. If client does not succeed in - receiving a second address using a new IAID, it may release the first - one (using the old IAID) and then retry asking for a new address. + The addresses obtained according to Section 4.5 are temporary in + nature, and will be discarded when the link layer address is changed. + They thus meet most of the use cases of the temporary addresses + defined in [RFC4941]. Clients interested in their privacy should not + publish their IPv6 addresses in the DNS or otherwise associate them + with name services, and thus do not normally need two classes of + addresses, one public, one temporary. - From the Operating System perspective, addresses obtained using this - technique SHOULD be treated as temporary as specified in [RFC4941]. + The use of mechanisms to allocate several IPv6 addresses to a client + while preserving privacy is for further study. + +4.5.2. Prefix delegation + + The interaction between prefix delegation and anonymity require + further study. For now, the simple solution is to avoid using prefix + delegation when striving for anonymity. When using the anonymity + profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of + address assignment. 4.6. Option Request Option The Option Request Option (ORO) is defined in [RFC3315] with option code 6. It specifies the options that the client is requesting from the server. The choice of requested options and the order of encoding of these options in the ORO can be used to fingerprint the client. The client willing to protect its privacy SHOULD only request a @@ -950,20 +970,31 @@ strict ordering. 7. Changed the requirement in Section 4.6 to allow "increasing order of option codes" as an alternative to "randomized order of options". 8. In Section 4.5.1 revised the language stating lack of support for renewing temporary addresses, as RFC 3315 does in fact specify a mechanism for doing so. + Changes from draft-03 to draft-04 address comments received during + 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. + 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. @@ -1026,22 +1057,22 @@ [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. [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-07 (work - in progress), June 2015. + 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. [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.