idnits 2.17.1 draft-arkko-core-dev-urn-02.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 7, 2012) is 4283 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 337, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 340, 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) -- 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 (-10) exists of draft-farrell-decade-ni-09 == 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 (~~), 9 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 8, 2013 Cisco 6 Z. Shelby 7 Sensinode 8 July 7, 2012 10 Uniform Resource Names for Device Identifiers 11 draft-arkko-core-dev-urn-02 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 8, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 6 62 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 10 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 [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, [I-D.farrell-decade-ni] 92 defines cryptographic identifiers, [I-D.montemurro-gsma-imei-urn] 93 defines International Mobile station Equipment Identity (IMEI) 94 identifiers for use with 3GPP cellular systems, and 95 [I-D.atarius-dispatch-meid-urn] defines Mobile Equipment Identity 96 (MEID) identifiers for use with 3GPP2 cellular systems. Those URN 97 types should be employed when such identities are transported; this 98 memo does not redefine these identifiers in any 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 and 1-wire device identifiers. Section 5 117 gives examples. Section 6 discusses the security considerations of 118 the new URN type. Finally, Section 7 specifies the IANA registration 119 for the new URN type and sets requirements for subtype allocations 120 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:" body componentpart 147 body = macbody / owbody / otherbody 148 macbody = "mac:" hexstring 149 owbody = "ow:" hexstring 150 otherbody = subtype ":" identifier 151 subtype = ALPHA *(DIGIT / ALPHA) 152 identifier = 1*unreserved 153 componentpart = [ ";" component [ componentpart ]] 154 component = *1(DIGIT / ALPHA) 155 hexstring = hexbyte / 156 hexbyte hexstring 157 hexbyte = hexdigit hexdigit 158 hexdigit = DIGIT / hexletter 159 hexletter = "a" / "b" / "c" / "d" / "e" / "f" 161 The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA 162 rules defined in [RFC5234], which are not repeated here. The rule 163 for unreserved is defined in Section 2.3 of [RFC3986]. 165 The device identity namespace includes three subtypes, and more may 166 be defined in the future as specified in Section 7. 168 The optional components following the hexstring are strings depicting 169 individual aspects of a device. The specific strings and their 170 semantics are up to the designers of the device, but could be used to 171 refer to specific interfaces or functions within the device. 173 Relevant ancillary documentation: See Section 4. 175 Identifier uniqueness considerations: Device identifiers are 176 generally expected to be unique, barring the accidental issue of 177 multiple devices with the same identifiers. 179 Identifier persistence considerations: This URN type SHOULD only be 180 used for persistent identifiers, such as hardware-based identifiers 181 or cryptographic identifiers based on keys intended for long-term 182 usage. 184 Process of identifier assignment: The process for identifier 185 assignment is dependent on the used subtype, and documented in the 186 specific subsection under Section 4. 188 Process for identifier resolution: The device identities are not 189 expected to be globally resolvable. No identity resolution system is 190 expected. Systems may perform local matching of identities to 191 previously seen identities or configured information, however. 193 Rules for Lexical Equivalence: The lexical equivalence of the DEV URN 194 is defined as an exact and case sensitive string match. Note that 195 the two subtypes defined in this document use only lower case 196 letters, however. Future types might use identifiers that require 197 other encodings that require a more full-blown character set (such as 198 BASE64), however. 200 Conformance with URN Syntax: The string representation of the device 201 identity URN and of the MEID sub namespace is fully compatible with 202 the URN syntax. 204 Validation Mechanism: Specific subtypes may be validated through 205 mechanisms discussed in Section 4. 207 Scope: DEV URN is global in scope. 209 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 # humidity 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997. 299 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 301 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 302 "Uniform Resource Names (URN) Namespace Definition 303 Mechanisms", BCP 66, RFC 3406, October 2002. 305 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 306 Resource Identifier (URI): Generic Syntax", STD 66, 307 RFC 3986, January 2005. 309 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 310 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 311 May 2008. 313 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 314 Specifications: ABNF", STD 68, RFC 5234, January 2008. 316 [IEEE.EUI64] 317 IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", 318 IEEE , 319 . 321 [OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use", 322 MAXIM 323 http://www.maxim-ic.com/app-notes/index.mvp/id/1796, 324 . 326 8.2. Informative References 328 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 329 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 330 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 332 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 333 A., Peterson, J., Sparks, R., Handley, M., and E. 334 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 335 June 2002. 337 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 338 Neighbor Discovery (SEND)", RFC 3971, March 2005. 340 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 341 RFC 3972, March 2005. 343 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 344 Unique IDentifier (UUID) URN Namespace", RFC 4122, 345 July 2005. 347 [RFC4627] Crockford, D., "The application/json Media Type for 348 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 350 [W3C.REC-xml-19980210] 351 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 352 Recommendation", World Wide Web Consortium 353 FirstEdition REC-xml-19980210, February 1998, 354 . 356 [I-D.ietf-core-coap] 357 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 358 "Constrained Application Protocol (CoAP)", 359 draft-ietf-core-coap-06 (work in progress), May 2011. 361 [I-D.jennings-senml] 362 Jennings, C., "Media Type for Sensor Markup Language 363 (SENML)", draft-jennings-senml-05 (work in progress), 364 March 2011. 366 [I-D.farrell-decade-ni] 367 Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 368 Keranen, A., and P. Hallam-Baker, "Naming Things with 369 Hashes", draft-farrell-decade-ni-09 (work in progress), 370 July 2012. 372 [I-D.arkko-core-sleepy-sensors] 373 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 374 Novo, "Implementing Tiny COAP Sensors", 375 draft-arkko-core-sleepy-sensors-01 (work in progress), 376 July 2011. 378 [I-D.arkko-core-security-arch] 379 Arkko, J. and A. Keranen, "CoAP Security Architecture", 380 draft-arkko-core-security-arch-00 (work in progress), 381 July 2011. 383 [I-D.montemurro-gsma-imei-urn] 384 Montemurro, M., "A Uniform Resource Name Namespace For The 385 GSM Association (GSMA) and the International Mobile 386 station Equipment Identity(IMEI)", 387 draft-montemurro-gsma-imei-urn-01 (work in progress), 388 February 2007. 390 [I-D.atarius-dispatch-meid-urn] 391 Atarius, R., "A Uniform Resource Name Namespace for the 392 Device Identity and the Mobile Equipment Identity (MEID)", 393 draft-atarius-dispatch-meid-urn-01 (work in progress), 394 August 2011. 396 Appendix A. Changes from Previous Version 398 Version -02 introduced several changes. The biggest change is that 399 with the NI URNs [I-D.farrell-decade-ni], it was no longer necessary 400 to define cryptographic identifiers in this specification. Another 401 change was that we incorporated a more generic syntax for future 402 extensions; non-hexstring identifiers can now also be supported, if 403 some future device identifiers for some reason would, for instance, 404 use BASE64. As a part of this change, we also changed the component 405 part separator character from '-' to ';' so that the general format 406 of the rest of the URN can employ the unreserved characters 407 [RFC3986]. 409 Appendix B. Acknowledgments 411 The authors would like to thank Ari Keranen, Stephen Farrell, 412 Christer Holmberg, Peter Saint-Andre, and Ahmad Muhanna for 413 interesting discussions in this problem space. We would also like to 414 note prior documents that focused on specific device identifiers, 415 such as [I-D.montemurro-gsma-imei-urn] or 416 [I-D.atarius-dispatch-meid-urn]. 418 Authors' Addresses 420 Jari Arkko 421 Ericsson 422 Jorvas 02420 423 Finland 425 Email: jari.arkko@piuha.net 427 Cullen Jennings 428 Cisco 429 170 West Tasman Drive 430 San Jose, CA 95134 431 USA 433 Phone: +1 408 421-9990 434 Email: fluffy@cisco.com 435 Zach Shelby 436 Sensinode 437 Kidekuja 2 438 Vuokatti 88600 439 FINLAND 441 Phone: +358407796297 442 Email: zach@sensinode.com