One document matched: draft-arkko-core-dev-urn-00.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902"
     docName="draft-arkko-core-dev-urn-00"
     category="info">

<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>

<front>

<title abbrev="DEV URN">Uniform Resource Names for Device Identifiers</title>

<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>

    <author fullname="Cullen Jennings" initials="C." surname="Jennings">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone>+1 408 421-9990</phone>

        <email>fluffy@cisco.com</email>
      </address>
    </author>

        <author initials="Z" surname="Shelby" fullname="Zach Shelby">
          <organization>
             Sensinode
          </organization>
          <address>
            <postal>
             <street>Kidekuja 2</street>
             <city>Vuokatti</city>
             <code>88600</code>
             <country>FINLAND</country>
            </postal>
            <phone>+358407796297</phone>
            <email>zach@sensinode.com</email>
          </address>
        </author>

<date month="October" year="2011" />

<keyword>URN</keyword>
<keyword>device identifier</keyword>
<keyword>IMEI</keyword>
<keyword>1-wire</keyword>
<keyword>MAC address</keyword>
<keyword>EUI-48</keyword>
<keyword>EUI-64</keyword>

<abstract>

<t>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.</t>

</abstract>

</front>
<middle>

<section anchor="intro" title="Introduction">

<t>This memo describes a new Uniform Resource Name (URN)
<xref target="RFC2141"/> <xref target="RFC3406"/> 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
<xref target="I-D.ietf-core-coap"/>,
<xref target="I-D.jennings-senml"/>,
<xref target="I-D.arkko-core-sleepy-sensors"/>
<xref target="I-D.arkko-core-security-arch"/>. 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 <xref target="RFC2616"/>, <xref
target="RFC3261"/>, <xref target="I-D.ietf-core-coap"/>. Finally, URNs
can also be easily carried and stored in formats such as XML <xref
target="W3C.REC-xml-19980210"/> or JSON <xref
target="I-D.jennings-senml"/> <xref target="RFC4627"/>. 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.</t>

<t>This memo defines identity URN types for situations where no such
convenient type already exist. For instance, <xref
target="I-D.montemurro-gsma-imei-urn"/> defines International Mobile
station Equipment Identity (IMEI) identifiers for use with 3GPP
cellular systems. Similarly, <xref
target="I-D.atarius-dispatch-meid-urn"/> 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.</t>

<t>Universally Unique IDentifier (UUID) URNs <xref target="RFC4122"/>
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.</t>

<t>Future device identifier types can extend the device device URN
type defined here, or define their own URNs.</t>

<t>The rest of this memo is organized as follows. <xref
target="devurn"/> defines the "DEV" URN type, and <xref
target="subtypes"/> defines subtypes for IEEE MAC-48, EUI-48 and EUI-64
addresses, 1-wire device identifiers, and cryptographically defined
identifiers.  <xref target="ex"/> gives examples. <xref target="sec"/>
discusses the security considerations of the new URN type. Finally,
<xref target="iana"/> specifies the IANA registration for the new URN
type and sets requirements for subtype allocations within this
type.</t>

</section>

<section anchor="kwd" title='Requirements language'>

   <t>In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in <xref target='RFC2119' />.</t>

</section>

<section anchor="devurn" title="DEV URN Definition">

<t>Namespace ID: "dev" requested</t>

<t>Registration Information: This is the first registration of this namespace, 2011-08-27.</t>

<t>Registration version number: 1</t>

<t>Registration date: 2011-08-27</t>

<t>Declared 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.</t>

<t>Declaration of syntactic structure: The identifier is expressed in
ASCII (UTF-8) characters and has a hierarchical structure as
follows:</t>

<figure>
<artwork>
  devurn = "urn:dev:" subtype ":" hexstring
  subtype = "mac" / "ow" / "cgi"
  hexstring = hexbyte /
              hexbyte hexstring
  hexbyte = hexdigit hexdigit
  hexdigit = DIGIT / hexletter
  hexletter = "a" / "b" / "c" / "d" / "e" / "f" /
              "A" / "B" / "C" / "D" / "E" / "F"
</artwork>
</figure>

<t>The above Augmented Backus-Naur Form (ABNF) uses the DIGIT rule
defined in <xref target="RFC5234"/>, which is not repeated here.</t>

