idnits 2.17.1 draft-arkko-core-dev-urn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 25, 2011) is 4566 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-06 == Outdated reference: A later version (-10) exists of draft-jennings-senml-05 == Outdated reference: A later version (-20) exists of draft-montemurro-gsma-imei-urn-01 == Outdated reference: A later version (-18) exists of draft-atarius-dispatch-meid-urn-01 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational C. Jennings 5 Expires: April 27, 2012 Cisco 6 Z. Shelby 7 Sensinode 8 October 25, 2011 10 Uniform Resource Names for Device Identifiers 11 draft-arkko-core-dev-urn-00 13 Abstract 15 This memo describes a new Uniform Resource Name (URN) namespace for 16 hardware device identifiers. A general representation of device 17 identity can be useful in many applications, such as in sensor data 18 streams and storage, or equipment inventories. A URN-based 19 representation can be easily passed along in any application that 20 needs the information. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 27, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 58 3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . . 4 59 4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 6 62 4.3. Cryptographically Generated Identifiers . . . . . . . . . 6 63 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 This memo describes a new Uniform Resource Name (URN) [RFC2141] 75 [RFC3406] namespace for hardware device identifiers. A general 76 representation of device identity can be useful in many applications, 77 such as in sensor data streams and storage, or equipment inventories 78 [I-D.ietf-core-coap], [I-D.jennings-senml], 79 [I-D.arkko-core-sleepy-sensors] [I-D.arkko-core-security-arch]. A 80 URN-based representation can be easily passed along in any 81 application that needs the information, as it fits in protocols 82 mechanisms that are designed to carry URNs [RFC2616], [RFC3261], 83 [I-D.ietf-core-coap]. Finally, URNs can also be easily carried and 84 stored in formats such as XML [W3C.REC-xml-19980210] or JSON 85 [I-D.jennings-senml] [RFC4627]. Using URNs in these formats is often 86 preferable as they are universally recognized, self-describing, and 87 therefore avoid the need for agreeing to interpret an octet string as 88 a specific form of a MAC address, for instance. 90 This memo defines identity URN types for situations where no such 91 convenient type already exist. For instance, 92 [I-D.montemurro-gsma-imei-urn] defines International Mobile station 93 Equipment Identity (IMEI) identifiers for use with 3GPP cellular 94 systems. Similarly, [I-D.atarius-dispatch-meid-urn] defines Mobile 95 Equipment Identity (MEID) identifiers for use with 3GPP2 cellular 96 systems. Those URN types should be employed when such identities are 97 transported; this memo does not redefine these identifiers in any 98 way. 100 Universally Unique IDentifier (UUID) URNs [RFC4122] are another 101 alternative way for representing device identifiers, and already 102 support MAC addresses as one of type of an identifier. However, 103 UUIDs can be inconvenient in environments where it is important that 104 the identifiers are as simple as possible and where additional 105 requirements on stable storage, real-time clocks, and identifier 106 length can be prohibitive. UUID-based identifiers are recommended 107 for all general purpose uses when MAC addresses are available as 108 identifiers. The device URN defined in this memo is recommended for 109 constrained environments. 111 Future device identifier types can extend the device device URN type 112 defined here, or define their own URNs. 114 The rest of this memo is organized as follows. Section 3 defines the 115 "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, 116 EUI-48 and EUI-64 addresses, 1-wire device identifiers, and 117 cryptographically defined identifiers. Section 5 gives examples. 118 Section 6 discusses the security considerations of the new URN type. 119 Finally, Section 7 specifies the IANA registration for the new URN 120 type and sets requirements for subtype allocations within this type. 122 2. Requirements language 124 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 125 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 126 described in [RFC2119]. 128 3. DEV URN Definition 130 Namespace ID: "dev" requested 132 Registration Information: This is the first registration of this 133 namespace, 2011-08-27. 135 Registration version number: 1 137 Registration date: 2011-08-27 139 Declared registrant of the namespace: IETF and the CORE working 140 group. Should the working group cease to exist, discussion should be 141 directed to the general IETF discussion forums or the IESG. 143 Declaration of syntactic structure: The identifier is expressed in 144 ASCII (UTF-8) characters and has a hierarchical structure as follows: 146 devurn = "urn:dev:" subtype ":" hexstring 147 subtype = "mac" / "ow" / "cgi" 148 hexstring = hexbyte / 149 hexbyte hexstring 150 hexbyte = hexdigit hexdigit 151 hexdigit = DIGIT / hexletter 152 hexletter = "a" / "b" / "c" / "d" / "e" / "f" / 153 "A" / "B" / "C" / "D" / "E" / "F" 155 The above Augmented Backus-Naur Form (ABNF) uses the DIGIT rule 156 defined in [RFC5234], which is not repeated here. 158 The device identity namespace includes three subtypes, and more may 159 be defined in the future as specified in Section 7. 161 Relevant ancillary documentation: See Section 4. 163 Identifier uniqueness considerations: Device identifiers are 164 generally expected to be unique, barring the accidental issue of 165 multiple devices with the same identifiers. 167 Identifier persistence considerations: This URN type SHOULD only be 168 used for persistent identifiers, such as hardware-based identifiers 169 or cryptographic identifiers based on keys intended for long-term 170 usage. 172 Process of identifier assignment: The process for identifier 173 assignment is dependent on the used subtype, and documented in the 174 specific subsection under Section 4. 176 Process for identifier resolution: The device identities are not 177 expected to be globally resolvable. No identity resolution system is 178 expected. Systems may perform local matching of identities to 179 previously seen identities or configured information, however. 181 Rules for Lexical Equivalence: The lexical equivalence of the DEV URN 182 is defined as an exact, but not case-sensitive, string match. While 183 uppercase letters are accepted, all systems that construct or display 184 DEV URNs MUST employ lower case letters. This is necessary to ensure 185 that searches, processing rules, and other potentially case sensitive 186 tools have uniformly lower-case identifiers to look at. 188 Conformance with URN Syntax: The string representation of the device 189 identity URN and of the MEID sub namespace is fully compatible with 190 the URN syntax. 192 Validation Mechanism: Specific subtypes may be validated through 193 mechanisms discussed in Section 4. 195 Scope: DEV URN is global in scope. 197 4. DEV URN Subtypes 199 4.1. MAC Addresses 201 DEV URNs of the "mac" subtype are based on the EUI-64 identifier 202 [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64. 203 The EUI-64 is formed from 24 or 36 bits of organization identifier 204 followed by 40 or 28 bits of device-specific extension identifier 205 assigned by that organization. 207 In the DEV URN "mac" subtype the hexstring is simply the full EUI-64 208 identifier represented as a hexadecimal string. It is always exactly 209 16 characters long. 211 MAC-48 and EUI-48 identifiers are also supported by the same DEV URN 212 subtype. To convert a MAC-48 address to an EUI-64 identifier, The 213 OUI of the Ethernet address (the first three octets) becomes the 214 organization identifier of the EUI-64 (the first three octets). The 215 fourth and fifth octets of the EUI are set to the fixed value FFFF 216 hexadecimal. The last three octets of the Ethernet address become 217 the last three octets of the EUI-64. The same process is used to 218 convert an EUI-48 identifier, but the fixed value FFFE is used 219 instead. 221 Identifier assignment for all of these identifiers rests within the 222 IEEE. 224 4.2. 1-Wire Device Identifiers 226 The 1-Wire* system is a device communications bus system designed by 227 Dallas Semiconductor Corporation. 1-Wire devices are identified by a 228 64-bit identifier that consists of 8 byte family code, 48 bit 229 identifier unique within a family, and 8 bit CRC code [OW]. 231 *) 1-Wire is a registered trademark. 233 In DEV URNs with the "ow" subtype the hexstring is a representation 234 of the full 64 bit identifier as a hexadecimal string. It is always 235 exactly 16 characters long. Note that the last two characters 236 represent the 8-bit CRC code. Implementations MAY check the validity 237 of this code. 239 Family code and identifier assignment for all 1-wire devices rests 240 with the manufacturers. 242 4.3. Cryptographically Generated Identifiers 244 DEV URNs with the "cgi" subtype represent cryptographically 245 identified devices. These identifiers are variable length but the 246 hexstring MUST be at least 16 characters long (128 bits). The 247 hexstring MUST have an even number of characters. 249 This memo does not define the construction of the cryptographic 250 identifiers or the algorithms used in the construction, as these are 251 up to the specific implementations. It should be noted, however, 252 that the use of cryptographic identifiers for anything else as tokens 253 of identification will require the communicating parties to agree on 254 how they are used, and what algorithms and methods are used to verify 255 an ownership claim, for instance. These are outside the scope of 256 this draft, however. The authors observe that the use of plain 257 identifiers independent of the actual cryptography that goes inside 258 the identifier is possible. For instance, Cryptographically 259 Generated Addresses (CGAs) [RFC3972] can be used by parties that are 260 unaware of how they were constructed, and that ownership proofs and 261 other advanced functionality are made separately [RFC3971]. 263 Identifier assignment rests on individual devices and manufacturers; 264 no coordinated identifier assignment or guaranteed uniqueness exists. 265 However, the 128 bit or longer identifiers are very unlikely to 266 collide, as long as their generation employs sound cryptographic 267 principles and proper sources of randomness are used where necessary. 269 5. Examples 271 The following three examples provide examples of MAC-based, 1-Wire, 272 and Cryptographic identifiers: 274 urn:dev:mac:0024befffe804ff1 # The MAC address of 275 # Jari's laptop 277 urn:dev:ow:10e2073a01080063 # The 1-Wire temperature 278 # sensor in Jari's kitchen 280 urn:dev:cgi:fd4a5bf6ffb4ca6c # The example hash output 281 # for a CGA from RFC 3972 282 # (before modifications to 283 # convert it to an IP address) 285 6. Security Considerations 287 On most devices, the user can display device identifiers. Depending 288 on circumstances, device identifiers may or may not be modified or 289 tampered by the user. An implementation of the DEV URN MUST NOT 290 change these properties from what they were intended. In particular, 291 a device identifier that is intended to be immutable should not 292 become mutable as a part of implementing the DEV URN type. More 293 generally, nothing in this memo should be construed to override what 294 the relevant device specifications have already said about the 295 identifiers. 297 Other devices in the same network may or may not be able to identify 298 the device. For instance, on Ethernet network, the MAC address of a 299 device is visible to all other devices. 301 7. IANA Considerations 303 Additional subtypes for DEV URNs can be defined through IETF Review 304 or IESG Approval [RFC5226]. 306 8. References 307 8.1. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 314 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 315 "Uniform Resource Names (URN) Namespace Definition 316 Mechanisms", BCP 66, RFC 3406, October 2002. 318 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 319 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 320 May 2008. 322 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 323 Specifications: ABNF", STD 68, RFC 5234, January 2008. 325 [IEEE.EUI64] 326 IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", 327 IEEE , 328 . 330 [OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use", 331 MAXIM 332 http://www.maxim-ic.com/app-notes/index.mvp/id/1796, 333 . 335 8.2. Informative References 337 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 338 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 339 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 341 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 342 A., Peterson, J., Sparks, R., Handley, M., and E. 343 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 344 June 2002. 346 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 347 Neighbor Discovery (SEND)", RFC 3971, March 2005. 349 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 350 RFC 3972, March 2005. 352 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 353 Unique IDentifier (UUID) URN Namespace", RFC 4122, 354 July 2005. 356 [RFC4627] Crockford, D., "The application/json Media Type for 357 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 359 [W3C.REC-xml-19980210] 360 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 361 Recommendation", World Wide Web Consortium 362 FirstEdition REC-xml-19980210, February 1998, 363 . 365 [I-D.ietf-core-coap] 366 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 367 "Constrained Application Protocol (CoAP)", 368 draft-ietf-core-coap-06 (work in progress), May 2011. 370 [I-D.jennings-senml] 371 Jennings, C., "Media Type for Sensor Markup Language 372 (SENML)", draft-jennings-senml-05 (work in progress), 373 March 2011. 375 [I-D.arkko-core-sleepy-sensors] 376 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 377 Novo, "Implementing Tiny COAP Sensors", 378 draft-arkko-core-sleepy-sensors-01 (work in progress), 379 July 2011. 381 [I-D.arkko-core-security-arch] 382 Arkko, J. and A. Keranen, "CoAP Security Architecture", 383 draft-arkko-core-security-arch-00 (work in progress), 384 July 2011. 386 [I-D.montemurro-gsma-imei-urn] 387 Montemurro, M., "A Uniform Resource Name Namespace For The 388 GSM Association (GSMA) and the International Mobile 389 station Equipment Identity(IMEI)", 390 draft-montemurro-gsma-imei-urn-01 (work in progress), 391 February 2007. 393 [I-D.atarius-dispatch-meid-urn] 394 Atarius, R., "A Uniform Resource Name Namespace for the 395 Device Identity and the Mobile Equipment Identity (MEID)", 396 draft-atarius-dispatch-meid-urn-01 (work in progress), 397 August 2011. 399 Appendix A. Acknowledgments 401 The authors would like to thank Christer Holmberg and Ahmad Muhanna 402 for interesting discussions in this problem space. We would also 403 like to note prior documents that focused on specific device 404 identifiers, such as [I-D.montemurro-gsma-imei-urn] or 405 [I-D.atarius-dispatch-meid-urn]. 407 Authors' Addresses 409 Jari Arkko 410 Ericsson 411 Jorvas 02420 412 Finland 414 Email: jari.arkko@piuha.net 416 Cullen Jennings 417 Cisco 418 170 West Tasman Drive 419 San Jose, CA 95134 420 USA 422 Phone: +1 408 421-9990 423 Email: fluffy@cisco.com 425 Zach Shelby 426 Sensinode 427 Kidekuja 2 428 Vuokatti 88600 429 FINLAND 431 Phone: +358407796297 432 Email: zach@sensinode.com