idnits 2.17.1 draft-arkko-core-dev-urn-04.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 (July 3, 2017) is 2489 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 ---------------------------------------------------------------------------- == Unused Reference: 'RFC3971' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 376, but no explicit reference was found in the text ** 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) == Outdated reference: A later version (-18) exists of draft-atarius-dispatch-meid-urn-12 == Outdated reference: A later version (-16) exists of draft-ietf-core-senml-09 -- 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) 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: January 4, 2018 Cisco 6 Z. Shelby 7 Sensinode 8 July 3, 2017 10 Uniform Resource Names for Device Identifiers 11 draft-arkko-core-dev-urn-04 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 January 4, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 58 3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 3 59 4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 5 62 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Appendix A. Changes from Previous Version . . . . . . . . . . . 9 69 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 10 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 [RFC7252], [I-D.ietf-core-senml], [I-D.arkko-core-sleepy-sensors] 79 [I-D.arkko-core-security-arch]. A URN-based representation can be 80 easily passed along in any application that needs the information, as 81 it fits in protocols mechanisms that are designed to carry URNs 82 [RFC2616], [RFC3261], [RFC7252]. Finally, URNs can also be easily 83 carried and stored in formats such as XML [W3C.REC-xml-19980210] or 84 JSON [I-D.ietf-core-senml] [RFC4627]. Using URNs in these formats is 85 often preferable as they are universally recognized, self-describing, 86 and therefore avoid the need for agreeing to interpret an octet 87 string as a specific form of a MAC address, for instance. 89 This memo defines identity URN types for situations where no such 90 convenient type already exist. For instance, [RFC6920] defines 91 cryptographic identifiers, [RFC7254] defines International Mobile 92 station Equipment Identity (IMEI) identifiers for use with 3GPP 93 cellular systems, and [I-D.atarius-dispatch-meid-urn] defines Mobile 94 Equipment Identity (MEID) identifiers for use with 3GPP2 cellular 95 systems. Those URN types should be employed when such identities are 96 transported; this memo does not redefine these identifiers in any 97 way. 99 Universally Unique IDentifier (UUID) URNs [RFC4122] are another 100 alternative way for representing device identifiers, and already 101 support MAC addresses as one of type of an identifier. However, 102 UUIDs can be inconvenient in environments where it is important that 103 the identifiers are as simple as possible and where additional 104 requirements on stable storage, real-time clocks, and identifier 105 length can be prohibitive. UUID-based identifiers are recommended 106 for all general purpose uses when MAC addresses are available as 107 identifiers. The device URN defined in this memo is recommended for 108 constrained environments. 110 Future device identifier types can extend the device device URN type 111 defined here, or define their own URNs. 113 The rest of this memo is organized as follows. Section 3 defines the 114 "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, 115 EUI-48 and EUI-64 addresses and 1-wire device identifiers. Section 5 116 gives examples. Section 6 discusses the security considerations of 117 the new URN type. Finally, Section 7 specifies the IANA registration 118 for the new URN type and sets requirements for subtype allocations 119 within this type. 121 2. Requirements language 123 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 124 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 125 described in [RFC2119]. 127 3. DEV URN Definition 129 Namespace ID: "dev" requested 131 Registration Information: This is the first registration of this 132 namespace, 2011-08-27. 134 Registration version number: 1 136 Registration date: 2011-08-27 138 Declared registrant of the namespace: IETF and the CORE working 139 group. Should the working group cease to exist, discussion should be 140 directed to the general IETF discussion forums or the IESG. 142 Declaration of syntactic structure: The identifier is expressed in 143 ASCII (UTF-8) characters and has a hierarchical structure as follows: 145 devurn = "urn:dev:" body componentpart 146 body = macbody / owbody / otherbody 147 macbody = "mac:" hexstring 148 owbody = "ow:" hexstring 149 otherbody = subtype ":" identifier 150 subtype = ALPHA *(DIGIT / ALPHA) 151 identifier = 1*unreserved 152 componentpart = [ ";" component [ componentpart ]] 153 component = *1(DIGIT / ALPHA) 154 hexstring = hexbyte / 155 hexbyte hexstring 156 hexbyte = hexdigit hexdigit 157 hexdigit = DIGIT / hexletter 158 hexletter = "a" / "b" / "c" / "d" / "e" / "f" 160 The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA 161 rules defined in [RFC5234], which are not repeated here. The rule 162 for unreserved is defined in Section 2.3 of [RFC3986]. 164 The device identity namespace includes three subtypes, and more may 165 be defined in the future as specified in Section 7. 167 The optional components following the hexstring are strings depicting 168 individual aspects of a device. The specific strings and their 169 semantics are up to the designers of the device, but could be used to 170 refer to specific interfaces or functions within the device. 172 Relevant ancillary documentation: See Section 4. 174 Identifier uniqueness considerations: Device identifiers are 175 generally expected to be unique, barring the accidental issue of 176 multiple devices with the same identifiers. 178 Identifier persistence considerations: This URN type SHOULD only be 179 used for persistent identifiers, such as hardware-based identifiers 180 or cryptographic identifiers based on keys intended for long-term 181 usage. 183 Process of identifier assignment: The process for identifier 184 assignment is dependent on the used subtype, and documented in the 185 specific subsection under Section 4. 187 Process for identifier resolution: The device identities are not 188 expected to be globally resolvable. No identity resolution system is 189 expected. Systems may perform local matching of identities to 190 previously seen identities or configured information, however. 192 Rules for Lexical Equivalence: The lexical equivalence of the DEV URN 193 is defined as an exact and case sensitive string match. Note that 194 the two subtypes defined in this document use only lower case 195 letters, however. Future types might use identifiers that require 196 other encodings that require a more full-blown character set (such as 197 BASE64), however. 199 Conformance with URN Syntax: The string representation of the device 200 identity URN and of the MEID sub namespace is fully compatible with 201 the URN syntax. 203 Validation Mechanism: Specific subtypes may be validated through 204 mechanisms discussed in Section 4. 206 Scope: DEV URN is global in scope. 208 4. DEV URN Subtypes 210 4.1. MAC Addresses 212 DEV URNs of the "mac" subtype are based on the EUI-64 identifier 213 [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64. 214 The EUI-64 is formed from 24 or 36 bits of organization identifier 215 followed by 40 or 28 bits of device-specific extension identifier 216 assigned by that organization. 218 In the DEV URN "mac" subtype the hexstring is simply the full EUI-64 219 identifier represented as a hexadecimal string. It is always exactly 220 16 characters long. 222 MAC-48 and EUI-48 identifiers are also supported by the same DEV URN 223 subtype. To convert a MAC-48 address to an EUI-64 identifier, The 224 OUI of the Ethernet address (the first three octets) becomes the 225 organization identifier of the EUI-64 (the first three octets). The 226 fourth and fifth octets of the EUI are set to the fixed value FFFF 227 hexadecimal. The last three octets of the Ethernet address become 228 the last three octets of the EUI-64. The same process is used to 229 convert an EUI-48 identifier, but the fixed value FFFE is used 230 instead. 232 Identifier assignment for all of these identifiers rests within the 233 IEEE. 235 4.2. 1-Wire Device Identifiers 237 The 1-Wire* system is a device communications bus system designed by 238 Dallas Semiconductor Corporation. 1-Wire devices are identified by a 239 64-bit identifier that consists of 8 byte family code, 48 bit 240 identifier unique within a family, and 8 bit CRC code [OW]. 242 *) 1-Wire is a registered trademark. 244 In DEV URNs with the "ow" subtype the hexstring is a representation 245 of the full 64 bit identifier as a hexadecimal string. It is always 246 exactly 16 characters long. Note that the last two characters 247 represent the 8-bit CRC code. Implementations MAY check the validity 248 of this code. 250 Family code and identifier assignment for all 1-wire devices rests 251 with the manufacturers. 253 5. Examples 255 The following three examples provide examples of MAC-based, 1-Wire, 256 and Cryptographic identifiers: 258 urn:dev:mac:0024befffe804ff1 # The MAC address of 259 # Jari's laptop 261 urn:dev:ow:10e2073a01080063 # The 1-Wire temperature 262 # sensor in Jari's 263 # kitchen 265 urn:dev:ow:264437f5000000ed;humidity # The laundry sensor's 266 # humidity part 268 urn:dev:ow:264437f5000000ed;temperature # The laundry sensor's 269 # temperature part 271 6. Security Considerations 273 On most devices, the user can display device identifiers. Depending 274 on circumstances, device identifiers may or may not be modified or 275 tampered by the user. An implementation of the DEV URN MUST NOT 276 change these properties from what they were intended. In particular, 277 a device identifier that is intended to be immutable should not 278 become mutable as a part of implementing the DEV URN type. More 279 generally, nothing in this memo should be construed to override what 280 the relevant device specifications have already said about the 281 identifiers. 283 Other devices in the same network may or may not be able to identify 284 the device. For instance, on Ethernet network, the MAC address of a 285 device is visible to all other devices. 287 7. IANA Considerations 289 Additional subtypes for DEV URNs can be defined through IETF Review 290 or IESG Approval [RFC5226]. 292 8. References 294 8.1. Normative References 296 [IEEE.EUI64] 297 IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", 298 IEEE , unknown year, 299 . 301 [OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use", 302 MAXIM 303 http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June 304 2008, 305 . 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, 313 May 1997, . 315 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 316 "Uniform Resource Names (URN) Namespace Definition 317 Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002, 318 . 320 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 321 Resource Identifier (URI): Generic Syntax", STD 66, 322 RFC 3986, DOI 10.17487/RFC3986, January 2005, 323 . 325 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 326 IANA Considerations Section in RFCs", RFC 5226, 327 DOI 10.17487/RFC5226, May 2008, 328 . 330 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 331 Specifications: ABNF", STD 68, RFC 5234, 332 DOI 10.17487/RFC5234, January 2008, 333 . 335 8.2. Informative References 337 [I-D.arkko-core-security-arch] 338 Arkko, J. and A. Keranen, "CoAP Security Architecture", 339 draft-arkko-core-security-arch-00 (work in progress), July 340 2011. 342 [I-D.arkko-core-sleepy-sensors] 343 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 344 Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- 345 sleepy-sensors-01 (work in progress), July 2011. 347 [I-D.atarius-dispatch-meid-urn] 348 Atarius, R., "A Uniform Resource Name Namespace for the 349 Device Identity and the Mobile Equipment Identity (MEID)", 350 draft-atarius-dispatch-meid-urn-12 (work in progress), May 351 2017. 353 [I-D.ietf-core-senml] 354 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 355 Bormann, "Media Types for Sensor Measurement Lists 356 (SenML)", draft-ietf-core-senml-09 (work in progress), 357 June 2017. 359 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 360 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 361 Transfer Protocol -- HTTP/1.1", RFC 2616, 362 DOI 10.17487/RFC2616, June 1999, 363 . 365 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 366 A., Peterson, J., Sparks, R., Handley, M., and E. 367 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 368 DOI 10.17487/RFC3261, June 2002, 369 . 371 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 372 "SEcure Neighbor Discovery (SEND)", RFC 3971, 373 DOI 10.17487/RFC3971, March 2005, 374 . 376 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 377 RFC 3972, DOI 10.17487/RFC3972, March 2005, 378 . 380 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 381 Unique IDentifier (UUID) URN Namespace", RFC 4122, 382 DOI 10.17487/RFC4122, July 2005, 383 . 385 [RFC4627] Crockford, D., "The application/json Media Type for 386 JavaScript Object Notation (JSON)", RFC 4627, 387 DOI 10.17487/RFC4627, July 2006, 388 . 390 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 391 Keranen, A., and P. Hallam-Baker, "Naming Things with 392 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 393 . 395 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 396 Application Protocol (CoAP)", RFC 7252, 397 DOI 10.17487/RFC7252, June 2014, 398 . 400 [RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. 401 Gosden, "A Uniform Resource Name Namespace for the Global 402 System for Mobile Communications Association (GSMA) and 403 the International Mobile station Equipment Identity 404 (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, 405 . 407 [W3C.REC-xml-19980210] 408 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 409 Recommendation", World Wide Web Consortium FirstEdition 410 REC-xml-19980210, February 1998, 411 . 413 Appendix A. Changes from Previous Version 415 Version -04 is a refresh, as the need and interest for this 416 specification has re-emerged. And the editing author has emerged 417 back to actual engineering from the depths of IETF administration. 419 Version -02 introduced several changes. The biggest change is that 420 with the NI URNs [RFC6920], it was no longer necessary to define 421 cryptographic identifiers in this specification. Another change was 422 that we incorporated a more generic syntax for future extensions; 423 non-hexstring identifiers can now also be supported, if some future 424 device identifiers for some reason would, for instance, use BASE64. 425 As a part of this change, we also changed the component part 426 separator character from '-' to ';' so that the general format of the 427 rest of the URN can employ the unreserved characters [RFC3986]. 429 Appendix B. Acknowledgments 431 The authors would like to thank Ari Keranen, Stephen Farrell, 432 Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, and Ahmad 433 Muhanna for interesting discussions in this problem space. We would 434 also like to note prior documents that focused on specific device 435 identifiers, such as [RFC7254] or [I-D.atarius-dispatch-meid-urn]. 437 Authors' Addresses 439 Jari Arkko 440 Ericsson 441 Jorvas 02420 442 Finland 444 Email: jari.arkko@piuha.net 446 Cullen Jennings 447 Cisco 448 170 West Tasman Drive 449 San Jose, CA 95134 450 USA 452 Phone: +1 408 421-9990 453 Email: fluffy@cisco.com 455 Zach Shelby 456 Sensinode 457 Kidekuja 2 458 Vuokatti 88600 459 FINLAND 461 Phone: +358407796297 462 Email: zach@sensinode.com