<t>The device identity namespace includes three subtypes, and more  may be
defined in the future as specified in <xref target="iana"/>.</t>

<t>Relevant ancillary documentation: See <xref
target="subtypes"/>.</t>

<t>Identifier uniqueness considerations: Device identifiers are
generally expected to be unique, barring the accidental issue of
multiple devices with the same identifiers.</t>

<t>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.</t>

<t>Process of identifier assignment: The process for identifier
assignment is dependent on the used subtype, and documented in the
specific subsection under <xref target="subtypes"/>.</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>Validation Mechanism: Specific subtypes may be validated through mechanisms discussed
in <xref target="subtypes"/>.</t>

<t>Scope: DEV URN is global in scope.</t>

</section>

<section anchor="subtypes" title="DEV URN Subtypes">

<section anchor="mac" title="MAC Addresses">

<t>DEV URNs of the "mac" subtype are based on the EUI-64 identifier
<xref target="IEEE.EUI64"/> 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.</t>

<t>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.</t>

<t>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.</t>

<t>Identifier assignment for all of these identifiers rests within the
IEEE.</t>

</section>

<section anchor="1wire" title="1-Wire Device Identifiers">

<t>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 <xref
target="OW"/>.

<list style="empty">
<t>*) 1-Wire is a registered trademark.</t>
</list>
</t>

<t>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.</t>

<t>Family code and identifier assignment for all 1-wire devices rests
with the manufacturers.</t>

</section>

<section anchor="cgi" title="Cryptographically Generated Identifiers">

<t>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.</t>

<t>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) <xref target="RFC3972"/> can be used by parties that are
unaware of how they were constructed, and that ownership proofs and
other advanced functionality are made separately <xref
target="RFC3971"/>.</t>

<t>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.</t>

</section>

</section>

<section anchor="ex" title="Examples">

<t>The following three examples provide examples of MAC-based, 1-Wire, and Cryptographic
identifiers:

<figure>
<artwork>
       urn:dev:mac:0024befffe804ff1  # The MAC address of
                                     # Jari's laptop

       urn:dev:ow:10e2073a01080063   # The 1-Wire temperature
                                     # sensor in Jari's kitchen

       urn:dev:cgi:fd4a5bf6ffb4ca6c  # The example hash output
                                     # for a CGA from RFC 3972
                                     # (before modifications to 
                                     # convert it to an IP address)
</artwork>
</figure>
</t>

</section>

<section anchor="sec" title="Security Considerations">

<t>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.</t>

<t>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.</t>

</section>

<section anchor="iana" title="IANA Considerations">

<t>Additional subtypes for DEV URNs can be defined through IETF
Review or IESG Approval <xref target="RFC5226"/>.</t>

</section>

</middle>

<back>

<references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.2141.xml"?>
      <?rfc include="reference.RFC.3406.xml"?>
      <?rfc include="reference.RFC.5226.xml"?>
      <?rfc include="reference.RFC.5234.xml"?>
      <?rfc include="reference.IEEE.EUI64.xml"?>
      <?rfc include="reference.OW.xml"?>
</references>

<references title="Informative References">
      <?rfc include="reference.RFC.2616.xml"?>
      <?rfc include="reference.RFC.3261.xml"?>
      <?rfc include="reference.RFC.3971.xml"?>
      <?rfc include="reference.RFC.3972.xml"?>
      <?rfc include="reference.RFC.4122.xml"?>
      <?rfc include="reference.RFC.4627.xml"?>
      <?rfc include="reference.W3C.REC-xml-19980210.xml"?>
      <?rfc include="reference.I-D.draft-ietf-core-coap-06.xml"?>
      <?rfc include="reference.I-D.jennings-senml.xml"?>
      <?rfc include="reference.I-D.arkko-core-sleepy-sensors.xml"?>
      <?rfc include="reference.I-D.arkko-core-security-arch.xml"?>
      <?rfc include="reference.I-D.montemurro-gsma-imei-urn.xml"?>
      <?rfc include="reference.I-D.atarius-dispatch-meid-urn.xml"?>
</references>

<section title="Acknowledgments">

<t>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 <xref target="I-D.montemurro-gsma-imei-urn"/> or <xref
target="I-D.atarius-dispatch-meid-urn"/>.</t>

</section>

</back>
</rfc>