idnits 2.17.1 draft-iesg-serno-privacy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 91: '...ed over the global Internet SHOULD NOT...' RFC 2119 keyword, line 94: '...numbers, SHOULD define a means to keep...' RFC 2119 keyword, line 98: '...e serial numbers SHOULD provide users ...' RFC 2119 keyword, line 107: '...ol elements, and MUST NOT depend on th...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (26 January 1999) is 9219 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-1971' is mentioned on line 47, but not defined ** Obsolete undefined reference: RFC 1971 (Obsoleted by RFC 2462) == Missing Reference: 'RFC-YYYY' is mentioned on line 49, but not defined == Missing Reference: 'DHCPv6' is mentioned on line 102, but not defined == Unused Reference: 'IPv6-ATM' is defined on line 131, but no explicit reference was found in the text == Unused Reference: 'IPv6-SAA' is defined on line 135, but no explicit reference was found in the text == Unused Reference: 'WebDAV' is defined on line 150, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1971 (ref. 'IPv6-SAA') (Obsoleted by RFC 2462) == Outdated reference: A later version (-09) exists of draft-iab-nat-implications-02 ** Downref: Normative reference to an Informational draft: draft-iab-nat-implications (ref. 'NAT-ARCH1') -- Possible downref: Normative reference to a draft: ref. 'NAT-ARCH2' -- Possible downref: Non-RFC (?) normative reference: ref. 'UUIDs' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith Moore, ed. 2 Internet-Draft University of Tennessee 3 26 January 1999 4 Expires: 26 July 1999 6 Privacy Considerations for the Use of Hardware Serial Numbers 7 in End-to-End Network Protocols 9 draft-iesg-serno-privacy-00.txt 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents at 18 any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 24 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 25 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 This memo describes privacy risks associated with the use of 30 hardware serial numbers in network protocols, and some countermeasures 31 which can ameliorate those risks. 33 1. Introduction 35 Some network protocols use of hardware serial numbers, or 36 quantities derived from hardware serial numbers, as protocol elements. 37 Such numbers are finding increasing use in network protocols to form a 38 globally-unique identifier, either for the host itself, or for some 39 other purpose. 41 Examples of hardware serial numbers include 48-bit IEEE 802 Media 42 Access Control (MAC) addresses, 64-bit Extended Unique Identifier 43 (EUI-64) addresses, and the serial numbers which Intel Corporation has 44 proposed to include in some of its future CPU products. Some protocols 45 which use components based on hardware serial numbers are IPv6 (when 46 global addresses are obtained using Stateless Address Autoconfiguration 47 [RFC-1971]), IPv6 over ATM [IPv6/ATM] (when the Interface Tokens are 48 derived from 48-bit MAC addresses, EUI-64 values, or AESA values), and 49 WebDAV [RFC-YYYY] (which use UUIDs/GUIDs [UUIDs] which may be generated 50 from 48-bit MAC addresses). 52 Use of protocols that directly or indirectly expose hardware serial 53 numbers may compromise the privacy of a user or group of users. This 54 memo attempts to document known risks of exposing such information, and 55 countermeasures which might ameliorate those risks. 57 2. Risks of Exposing Hardware Serial Numbers 59 When a hardware serial number is associated with a particular host, 60 the number may be used to track network-based activity of that host. 61 Such tracking may be done by communication among the parties with which 62 the host communicates, or by eavesdroppers who can observe the host's 63 traffic. When the hardware serial number appears in an IPv6 address, 64 the information may be available to eavesdroppers even when the higher 65 level traffic is encrypted via IPSEC or TLS/SSL. In higher level 66 protocols, hardware serial numbers might be transmitted through 67 firewalls. 69 In many cases it is feasible for an observer to combine hardware 70 serial numbers with information which is visible either to the host's 71 communications peers, or to an eavesdropper (if the transmission is 72 unencrypted). For example, if a mobile host (e.g. laptop) were used to 73 access the net from several different locations, an eavesdropper would 74 be able to track the movement of that mobile host (and probably also its 75 human user) from place to place, even if the communications were 76 encrypted. 78 Certain bits of a hardware serial numbers are usually reserved to 79 identify the vendor of the hardware. Hardware serial numbers can 80 therefore leak information about the kind of computer hardware which is 81 being used, and of the different types of computers in use by a 82 particular group. 84 Some software products themselves emit serial numbers or other 85 registration information. If such software products are used on a host 86 that exposes its hardware serial number, an eavesdropper can determine 87 which copies of the software are running on a which hosts. 89 3. Recommendations on the Use of Hardware Serial Numbers 91 Protocols intended to be used over the global Internet SHOULD NOT 92 depend on the inclusion of hardware serial numbers. Protocols intended 93 to be used only in a local IP-based network, which use hardware serial 94 numbers, SHOULD define a means to keep those serial numbers from 95 escaping into the global Internet. 97 Implementations of protocols which use protocol elements derived 98 from hardware serial numbers SHOULD provide users with the ability to 99 either omit those elements entirely, or select an alternative means of 100 deriving those protocol elements. For instance, to avoid exposure, a 101 user might prefer to set the IPv6 address via manual configuration or 102 DHCPv6 [DHCPv6] rather than by using stateless autoconfiguration. 104 Protocol elements that contain hardware serial numbers should be 105 considered opaque to any applications that use them. Applications 106 SHOULD NOT attempt to interpret the hardware serial number portion of 107 such protocol elements, and MUST NOT depend on the hardware serial 108 numbers for proper operation. 110 4. Countermeasures 112 Countermeasures should be evaluated in relation to risk. For 113 instance, there is little additional risk in exposing the hardware 114 address of a single stationary host that is assigned a static IP 115 address. 117 Depending on the environment, there may be one or more means of 118 instructing an operating system or application to use a different serial 119 number in various protocols. For instance, it may be possible to set 120 the MAC address of an ethernet card to some value other than the 121 default. 123 In some environments, it may be possible to use network address 124 translators (NATs), firewalls, or proxies to hide use of particular 125 hosts, or make substitutions for protocol elements that contain hardware 126 serial numbers. However, such solutions have severe limitations which 127 are beyond the scope of this memo. [NAT-ARCH1], [NAT-ARCH2]. 129 References 131 [IPv6-ATM] Greenville Arimtage, Peter Schulter, Markus Jork. IPv6 over 132 ATM Networks. Internet-draft draft-ietf-ion-ipv6-atm-03.txt, Octo- 133 ber 17, 1998. (work in progress) 135 [IPv6-SAA] S. Thomson, T. Narten. IPv6 Stateless Address Autoconfigura- 136 tion. RFC 1971, August 1996. 138 [NAT-ARCH1] T. Hain. Architectural Implications of NAT. Internet-draft 139 draft-iab-nat-implications-02.txt, October 1998. (work in 140 progress) 142 [NAT-ARCH2] Yakov Rekhter. Implications of NATs on the TCP/IP architec- 143 ture. Internet-draft draft-ietf-nat-arch-implications-00.txt, 144 August 1998. (work in progress) 146 [UUIDs] ISO (International Organization for Standardization). Informa- 147 tion technology - Open Systems Interconnection - Remote Procedure 148 Call (RPC). ISO/IEC 11578:1996. 150 [WebDAV] Y. Y. Goland, E. J. Whitehead, A. Faizi, S. R. Carter, D. 151 Jensen. HTTP Extensions for Distributed Authoring -- WebDAV. 152 Internet-draft draft-ietf-webdav-protocol-10.txt, November 16, 153 1998. (work in progress, approved by IESG for publication as an 154 RFC)