[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                   Keith Moore, ed.
Internet-Draft                                   University of Tennessee
26 January 1999
Expires: 26 July 1999


     Privacy Considerations for the Use of Hardware Serial Numbers
                    in End-to-End Network Protocols

                    draft-iesg-serno-privacy-00.txt

     This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

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

     To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

     This memo describes privacy risks associated with the use of
hardware serial numbers in network protocols, and some countermeasures
which can ameliorate those risks.

1. Introduction

     Some network protocols use of hardware serial numbers, or
quantities derived from hardware serial numbers, as protocol elements.
Such numbers are finding increasing use in network protocols to form a
globally-unique identifier, either for the host itself, or for some
other purpose.

     Examples of hardware serial numbers include 48-bit IEEE 802 Media
Access Control (MAC) addresses, 64-bit Extended Unique Identifier
(EUI-64) addresses, and the serial numbers which Intel Corporation has
proposed to include in some of its future CPU products.  Some protocols
which use components based on hardware serial numbers are IPv6 (when
global addresses are obtained using Stateless Address Autoconfiguration
[RFC-1971]), IPv6 over ATM [IPv6/ATM] (when the Interface Tokens are



Moore                     Expires 26 July 1999                  [Page 1]

Hardware Serial Numbers      INTERNET-DRAFT              26 January 1999


derived from 48-bit MAC addresses, EUI-64 values, or AESA values), and
WebDAV [RFC-YYYY] (which use UUIDs/GUIDs [UUIDs] which may be generated
from 48-bit MAC addresses).

     Use of protocols that directly or indirectly expose hardware serial
numbers may compromise the privacy of a user or group of users.  This
memo attempts to document known risks of exposing such information, and
countermeasures which might ameliorate those risks.

2. Risks of Exposing Hardware Serial Numbers

     When a hardware serial number is associated with a particular host,
the number may be used to track network-based activity of that host.
Such tracking may be done by communication among the parties with which
the host communicates, or by eavesdroppers who can observe the host's
traffic.  When the hardware serial number appears in an IPv6 address,
the information may be available to eavesdroppers even when the higher
level traffic is encrypted via IPSEC or TLS/SSL.  In higher level
protocols, hardware serial numbers might be transmitted through
firewalls.

     In many cases it is feasible for an observer to combine hardware
serial numbers with information which is visible either to the host's
communications peers, or to an eavesdropper (if the transmission is
unencrypted).  For example, if a mobile host (e.g. laptop) were used to
access the net from several different locations, an eavesdropper would
be able to track the movement of that mobile host (and probably also its
human user) from place to place, even if the communications were
encrypted.

     Certain bits of a hardware serial numbers are usually reserved to
identify the vendor of the hardware.  Hardware serial numbers can
therefore leak information about the kind of computer hardware which is
being used, and of the different types of computers in use by a
particular group.

     Some software products themselves emit serial numbers or other
registration information.  If such software products are used on a host
that exposes its hardware serial number, an eavesdropper can determine
which copies of the software are running on a which hosts.

3. Recommendations on the Use of Hardware Serial Numbers

     Protocols intended to be used over the global Internet SHOULD NOT
depend on the inclusion of hardware serial numbers.  Protocols intended
to be used only in a local IP-based network, which use hardware serial
numbers, SHOULD define a means to keep those serial numbers from
escaping into the global Internet.



Moore                     Expires 26 July 1999                  [Page 2]

Hardware Serial Numbers      INTERNET-DRAFT              26 January 1999


     Implementations of protocols which use protocol elements derived
from hardware serial numbers SHOULD provide users with the ability to
either omit those elements entirely, or select an alternative means of
deriving those protocol elements.  For instance, to avoid exposure, a
user might prefer to set the IPv6 address via manual configuration or
DHCPv6 [DHCPv6] rather than by using stateless autoconfiguration.

     Protocol elements that contain hardware serial numbers should be
considered opaque to any applications that use them.  Applications
SHOULD NOT attempt to interpret the hardware serial number portion of
such protocol elements, and MUST NOT depend on the hardware serial
numbers for proper operation.

4. Countermeasures

     Countermeasures should be evaluated in relation to risk.  For
instance, there is little additional risk in exposing the hardware
address of a single stationary host that is assigned a static IP
address.

     Depending on the environment, there may be one or more means of
instructing an operating system or application to use a different serial
number in various protocols.  For instance, it may be possible to set
the MAC address of an ethernet card to some value other than the
default.

     In some environments, it may be possible to use network address
translators (NATs), firewalls, or proxies to hide use of particular
hosts, or make substitutions for protocol elements that contain hardware
serial numbers.  However, such solutions have severe limitations which
are beyond the scope of this memo. [NAT-ARCH1], [NAT-ARCH2].

References

[IPv6-ATM] Greenville Arimtage, Peter Schulter, Markus Jork.  IPv6 over
     ATM Networks.  Internet-draft draft-ietf-ion-ipv6-atm-03.txt, Octo-
     ber 17, 1998. (work in progress)

[IPv6-SAA] S. Thomson, T. Narten.  IPv6 Stateless Address Autoconfigura-
     tion.  RFC 1971, August 1996.

[NAT-ARCH1] T. Hain.  Architectural Implications of NAT.  Internet-draft
     draft-iab-nat-implications-02.txt, October 1998.  (work in
     progress)

[NAT-ARCH2] Yakov Rekhter.  Implications of NATs on the TCP/IP architec-
     ture.  Internet-draft draft-ietf-nat-arch-implications-00.txt,
     August 1998. (work in progress)



Moore                     Expires 26 July 1999                  [Page 3]

Hardware Serial Numbers      INTERNET-DRAFT              26 January 1999


[UUIDs] ISO (International Organization for Standardization).  Informa-
     tion technology - Open Systems Interconnection - Remote Procedure
     Call (RPC).  ISO/IEC 11578:1996.

[WebDAV] Y. Y. Goland, E. J. Whitehead, A. Faizi, S. R. Carter, D.
     Jensen.  HTTP Extensions for Distributed Authoring -- WebDAV.
     Internet-draft draft-ietf-webdav-protocol-10.txt, November 16,
     1998.  (work in progress, approved by IESG for publication as an
     RFC)










































Moore                     Expires 26 July 1999                  [Page 4]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/