idnits 2.17.1 draft-ietf-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 (March 5, 2018) is 2238 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 397, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC5612' is defined on line 416, but no explicit reference was found in the text ** 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 (-16) exists of draft-ietf-core-senml-13 == Outdated reference: A later version (-18) exists of draft-atarius-dispatch-meid-urn-15 Summary: 2 errors (**), 0 flaws (~~), 7 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: September 6, 2018 Cisco 6 Z. Shelby 7 Sensinode 8 March 5, 2018 10 Uniform Resource Names for Device Identifiers 11 draft-ietf-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 September 6, 2018. 39 Copyright Notice 41 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . 6 62 4.3. Organization-Defined Identifiers . . . . . . . . . . . . 6 63 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 9 69 Appendix A. Changes from Previous Version . . . . . . . . . . . 10 70 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 This memo describes a new Uniform Resource Name (URN) [RFC8141] 76 [RFC3406] namespace for hardware device identifiers. A general 77 representation of device identity can be useful in many applications, 78 such as in sensor data streams and storage, or equipment inventories 79 [RFC7252], [I-D.ietf-core-senml]. 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 Note that long-term stable unique identifiers are problematic for 114 privacy reasons and should be used with care or avoided as described 115 in [RFC7721]. 117 The rest of this memo is organized as follows. Section 3 defines the 118 "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, 119 EUI-48 and EUI-64 addresses and 1-wire device identifiers. Section 5 120 gives examples. Section 6 discusses the security considerations of 121 the new URN type. Finally, Section 7 specifies the IANA registration 122 for the new URN type and sets requirements for subtype allocations 123 within this type. 125 2. Requirements language 127 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 128 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 129 described in [RFC2119]. 131 3. DEV URN Definition 133 Namespace ID: "dev" requested 135 Registration Information: This is the first registration of this 136 namespace, 2011-08-27. 138 Registration version number: 1 140 Registration date: 2011-08-27 142 Declared registrant of the namespace: IETF and the CORE working 143 group. Should the working group cease to exist, discussion should be 144 directed to the general IETF discussion forums or the IESG. 146 Declaration of syntactic structure: The identifier is expressed in 147 ASCII characters and has a hierarchical structure as follows: 149 devurn = "urn:dev:" body componentpart 150 body = macbody / owbody / orgbody / otherbody 151 macbody = "mac:" hexstring 152 owbody = "ow:" hexstring 153 orgbody = "org:" number ":" identifier 154 otherbody = subtype ":" identifier 155 subtype = ALPHA *(DIGIT / ALPHA) 156 identifier = 1*unreservednout 157 unreservednout = ALPHA / DIGIT / "-" / "." 158 componentpart = [ "_" component [ componentpart ]] 159 component = *1(DIGIT / ALPHA) 160 hexstring = hexbyte / 161 hexbyte hexstring 162 hexbyte = hexdigit hexdigit 163 hexdigit = DIGIT / hexletter 164 hexletter = "a" / "b" / "c" / "d" / "e" / "f" 165 number = *1DIGIT 167 The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA 168 rules defined in [RFC5234], which are not repeated here. The rule 169 for unreserved is defined in Section 2.3 of [RFC3986]. 171 The device identity namespace includes three subtypes, and more may 172 be defined in the future as specified in Section 7. 174 The optional components following the hexstring are strings depicting 175 individual aspects of a device. The specific strings and their 176 semantics are up to the designers of the device, but could be used to 177 refer to specific interfaces or functions within the device. 179 Relevant ancillary documentation: See Section 4. 181 Identifier uniqueness considerations: Device identifiers are 182 generally expected to be unique, barring the accidental issue of 183 multiple devices with the same identifiers. 185 Identifier persistence considerations: This URN type SHOULD only be 186 used for persistent identifiers, such as hardware-based identifiers 187 or cryptographic identifiers based on keys intended for long-term 188 usage. 190 Process of identifier assignment: The process for identifier 191 assignment is dependent on the used subtype, and documented in the 192 specific subsection under Section 4. 194 Process for identifier resolution: The device identities are not 195 expected to be globally resolvable. No identity resolution system is 196 expected. Systems may perform local matching of identities to 197 previously seen identities or configured information, however. 199 Rules for Lexical Equivalence: The lexical equivalence of the DEV URN 200 is defined as an exact and case sensitive string match. Note that 201 the two subtypes defined in this document use only lower case 202 letters, however. Future types might use identifiers that require 203 other encodings that require a more full-blown character set (such as 204 BASE64), however. 206 Conformance with URN Syntax: The string representation of the device 207 identity URN and of the MEID sub namespace is fully compatible with 208 the URN syntax. 210 Validation Mechanism: Specific subtypes may be validated through 211 mechanisms discussed in Section 4. 213 Scope: DEV URN is global in scope. 215 4. DEV URN Subtypes 217 4.1. MAC Addresses 219 DEV URNs of the "mac" subtype are based on the EUI-64 identifier 220 [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64. 221 The EUI-64 is formed from 24 or 36 bits of organization identifier 222 followed by 40 or 28 bits of device-specific extension identifier 223 assigned by that organization. 225 In the DEV URN "mac" subtype the hexstring is simply the full EUI-64 226 identifier represented as a hexadecimal string. It is always exactly 227 16 characters long. 229 MAC-48 and EUI-48 identifiers are also supported by the same DEV URN 230 subtype. To convert a MAC-48 address to an EUI-64 identifier, The 231 OUI of the Ethernet address (the first three octets) becomes the 232 organization identifier of the EUI-64 (the first three octets). The 233 fourth and fifth octets of the EUI are set to the fixed value FFFF 234 hexadecimal. The last three octets of the Ethernet address become 235 the last three octets of the EUI-64. The same process is used to 236 convert an EUI-48 identifier, but the fixed value FFFE is used 237 instead. 239 Identifier assignment for all of these identifiers rests within the 240 IEEE. 242 4.2. 1-Wire Device Identifiers 244 The 1-Wire* system is a device communications bus system designed by 245 Dallas Semiconductor Corporation. 1-Wire devices are identified by a 246 64-bit identifier that consists of 8 byte family code, 48 bit 247 identifier unique within a family, and 8 bit CRC code [OW]. 249 *) 1-Wire is a registered trademark. 251 In DEV URNs with the "ow" subtype the hexstring is a representation 252 of the full 64 bit identifier as a hexadecimal string. It is always 253 exactly 16 characters long. Note that the last two characters 254 represent the 8-bit CRC code. Implementations MAY check the validity 255 of this code. 257 Family code and identifier assignment for all 1-wire devices rests 258 with the manufacturers. 260 4.3. Organization-Defined Identifiers 262 Device identifiers that have only a meaning within an organisation 263 can also be used to represent vendor-specific or experimental 264 identifiers or identifiers designed for use within the context of an 265 organisation. Organisations are identified by the Private Enterprise 266 Number [RFC2578]. 268 5. Examples 270 The following three examples provide examples of MAC-based, 1-Wire, 271 and Cryptographic identifiers: 273 urn:dev:mac:0024befffe804ff1 # The MAC address of 274 # Jari's laptop 276 urn:dev:ow:10e2073a01080063 # The 1-Wire temperature 277 # sensor in Jari's 278 # kitchen 280 urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's 281 # humidity part 283 urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's 284 # temperature part 286 urn:dev:org:32473:123456 # Device 123456 in 287 # the RFC 5612 example 288 # organisation 290 6. Security Considerations 292 On most devices, the user can display device identifiers. Depending 293 on circumstances, device identifiers may or may not be modified or 294 tampered by the user. An implementation of the DEV URN MUST NOT 295 change these properties from what they were intended. In particular, 296 a device identifier that is intended to be immutable should not 297 become mutable as a part of implementing the DEV URN type. More 298 generally, nothing in this memo should be construed to override what 299 the relevant device specifications have already said about the 300 identifiers. 302 Other devices in the same network may or may not be able to identify 303 the device. For instance, on Ethernet network, the MAC address of a 304 device is visible to all other devices. 306 The URNs generated according to the rules defined in this document 307 result in long-term stable unique identifiers for the devices. Such 308 identifiers may have privacy and security implications because they 309 may enable correlating information about a specific device over a 310 long period of time, location tracking, and device specific 311 vulnerability exploitation [RFC7721]. Also, usually there is no easy 312 way to change the identifier. Therefore these identifiers need to be 313 used with care and especially care should be taken avoid leaking them 314 outside of the system that is intended to use the identifiers. 316 7. IANA Considerations 318 This document requests the registration of a new URN namespace for 319 "DEV", as described in Section 3. 321 Additional subtypes for DEV URNs can be defined through IETF Review 322 or IESG Approval [RFC5226]. 324 Such allocations are appropriate when there is a new namespace of 325 some type of device identifiers, defined in stable fashion and with a 326 publicly available specification that can be pointed to. 328 Note that the organisation (Section 4.3) device identifiers can also 329 be used in some cases, at least as a temporary measure. It is 330 preferrable, however, that long-term usage of a broadly employed 331 device identifier be registered with IETF rather than used through 332 the organisation device identifier type. 334 8. References 336 8.1. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 340 RFC2119, March 1997, . 343 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 344 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 345 . 347 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 348 Schoenwaelder, Ed., "Structure of Management Information 349 Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/ 350 RFC2578, April 1999, . 353 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 354 "Uniform Resource Names (URN) Namespace Definition 355 Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002, 356 . 358 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 359 Resource Identifier (URI): Generic Syntax", STD 66, RFC 360 3986, DOI 10.17487/RFC3986, January 2005, . 363 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 364 IANA Considerations Section in RFCs", RFC 5226, DOI 365 10.17487/RFC5226, May 2008, . 368 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 369 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 370 RFC5234, January 2008, . 373 [IEEE.EUI64] 374 IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", 375 IEEE , unknown year, 376 . 378 [OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use", 379 MAXIM http://www.maxim-ic.com/app-notes/index.mvp/id/1796, 380 June 2008, 381 . 383 8.2. Informative References 385 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 386 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 387 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 388 RFC2616, June 1999, . 391 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 392 A., Peterson, J., Sparks, R., Handley, M., and E. 393 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 394 DOI 10.17487/RFC3261, June 2002, . 397 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 398 "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487 399 /RFC3971, March 2005, . 402 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 403 RFC 3972, DOI 10.17487/RFC3972, March 2005, . 406 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 407 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 408 10.17487/RFC4122, July 2005, . 411 [RFC4627] Crockford, D., "The application/json Media Type for 412 JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487 413 /RFC4627, July 2006, . 416 [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for 417 Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 418 2009, . 420 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 421 Considerations for IPv6 Address Generation Mechanisms", 422 RFC 7721, DOI 10.17487/RFC7721, March 2016, . 425 [W3C.REC-xml-19980210] 426 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 427 Recommendation", World Wide Web Consortium FirstEdition 428 REC-xml-19980210, February 1998, 429 . 431 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 432 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 433 RFC7252, June 2014, . 436 [I-D.ietf-core-senml] 437 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 438 Bormann, "Media Types for Sensor Measurement Lists 439 (SenML)", draft-ietf-core-senml-13 (work in progress), 440 March 2018. 442 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 443 Keranen, A., and P. Hallam-Baker, "Naming Things with 444 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 445 . 447 [RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. 448 Gosden, "A Uniform Resource Name Namespace for the Global 449 System for Mobile Communications Association (GSMA) and 450 the International Mobile station Equipment Identity 451 (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, . 454 [I-D.atarius-dispatch-meid-urn] 455 Atarius, R., "A Uniform Resource Name Namespace for the 456 Device Identity and the Mobile Equipment Identity (MEID)", 457 draft-atarius-dispatch-meid-urn-15 (work in progress), 458 January 2018. 460 Appendix A. Changes from Previous Version 462 Version -00 of the WG draft renamed the file name and fixed the ABNF 463 to correctly use "org:" rather than "dn:". 465 Version -05 made a change to the delimiter for parameters within a 466 DEV URN. Given discussions on allowed character sets in SenML 467 [I-D.ietf-core-senml], we would like to suggest that the "_" 468 character be used instead of ";", to avoid the need to translate DEV 469 URNs in SenML-formatted communications or files. However, this 470 reverses the earlier decision to not use unreserved characters. This 471 also means that device IDs cannot use "_" characters, and have to 472 employ other characters instead. Feedback on this decision is 473 sought. 475 Version -05 also introduced local or organisation-specific device 476 identifiers. Organisations are identified by their PEN number 477 (although we considered FQDNs as a potential alternative. The 478 authors belive an organisation-specific device identifier type will 479 make experiments and local use easier, but feedback on this point and 480 the choice of PEN numbers vs. other possible organisation identifiers 481 would be very welcome. 483 Version -05 also added some discussion of privacy concerns around 484 long-term stable identifiers. 486 Finally, version -05 clarified the situations when new allocations 487 within the registry of possible device identifier subtypes is 488 appropriate. 490 Version -04 is a refresh, as the need and interest for this 491 specification has re-emerged. And the editing author has emerged 492 back to actual engineering from the depths of IETF administration. 494 Version -02 introduced several changes. The biggest change is that 495 with the NI URNs [RFC6920], it was no longer necessary to define 496 cryptographic identifiers in this specification. Another change was 497 that we incorporated a more generic syntax for future extensions; 498 non-hexstring identifiers can now also be supported, if some future 499 device identifiers for some reason would, for instance, use BASE64. 500 As a part of this change, we also changed the component part 501 separator character from '-' to ';' so that the general format of the 502 rest of the URN can employ the unreserved characters [RFC3986]. 504 Appendix B. Acknowledgments 506 The authors would like to thank Ari Keranen, Stephen Farrell, 507 Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez, 508 and Ahmad Muhanna for interesting discussions in this problem space. 509 We would also like to note prior documents that focused on specific 510 device identifiers, such as [RFC7254] or 511 [I-D.atarius-dispatch-meid-urn]. 513 Authors' Addresses 515 Jari Arkko 516 Ericsson 517 Jorvas 02420 518 Finland 520 Email: jari.arkko@piuha.net 522 Cullen Jennings 523 Cisco 524 170 West Tasman Drive 525 San Jose, CA 95134 526 USA 528 Phone: +1 408 421-9990 529 Email: fluffy@cisco.com 531 Zach Shelby 532 Sensinode 533 Kidekuja 2 534 Vuokatti 88600 535 FINLAND 537 Phone: +358407796297 538 Email: zach@sensinode.com