--- 1/draft-ietf-dhc-anonymity-profile-01.txt 2015-08-20 10:14:59.003146778 -0700 +++ 2/draft-ietf-dhc-anonymity-profile-02.txt 2015-08-20 10:14:59.047147838 -0700 @@ -1,21 +1,21 @@ Network Working Group C. Huitema Internet-Draft Microsoft Updates: 4361 (if approved) T. Mrugalski Intended status: Standards Track ISC -Expires: January 1, 2016 S. Krishnan +Expires: February 21, 2016 S. Krishnan Ericsson - June 30, 2015 + August 20, 2015 Anonymity profile for DHCP clients - draft-ietf-dhc-anonymity-profile-01.txt + draft-ietf-dhc-anonymity-profile-02.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 January 1, 2016. + This Internet-Draft will expire on February 21, 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 @@ -57,52 +57,52 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 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 + 2.7. What about privacy for DHCP servers . . . . . . . . . . . 7 3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 3.1. Client IP address field . . . . . . . . . . . . . . . . . 9 3.2. Requested IP address option . . . . . . . . . . . . . . . 9 - 3.3. Client hardware address . . . . . . . . . . . . . . . . . 9 + 3.3. Client hardware address . . . . . . . . . . . . . . . . . 10 3.4. Client Identifier Option . . . . . . . . . . . . . . . . 10 3.5. Host Name Option . . . . . . . . . . . . . . . . . . . . 11 - 3.6. Client FQDN Option . . . . . . . . . . . . . . . . . . . 11 + 3.6. Client FQDN Option . . . . . . . . . . . . . . . . . . . 12 3.7. UUID/GUID-based Client Identifier Option . . . . . . . . 12 - 3.8. User and Vendor Class DHCP options . . . . . . . . . . . 12 - 4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 12 - 4.1. Do not send Confirm messages, unless really sure where . 13 - 4.2. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 13 - 4.2.1. Anonymous Information-Request . . . . . . . . . . . . 14 - 4.3. Server Identifier Option . . . . . . . . . . . . . . . . 14 + 3.8. User and Vendor Class DHCP options . . . . . . . . . . . 13 + 4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 13 + 4.1. Do not send Confirm messages, unless really sure where . 14 + 4.2. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 14 + 4.2.1. Anonymous Information-Request . . . . . . . . . . . . 15 + 4.3. Server Identifier Option . . . . . . . . . . . . . . . . 15 4.4. Address assignment options . . . . . . . . . . . . . . . 15 - 4.4.1. Obtain temporary addresses . . . . . . . . . . . . . 15 + 4.4.1. Obtain temporary addresses . . . . . . . . . . . . . 16 4.5. Option Request Option . . . . . . . . . . . . . . . . . . 16 - 4.5.1. Previous option values . . . . . . . . . . . . . . . 16 - 4.6. Authentication Option . . . . . . . . . . . . . . . . . . 16 + 4.5.1. Previous option values . . . . . . . . . . . . . . . 17 + 4.6. Authentication Option . . . . . . . . . . . . . . . . . . 17 4.7. User and Vendor Class DHCPv6 options . . . . . . . . . . 17 4.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 17 - 5. Operational Considerations . . . . . . . . . . . . . . . . . 17 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 5. Operational Considerations . . . . . . . . . . . . . . . . . 18 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Changes from previous versions . . . . . . . . . . . . . . . 18 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 10.2. Informative References . . . . . . . . . . . . . . . . . 19 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 10.2. Informative References . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 @@ -350,43 +350,46 @@ [I-D.ietf-dhc-dhcp-privacy] and [I-D.ietf-dhc-dhcpv6-privacy]. 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, Host name, and Parameter Request List - options. It SHOULD NOT contain any other option. + Type, Client Identifier, and Parameter Request List options. It + SHOULD NOT contain any other option. REQUEST: The anonymized REQUEST messages SHOULD contain the Message - Type, Client Identifier, Host name, 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. + 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. DECLINE: The anonymized DECLINE messages SHOULD contain the Message Type, Client Identifier and Server Identifier options. RELEASE: The anonymized RELEASE messages SHOULD contain the Message Type, Client Identifier and Server Identifier options. INFORM: The anonymized INFORM messages MUST contain the Message - Type, Client Id, Host name, and Parameter Request List options. - It SHOULD NOT contain any other option. + Type, Client Id, 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.5 and Section 3.6. + 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, when connecting to a different @@ -411,20 +414,29 @@ convenience, an attempt to 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 MAC 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 + 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.3. 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 RFCs, can be used to uniquely identify a device, especially if they follow the IEEE 802 recommendations. These unique identifiers can be used by @@ -460,20 +472,27 @@ tradeoff should depend on the circumstances. In contradiction to [RFC4361], When using the anonymity profile, DHCP clients MUST 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. + In general, clients that care about privacy SHOULD NOT use RFC4361 as + doing so would provide a stable identifier even when MAC + randomization is used. If RFC4361 needs to be used, it is + RECOMMENDED for the client to only use the DUID type DUID-LL (3) with + the link layer address of the interface on which the DHCP message is + sent. + 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.5. Host Name Option The Host Name option is defined in [RFC2132] with option code 12. @@ -486,31 +505,39 @@ 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 using the anonymity profile, DHCP clients SHOULD avoid sending - the host name option. If they chose to send the option, DHCP clients + When using the anonymity profile, DHCP clients SHOULD NOT send the + host name option. If they chose to send the option, DHCP clients MUST always send a non-qualified host name instead of a fully qualified domain name, and MUST obfuscate the host name value. - When obfuscating the host name, DHCP clients SHOULD construct a - randomized host name by computing a secure hash of a local secret and - of the link layer address that will be used in the underlying - connection, and then use as the name the hexadecimal representation - of the first 6 bytes of the hash. This procedure ensures that the - random name will not reveal the underlying link layer address. + There are many ways to obfuscate a host name. The construction rules + SOULD guarantee that a different host name is generated each time the + link-layer address changes and that the obfuscated host name will not + reveal the underlying link layer address. The construction SHOULD + generate names that are unique enough to minimize collisions in the + local link. Clients MAY use the following algorithm: compute a + secure hash of a local secret and of the link layer address that will + be used in the underlying connection, and then use the hexadecimal + representation of the first 6 bytes of the hash as the obfuscated + host name. + + There is a potential downside to having a specific name pattern for + hosts that require anonymity, as explained in Section 2.5. For this + reason, the above algorithm is just a suggestion. 3.6. Client FQDN Option The Client FQDN option is defined in [RFC4702] with option code 81. The option allows the DHCP clients to advertise to the DHCP server 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. @@ -680,48 +707,49 @@ 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.4.1. Obtain temporary addresses [RFC3315] defines a special container (IA_TA) 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 - widely used feature, so clients depending solely on temporary - addresses may lock themselves out of service. Secondly, [RFC3315] - does not specify any renewal mechanisms for temporary addresses. - Therefore support for renewing temporary addresses may vary between - server 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. + there are a number of issues associated with it. First of all, this + is not widely used feature. Thus clients cannot count on it to be + always available. Secondly, [RFC3315] does not specify any renewal + mechanisms for temporary addresses. Therefore the support for + renewing temporary addresses in server implementations usually varies + between poor and non-existent. Finally, a client reveals its desire + for privacy just by requesting temporary addresses, and potentially + risks countermeasures as described in Section 2.5. - Clients interested in their privacy SHOULD NOT use IA_TA. They + Clients interested in their privacy SHOULD NOT use the IA_TA. They should simply send an IA_NA with a randomized IAID. This, along with the mitigation technique discussed in Section 4.3, 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 + with a new randomized IAID before releasing the older 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. - - 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 an old IAID) and then retry asking for a new address. + address obtained using the older IAID value can be released safely or + be allowed to time out. From the Operating System perspective, addresses obtained using this - technique SHOULD be treated as temporary as specified in [RFC4941]. + technique SHOULD be treated as temporary addresses as specified in + [RFC4941]. + + Note that this solution may not work if the server enforces specific + policies such as providing only one address per client. If client + does not succeed in obtaining a second address using a new IAID, it + needs to release the first one (using an old IAID) and then retry + asking for a new address. 4.5. Option Request Option A DHCPv6 client may reveal other types of information, besides unique identifiers. There are many ways a DHCPv6 client can perform certain actions and the specifics can be used to fingerprint the client. This may not reveal the identity of a client, but may provide additional information, such as the device type, vendor type or OS type and in some cases specific version. @@ -773,26 +801,30 @@ the client. As explained in Section 3.6 they MAY use a local-only FQDN by combining a host name derived from the link layer address and a suffix advertised by the local DHCP server. 5. Operational Considerations The anonymity profile has the effect of hiding the client identity from the DHCP server. This is not always desirable. Some DHCP servers provide facilities like publishing names and addresses in the DNS, or ensuring that returning clients get reassigned the same - address. Implementers should be careful to only use the anonymity - profile when privacy trumps management considerations. + address. - Clients using the anonymity profile in general consume more - resources. For example when they change MAC address and request for - a new IP, the old one is still marked as leased by the server. + Clients using the anonymity profile may be consuming more resources. + For example when they change MAC address and request for a new IP, + the old one is still marked as leased by the server. + + Implementers SHOULD provide a way for clients to control when the + anonymity profile is used, and when standard behavior is preferred. + Implementers MAY implement this control by tying use of the anonymity + profile to that of link-layer address randomization. 6. Security Considerations The use of the anonymity profile does not change the security considerations of the DHCPv4 or DHCPv6 protocols. 7. IANA Considerations This draft does not require any IANA action. @@ -823,46 +855,52 @@ when roaming between access points on the same network. 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-00 (work in progress), March 2015. + 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, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC - 2131, March 1997. + 2131, DOI 10.17487/RFC2131, March 1997, + . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, March 1997. + Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, + . [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)", - RFC 3925, October 2004. + 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, February 2006. + 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, October 2006. + 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, October 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy @@ -873,28 +911,28 @@ [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-04 (work in progress), June + draft-ietf-6man-default-iids-05 (work in progress), July 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-03 (work + in progress), January 2015. [I-D.ietf-dhc-dhcp-privacy] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy considerations for DHCP", draft-ietf-dhc-dhcp-privacy-00 (work in progress), February 2015. [I-D.ietf-dhc-dhcpv6-privacy] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy considerations for DHCPv6", draft-ietf-dhc- dhcpv6-privacy-00 (work in progress), February 2015. @@ -907,30 +945,31 @@ [IEEE-OUI] IEEE, "Organizationally Unique Identifiers http://www.ieee.org/netstorage/standards/oui.txt", . [IETFMACRandom] Zuniga, JC., "MAC Privacy", November 2014, . - [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration - Protocol (DHCP) Options for the Intel Preboot eXecution - Environment (PXE)", RFC 4578, November 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, + . [WiFiRadioFingerprinting] Brik, V., Banerjee, S., Gruteser, M., and S. Oh, "Wireless Device Identification with Radiometric Signatures", - September 2008, - . + September 2008, . Authors' Addresses Christian Huitema Microsoft Redmond, WA 98052 U.S.A. Email: huitema@microsoft.com