Uniform Resource Names for Device IdentifiersEricssonJorvas02420Finlandjari.arkko@piuha.netCisco170 West Tasman DriveSan JoseCA95134USA+1 408 421-9990fluffy@cisco.com
Sensinode
Kidekuja 2Vuokatti88600FINLAND+358407796297zach@sensinode.comURNdevice identifierIMEI1-wireMAC addressEUI-48EUI-64This memo describes a new Uniform Resource Name (URN) namespace for
hardware device identifiers. A general representation of device
identity can be useful in many applications, such as in sensor data
streams and storage, or equipment inventories. A URN-based
representation can be easily passed along in any application that
needs the information.This memo describes a new Uniform Resource Name (URN)
namespace for
hardware device identifiers. A general representation of device
identity can be useful in many applications, such as in sensor data
streams and storage, or equipment inventories
,
,
. A URN-based
representation can be easily passed along in any application that
needs the information, as it fits in protocols mechanisms that are
designed to carry URNs , , . Finally, URNs
can also be easily carried and stored in formats such as XML or JSON . Using URNs in
these formats is often preferable as they are universally recognized,
self-describing, and therefore avoid the need for agreeing to
interpret an octet string as a specific form of a MAC address, for
instance.This memo defines identity URN types for situations where no such
convenient type already exist. For instance, defines International Mobile
station Equipment Identity (IMEI) identifiers for use with 3GPP
cellular systems. Similarly, defines Mobile Equipment
Identity (MEID) identifiers for use with 3GPP2 cellular systems. Those
URN types should be employed when such identities are transported;
this memo does not redefine these identifiers in any way.Universally Unique IDentifier (UUID) URNs
are another alternative way for representing device identifiers, and
already support MAC addresses as one of type of an
identifier. However, UUIDs can be inconvenient in environments where
it is important that the identifiers are as simple as possible and
where additional requirements on stable storage, real-time clocks, and
identifier length can be prohibitive. UUID-based identifiers are
recommended for all general purpose uses when MAC addresses are
available as identifiers. The device URN defined in this memo is
recommended for constrained environments.Future device identifier types can extend the device device URN
type defined here, or define their own URNs.The rest of this memo is organized as follows. defines the "DEV" URN type, and defines subtypes for IEEE MAC-48, EUI-48 and EUI-64
addresses, 1-wire device identifiers, and cryptographically defined
identifiers. gives examples.
discusses the security considerations of the new URN type. Finally,
specifies the IANA registration for the new URN
type and sets requirements for subtype allocations within this
type.In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in .Namespace ID: "dev" requestedRegistration Information: This is the first registration of this namespace, 2011-08-27.Registration version number: 1Registration date: 2011-08-27Declared registrant of the namespace: IETF and the CORE working
group. Should the working group cease to exist, discussion should be
directed to the general IETF discussion forums or the IESG.Declaration of syntactic structure: The identifier is expressed in
ASCII (UTF-8) characters and has a hierarchical structure as
follows:The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA rules
defined in , which are not repeated here.The device identity namespace includes three subtypes, and more may be
defined in the future as specified in .The optional components following the hexstring are strings depicting individual aspects of
a device. The specific strings and their semantics are up to the designers of the device, but
could be used to refer to specific interfaces or functions within the device.Relevant ancillary documentation: See .Identifier uniqueness considerations: Device identifiers are
generally expected to be unique, barring the accidental issue of
multiple devices with the same identifiers.Identifier persistence considerations: This URN type SHOULD only be
used for persistent identifiers, such as hardware-based identifiers or
cryptographic identifiers based on keys intended for long-term
usage.Process of identifier assignment: The process for identifier
assignment is dependent on the used subtype, and documented in the
specific subsection under .Process for identifier resolution: The device identities are not
expected to be globally resolvable. No identity resolution system is
expected. Systems may perform local matching of identities to previously
seen identities or configured information, however.Rules for Lexical Equivalence: The lexical equivalence of the DEV
URN is defined as an exact, but not case-sensitive, string match.
While uppercase letters are accepted, all systems that construct or
display DEV URNs MUST employ lower case letters. This is necessary to
ensure that searches, processing rules, and other potentially case
sensitive tools have uniformly lower-case identifiers to look at.Conformance with URN Syntax: The string representation of the device
identity URN and of the MEID sub namespace is fully compatible with
the URN syntax.Validation Mechanism: Specific subtypes may be validated through mechanisms discussed
in .Scope: DEV URN is global in scope.DEV URNs of the "mac" subtype are based on the EUI-64 identifier
derived from a device with a built-in
64-bit EUI-64. The EUI-64 is formed from 24 or 36 bits of organization
identifier followed by 40 or 28 bits of device-specific extension
identifier assigned by that organization.In the DEV URN "mac" subtype the hexstring is simply the full
EUI-64 identifier represented as a hexadecimal string. It is always
exactly 16 characters long.MAC-48 and EUI-48 identifiers are also supported by the same DEV
URN subtype. To convert a MAC-48 address to an EUI-64 identifier, The
OUI of the Ethernet address (the first three octets) becomes the
organization identifier of the EUI-64 (the first three octets). The
fourth and fifth octets of the EUI are set to the fixed value FFFF
hexadecimal. The last three octets of the Ethernet address become the
last three octets of the EUI-64. The same process is used to convert
an EUI-48 identifier, but the fixed value FFFE is used instead.Identifier assignment for all of these identifiers rests within the
IEEE.The 1-Wire* system is a device communications bus system designed by
Dallas Semiconductor Corporation. 1-Wire devices are identified by a
64-bit identifier that consists of 8 byte family code, 48 bit
identifier unique within a family, and 8 bit CRC code .
*) 1-Wire is a registered trademark.In DEV URNs with the "ow" subtype the hexstring is a representation
of the full 64 bit identifier as a hexadecimal string. It is always
exactly 16 characters long. Note that the last two characters
represent the 8-bit CRC code. Implementations MAY check the validity
of this code.Family code and identifier assignment for all 1-wire devices rests
with the manufacturers.DEV URNs with the "cgi" subtype represent cryptographically
identified devices. These identifiers are variable length but the
hexstring MUST be at least 16 characters long (128 bits). The hexstring
MUST have an even number of characters.This memo does not define the construction of the cryptographic
identifiers or the algorithms used in the construction, as these are
up to the specific implementations. It should be noted, however, that
the use of cryptographic identifiers for anything else as tokens of
identification will require the communicating parties to agree on how
they are used, and what algorithms and methods are used to verify an
ownership claim, for instance. These are outside the scope of this
draft, however. The authors observe that the use of plain identifiers
independent of the actual cryptography that goes inside the identifier
is possible. For instance, Cryptographically Generated Addresses
(CGAs) can be used by parties that are
unaware of how they were constructed, and that ownership proofs and
other advanced functionality are made separately .Identifier assignment rests on individual devices and
manufacturers; no coordinated identifier assignment or guaranteed
uniqueness exists. However, the 128 bit or longer identifiers are very
unlikely to collide, as long as their generation employs sound
cryptographic principles and proper sources of randomness are used
where necessary.The following three examples provide examples of MAC-based, 1-Wire, and Cryptographic
identifiers:
On most devices, the user can display device identifiers. Depending
on circumstances, device identifiers may or may not be modified or
tampered by the user. An implementation of the DEV URN MUST NOT change
these properties from what they were intended. In particular, a device
identifier that is intended to be immutable should not become mutable
as a part of implementing the DEV URN type. More generally, nothing in
this memo should be construed to override what the relevant device
specifications have already said about the identifiers.Other devices in the same network may or may not be able to
identify the device. For instance, on Ethernet network, the MAC
address of a device is visible to all other devices.Additional subtypes for DEV URNs can be defined through IETF
Review or IESG Approval .The authors would like to thank Christer Holmberg and Ahmad Muhanna
for interesting discussions in this problem space. We would also like
to note prior documents that focused on specific device identifiers,
such as or .