idnits 2.17.1 draft-richardson-mud-qrcode-01.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 date (13 May 2021) is 1078 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-opsawg-mud-acceptable-urls-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Informational J. Latour 5 Expires: 14 November 2021 CIRA Labs 6 H. Habibi Gharakheili 7 UNSW Sydney 8 13 May 2021 10 On loading MUD URLs from QR codes 11 draft-richardson-mud-qrcode-01 13 Abstract 15 This informational document details a protocol to load MUD 16 definitions for devices which have no integrated MUD (RFC8520) 17 support. 19 This document is published to inform the Internet community of this 20 mechanism to allow interoperability and to serve as a basis of other 21 standards work if there is interest. 23 RFCEDITOR please remove: Pull requests and edit welcome at: 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 14 November 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. The SQRL Protocol . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Manufacturer Usage Descriptions in SQRL . . . . . . . . . 5 63 3.2.1. B000 Company Name . . . . . . . . . . . . . . . . . . 5 64 3.2.2. B001 Product Name . . . . . . . . . . . . . . . . . . 6 65 3.2.3. B002 Model Number . . . . . . . . . . . . . . . . . . 6 66 3.2.4. MUD URL Data Record . . . . . . . . . . . . . . . . . 6 67 3.2.5. MUD Device MAC Address . . . . . . . . . . . . . . . 6 68 4. Generic URL or Version Specific URL . . . . . . . . . . . . . 7 69 5. Crowd Supply of MUD Files . . . . . . . . . . . . . . . . . . 7 70 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 10.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The Manufacturer Usage Description (MUD) [RFC8520] defines a YANG 82 data model to express what sort of access a device requires to 83 operate correctly. That document additionally defines three ways for 84 the device to communicate the URL of the resulting JSON [RFC8259] 85 format file to a network enforcement point: DHCP, within an X.509 86 certificate extension, and via LLDP. 88 Each of the above mechanism conveys the MUD URL in-band, and requires 89 modifications to the device firmware. Most small IoT devices do not 90 have LLDP, and often have very restricted DHCP clients. Adding the 91 LLDP or DHCP options requires at least some minimal configuration 92 change, and possibly entire new subsystems. Meanwhile, use of the 93 PKIX certification extension only makes sense as part of a larger 94 IDevID based [ieee802-1AR] deployment such as 95 [I-D.ietf-anima-bootstrapping-keyinfra]. 97 In the above cases these mechanisms can only be implemented by 98 persons with access to modify and update the firmware of the device. 100 In the meantime there is a chicken or egg problem ([chickenegg]): no 101 manufacturers include MUD URLs in their products as there are no 102 gateways that use them. No gateways include code that processes MUD 103 URLs as no products produce them. 105 The protocol described here allows any person with physical access to 106 the device to affix a reference to a MUD URL that can later be 107 scanned by an end user. 109 Such an action can be done by 111 * the marketing department of the Manufacturer, 113 * an outsourced assembler plant, 115 * value added resellers (perhaps in response to a local RFP), 117 * a company importing the product (possibly to comply with a local 118 regulation), 120 * a network administrator (perhaps before sending devices home with 121 employees, or to remote sites), 123 * a retailer as a value added service. 125 QRcodes are informally described in [qrcode] and formally defined in 126 [isoiec18004]. The protocol described in this document uses a QRcode 127 to encode the MUD URL. Specifically, the protocol leverages the data 128 format from the Reverse Logistics Association's Standardized Quick 129 Response for Logistics [SQRL]. 131 SQRL codes are being put on devices via sticker or via laser etching 132 into the case in order to deal with many situations, but specifically 133 for end-of-life processing for the device. An important idea behind 134 the effort is that clearly identifying a product permits appropriate 135 disposal, refurbishment or recycling of the components of the 136 product. 138 There are also use cases for SQRL described in which the codes are 139 used as part of regular maintenance for a product. 141 SQRL is an application of the 12N Data Identifier system specified by 142 the ANSI MH10.8.2 Committee [mh10] in a format appropriate for 143 QRcodes as well as other things like NFCs transmissions. 145 QRcode generators are available as web services [qrcodewebservice], 146 or as programs such as [qrencode]. 148 Section 4 summarizes the considerations contained in 149 [I-D.ietf-opsawg-mud-acceptable-urls] section 6.1 ("Updating MUD URLs 150 vs Updating MUD files"). Due to the immutable nature of the QRcode, 151 MUD URLs in this document will need to non-firmware specific. 153 2. Terminology 155 Although this document is not an IETF Standards Track publication it 156 adopts the conventions for normative language to provide clarity of 157 instructions to the implementer. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in 162 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 163 capitals, as shown here. 165 3. Protocol 167 This QRcode protocol builds upon the work by [SQRL]. That protocol 168 is very briefly described in the next section. Then the list of 169 needed Data Records to be filled in is explained. 171 3.1. The SQRL Protocol 173 [SQRL] documents an octet protocol that can be efficiently encoded 174 into QRcodes using a sequence of ASCII bytes, plus six control codes 175 (see section 3.1 of [SQRL]): 177 * Record Separator (ASCII 30) 178 * End of Transmission (ASCII 4) 180 * Field Separator (ASCII 28) 182 * Group Separator (ASCII 29) 184 * Unit Separator (ASCII 31), 186 * Concatenation Operator (ASCII 43: "+"). 188 Section 7.2 of [SQRL] gives the details, which can be summarized as: 190 1. The QR code header starts with: 192 "[)>" "06" "12N" 194 1. Include one or more Data Records. This consists of a four letter 195 Field Identifiers followed by ASCII characters terminated with a 196 . 198 2. End with: 200 202 There are additionally optional flags that may be present in every 203 Data Record as described in section 7.4 of [SQRL]. These flags have 204 no bearing on MUD processing. A parser which is only collecting MUD 205 URLs will not need to parse those flags. A general purpose SQRL 206 parser will need more complexity. 208 Field Seperator characters are used in SQRL to signify the beginning 209 of a new unit of data. A MUD specific parser that encounters a Field 210 Seperator and has not yet collected the right MUD information MUST 211 ignore the characters collected so far and then restart. 213 Environment records, as described in [SQRL] section 7.4, look and act 214 exactly as fields, with a special Field Identifier. They serve no 215 purpose when looking for MUD information, and MAY be ignored. 217 3.2. Manufacturer Usage Descriptions in SQRL 219 3.2.1. B000 Company Name 221 The B000 Data Record is mandatory in [SQRL]. It MUST be in ASCII 222 representation. It should be a representation of the company or 223 brand name. It SHOULD match the ietf-mud/mud/mfg-name in the MUD 224 file, however the MUD file can contain arbitrary UTF8 for this name, 225 while the SQRL files are expected to be 7-bit US-ASCII. 227 3.2.2. B001 Product Name 229 The B001 Data Record is optional in [SQRL]. It's presence is 230 RECOMMENDED. Some third parties that create QRcode stickers might 231 not know the product name with 100% certainty, and MAY prefer to omit 232 this rather than create further confusion. It is the Product Name in 233 ASCII. 235 3.2.3. B002 Model Number 237 The B002 Data Record is optional in [SQRL], but is MANDATORY in this 238 profile. It is the Model Name in ASCII. It SHOULD match the 239 optional ietf-mud/mud/model-name in the MUD file if that entry is 240 present in the MUD file. 242 If a third party that is creating QRcodes can not locate an official 243 model number when creating their MUD file and QRcode, then the third 244 party SHOULD make one up. 246 3.2.4. MUD URL Data Record 248 A new Field Identifier has been assigned by the Reverse Logistics 249 Association (RLA), which is "M180" This record MUST be filled with 250 the MUD URL. 252 Short URLs are easier to encode into QRcode because they require 253 fewer pixels of QRcode. More content in the QRcode requires a bigger 254 image. 256 Use of URL shortening services (see [URLshorten]) can be useful 257 provided that the service is stable throughout the lifetime of the 258 device and QRcode, and that the privacy stance of the service is well 259 understood. 261 Section 8.1 of [SQRL] also has some good advice on longevity concerns 262 with URLs. 264 The URL provided MUST NOT have a query (?) portion present. If one 265 is present, the query portion MUST be removed before processing. 267 3.2.5. MUD Device MAC Address 269 In order for the MUD controller to associate the above policy with a 270 specific device, some unique identifier must be provided to the MUD 271 controller. The most actionable identifier is the Ethernet MAC 272 address. [SQRL] section 9.10 defines the Data Record: "M06C" as the 273 MAC address. No format for the MAC address is provided in that 274 document. 276 This document RECOMMENDS 12 (or 16) hex octets are used with no 277 spaces or punctuation. (16 octets are used in the IEEE OUI-64 format 278 used in 802.15.4, and some next generation Ethernet proposals) 280 Parsers that find punctuation (such as colons (":"), dashes ("-"), or 281 white space) MUST skip over it. 283 4. Generic URL or Version Specific URL 285 MUD URLs which are communicated in-band by the device, and which are 286 programmed into the device's firmware may provide a firmware specific 287 version of the MUD URL. This has the advantage that the resulting 288 Access Control Lists (ACLs) implemented are specific to the needs of 289 that version of the firmware. 291 A MUD URL which is affixed to the device with a sticker, or etched 292 into the case can not be changed. 294 Given the considerations of [I-D.ietf-opsawg-mud-acceptable-urls] 295 section 6.1 ("Updating MUD URLs vs Updating MUD files"), it is 296 prudent to use a MUD URL which points to a MUD file which will only 297 have new features added over time, and never have features removed. 299 When the firmware eventually receives built-in MUD URL support, then 300 a more specific URL may be used. 302 Note that in many cases it will be third parties who are generating 303 these QRcodes, so the MUD file may be hosted by the third party. 305 5. Crowd Supply of MUD Files 307 At the time of writing, the IETF MUD is a new IETF Proposed Standard. 308 Hence, IoT device manufacturers have not yet provided MUD profiles 309 for their devices. A research group at the University of New South 310 Wales (UNSW Sydney) has developed an open-source tool, called MUDgee 311 ([MUDgee]), which automatically generates a MUD file (profile) for an 312 IoT device from its traffic trace in order to make this process 313 faster, easier, and more accurate. Note that the generated profile 314 completeness solely depends on the completeness of the input traffic 315 traces. MUDgee assumes that all the activity seen is intended and 316 benign. 318 UNSW researchers have applied MUDgee about 30 consumer IoT devices 319 from their lab testbed, and publicly released their MUD files 320 ([MUDfiles]). MUDgee can assist IoT manufacturers in developing and 321 verifying MUD profiles, while also helping adopters of these devices 322 to ensure they are compatible with their organisational policies. 324 Similar processes have been done in a number of other public and 325 private labs. One of the strong motivations for this specification 326 is to allow for this work to leave the lab, to be applied in the 327 field. 329 6. Privacy Considerations 331 The presence of the MUD URL in the QR code reveals the manufacturer 332 of the device, the type or model of the device, and possibly the 333 firmware version of the device. 335 The MAC address of the device will also need to be present, and this 336 is potentially Personally Identifiable Information (PII). Such 337 QRcodes should not be placed on the outside of the packaging, and 338 only on the device itself, ideally on a non-prominent part of the 339 device. (e.g., the bottom). 341 The QR code sticker should not placed on any part of the device that 342 might become visible to machine vision systems in the same area. 343 This includes security systems, robotic vacuum cleaners, anyone 344 taking a picture with a camera. Such systems may store the 345 picture(s) in such a way that a future viewer of the image will be 346 able to decode the QR code, possibly through assembly of multiple 347 pictures. Of course, the QR code is not, however, a certain 348 indicator that the device is present, only that the QR code sticker 349 that came with the device is present. 351 7. Security Considerations 353 The mere presence of at QRcode on a device does not in itself create 354 any security issues on its own. Neither an attached paper sticker or 355 a laser etched code in a plastic case will not affect the device 356 operation. The QRcode is not active, it is not in general able to 357 communicate on nearby networks. It is conceivable that something 358 more active is concealed in the sticker: an NFC or RFID tag for 359 instance. But, any sticker could contain such a thing: on some 360 university campuses stickers are often used as part of political 361 campaigns, and can be found attached all over the place. 363 Security issues that this protocol create are related to assumptions 364 that the presence of the QRcode might imply. The presence of the 365 QRcode may imply to some owners or network operators that the 366 behaviour of the device has been vetted by some authority. It is 367 here that some caution is required. 369 The network operator who takes the MUD file designated by the QRcode 370 needs to be careful that they are validating the signature on the MUD 371 file. Not only that the file is intact, but that the signer of the 372 file is authorized to sign MUD files for that vendor, or that the 373 network operator has some trust if the MUD file is a crowd sourced 374 definition. At the time of writing, [RFC8520] does not define any 375 infrastructure to authenticate or authorize MUD file signers. 377 A possibly bigger risk from application of MUD file stickers to 378 devices is that they may begin to convey a sense of safety to users 379 of the device. The presence of the sticker, possibly with the logo 380 of the physical establishment in which the device is located could 381 convey to occupants of the establishment that this device is an 382 official device. For instance, a university which only deploys 383 sensors on the university campus that have been vetted for compliance 384 against a MUD definition. 386 The risk is then of social engineering: any device with a reasonable 387 looking QRcode may become a trusted device. An attacker that wishes 388 to infiltrate their own devices need only suitably camoflage the 389 device with an appropriate sticker in order to convey legitimacy. 391 Another issue with the stickers is that the wrong sticker could be 392 applied to a device by a reseller or other trusted party, either in 393 error, or via some physical or socially engineered attack against 394 that party. The network operator now onboards a device, and applies 395 what they think is a legitimate network policy for the device in 396 their hands, only it is in fact a policy for another kind of device. 398 Inclusion of the device specific MAC address (described in 399 Section 3.2.5) in the QRcode makes use of the MUD code much easier as 400 it identifies the device specifically. If the MAC addresss is not 401 included, then a network operator, having the device in their hands, 402 then has to associate the policy with the device through some other 403 interface. 405 Despite the significant advantage of having the MAC address include, 406 it is unlikely that third party stickers will include that. 407 Including the MAC address requires that the QRcode for that device 408 requires that a unique sticker be created for each device. This is 409 possible if the sticker is applied by a manufacturer: it is already 410 common to have a serial number and MAC address on the outside of the 411 device. In that case, if the QRcode is part of that sticker, then 412 the customization problem is not that complex. 414 For cases where a third party has produced the QRcode, it is likely 415 that every device of a particular model will have the same QRcode 416 applied, omitting the MAC address. This makes it more likely that a 417 policy will be applied to the wrong device. 419 8. IANA Considerations 421 This document makes no request for IANA actions. 423 9. Acknowledgements 425 This work was supported by the Canadian Internet Registration 426 Authority (cira.ca). 428 10. References 430 10.1. Normative References 432 [qrcode] Wikipedia, "QR Code", December 2019, 433 . 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, 437 DOI 10.17487/RFC2119, March 1997, 438 . 440 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 441 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 442 May 2017, . 444 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 445 Description Specification", RFC 8520, 446 DOI 10.17487/RFC8520, March 2019, 447 . 449 [SQRL] Reverse Logistics Association, "SQRL Codes: Standardized 450 Quick Response for Logistics, Using the 12N Data 451 Identifier", February 2017, 452 . 454 10.2. Informative References 456 [chickenegg] 457 Wikipedia, "Chicken or the egg", December 2019, 458 . 460 [I-D.ietf-anima-bootstrapping-keyinfra] 461 Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. 462 H., and K. Watsen, "Bootstrapping Remote Secure Key 463 Infrastructures (BRSKI)", Work in Progress, Internet- 464 Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11 465 November 2020, . 468 [I-D.ietf-opsawg-mud-acceptable-urls] 469 Richardson, M., Pan, W., and E. Lear, "Authorized update 470 to MUD URLs", Work in Progress, Internet-Draft, draft- 471 ietf-opsawg-mud-acceptable-urls-03, 19 February 2021, 472 . 475 [ieee802-1AR] 476 IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 477 2009, . 480 [isoiec18004] 481 ISO/IEC, "Information technology - Automatic 482 identification and data capture techniques - QR Code bar 483 code symbology specification (ISO/IEC 18004)", February 484 2015. 486 [mh10] "ANSI MH10.8.2 Committee", May 2021, 487 . 489 [MUDfiles] UNSW Sydney, ., "MUD Profiles", July 2019, 490 . 492 [MUDgee] Hamza, A., "MUDgee", July 2019, 493 . 495 [qrcodewebservice] 496 Internet, "QR Code Generators", December 2019, 497 . 499 [qrencode] Fukuchi, K., "QR encode", December 2019, 500 . 502 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 503 Interchange Format", STD 90, RFC 8259, 504 DOI 10.17487/RFC8259, December 2017, 505 . 507 [URLshorten] 508 Wikipedia, "URL shortening", May 2021, 509 . 511 Authors' Addresses 513 Michael Richardson 514 Sandelman Software Works 515 Email: mcr+ietf@sandelman.ca 517 Jacques Latour 518 CIRA Labs 520 Email: Jacques.Latour@cira.ca 522 Hassan Habibi Gharakheili 523 UNSW Sydney 525 Email: h.habibi@unsw.edu.au