idnits 2.17.1 draft-richardson-mud-qrcode-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 date (17 December 2020) is 1225 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPS Area Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Informational J. Latour 5 Expires: 20 June 2021 CIRA Labs 6 H. Habibi Gharakheili 7 UNSW Sydney 8 17 December 2020 10 On loading MUD URLs from QR codes 11 draft-richardson-mud-qrcode-00 13 Abstract 15 This informational document details the mechanism used by the CIRA 16 Secure Home Gateway (SHG) to load MUD definitions for devices which 17 have no integrated MUD (RFC8520) support. 19 RFCEDITOR please remove: Pull requests and edit welcome at: 20 https://github.com/CIRALabs/securehomegateway-mud/tree/ietf 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 https://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 20 June 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. The SQRL protocol . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Manufacturer Usage Descriptions in SQRL . . . . . . . . . 5 60 3.2.1. B000 Company Name . . . . . . . . . . . . . . . . . . 5 61 3.2.2. B001 Product Name . . . . . . . . . . . . . . . . . . 5 62 3.2.3. B002 Model Number . . . . . . . . . . . . . . . . . . 5 63 3.2.4. MUD URL Data Record . . . . . . . . . . . . . . . . . 5 64 3.2.5. MUD device MAC address . . . . . . . . . . . . . . . 6 65 4. Generic URL or Version Specific URL . . . . . . . . . . . . . 6 66 5. Crowd Supply of MUD Files . . . . . . . . . . . . . . . . . . 6 67 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 10. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 11.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 The Manufacturer Usage Description (MUD) [RFC8520] defines a YANG 80 data model to express what sort of access a device requires to 81 operate correctly. The document additionally defines three ways for 82 the device to communicate the URL of the resulting JSON [RFC8259] 83 format file to a network enforcement point: DHCP, within an X.509 84 certificate extension, and via LLDP. 86 Each of the above mechanism conveys the MUD URL in-band, and requires 87 modifications to the device firmware. Most small IoT devices do not 88 have LLDP, and often have very restricted DHCP clients. Adding the 89 LLDP or DHCP options requires at least some minimal configuration 90 change, and possibly entire new subsystems. Meanwhile, use of the 91 PKIX certification extension only makes sense as part of a larger 92 IDevID based [ieee802-1AR] deployment such as 93 [I-D.ietf-anima-bootstrapping-keyinfra]. 95 In the above cases these mechanisms can only be implemented by 96 persons with access to modify and update the firmware of the device. 97 The MUD system was designed to be implemented by Manufacturers after 98 all! 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 mechanism described here allows any person with physical access 106 to 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 The mechanism described herein uses a QRcode, which is informally 126 described in [qrcode], but specifically leverages the data format 127 from Reverse Logistics Association's [SQRL] system. This is an 128 application of the 12N Data Identifier system specified by the ANSI 129 MH10.8.2 Committee in a format appropriate for QRcodes as well as 130 other things like NFCs transmissions. 132 QR code generators are available as web services 133 ([qrcodewebservice]), or as programs such as [qrencode]. They are 134 formally defined in [isoiec18004]. 136 Section {#genericfirmware} summarizes the recommendations 137 [I-D.richardson-opsawg-mud-acceptable-urls] section 2 ("Updating MUD 138 URLs vs Updating MUD files"). The question as to whether the MUD 139 file should be specific to a specific version of the device firmware 140 is considered in the context of affixed external labels. 142 A third issue is that an intermediary (ISP, or third-party security 143 service) may want to extend or amend a MUD file received from a 144 manufacturer. In order to maintain an audit trail of changes, a way 145 to encode the previous MUD URL and signature file (and status) is 146 provided. (FOR DISCUSSION) 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in 153 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 3. Protocol 158 This QRcode protocol builds upon the work by [SQRL]. That protocol 159 is very briefly described in the next section. Then the list of 160 needed Data Records to be filled in is explained. 162 3.1. The SQRL protocol 164 [SQRL] documents an octet protocol that can be efficiently encoded 165 into QRcodes using a sequence of ASCII bytes, plus five control codes 166 (see section 3.1 of [SQRL]): 168 * Record Separator (ASCII 30) 170 * End of Transmission (ASCII 4) 172 * Field Separator (ASCII 28) 174 * Group Separator (ASCII 29) 176 * Unit Separator (ASCII 31), 178 * Concatenation Operator (ASCII 43: "+"). 180 Section 7.2 of [SQRL] gives the details, which can be summarized as: 182 1. The QR code header starts with: 184 "[)>" "06" "12N" 186 1. Include one or more Data Records. This consists of a four letter 187 Field Identifiers followed by ASCII characters terminated with a 188 . 190 2. End with: 192 194 There are, additionally optional flags that may be present in every 195 Data Record as described in section 7.4. As there is little use for 196 this in the context of MUD URLs, they can likely be ignored by 197 parsers that are not parsing any of the rest of the information. A 198 parser that sees a Field Separator in the stream SHOULD ignore the 199 characters collected so far and then continue parsing to get the user 200 data. 202 Environment records, as described in section 7.4, look and act 203 exactly as fields, with a special Field Identifier. They serve no 204 purpose when looking for MUD information, and MAY be ignored. 206 3.2. Manufacturer Usage Descriptions in SQRL 208 3.2.1. B000 Company Name 210 The B000 Data Record is mandatory in [SQRL]. It should be an ASCII 211 representation of the company or brand name. It should match the 212 ietf-mud/mud/mfg-name in the MUD file. 214 3.2.2. B001 Product Name 216 The B001 Data Record is optional. It is the Product Name in ASCII. 217 It's presence is strongly RECOMMENDED. 219 3.2.3. B002 Model Number 221 The B002 Data Record is optional in [SQRL], but is MANDATORY in this 222 profile. It is the Model Name in ASCII. It should match the ietf- 223 mud/mud/model-name in the MUD file, if it is present. 225 3.2.4. MUD URL Data Record 227 A new Field Identifier has been assigned by the RLA, which is "M180" 228 This record should be filled with the MUD URL. Shorter is better. 229 Section 8.1 of [SQRL] has some good advice on longevity concerns with 230 URLs. 232 The URL provided MUST NOT have a query (?) portion present. 234 3.2.5. MUD device MAC address 236 In order for the MUD controller to associate the above policy with a 237 specific device, then some unique identifier must be provided to the 238 MUD controller. The most actionable identifier is the Ethernet MAC 239 address. [SQRL] section 9.10 defines the Data Record: "M06C" as the 240 MAC address. No format for the MAC address is provided in the 241 document. 243 The recommended format in order to conserve space is 12 or 16 hex 244 octets. (16 octets for the newer IEEE OUI-64 format used in 802.15.4, 245 and some next generation Ethernet proposals) 247 The parser SHOULD be tolerant of extra characters: colons (":"), 248 dashes ("-"), and white space. 250 4. Generic URL or Version Specific URL 252 MUD URLs which are communicated in-band by the device, and which are 253 programmed into the device's firmware may provide a firmware specific 254 version of the MUD URL. This has the advantage that the resulting 255 ACLs implemented are specific to the needs of that version of the 256 firmware. 258 A MUD URL which is affixed to the device with a sticker, or etched 259 into the case can not be changed. 261 Given the considerations of 262 [I-D.richardson-opsawg-mud-acceptable-urls] section 2.1 ("Updating 263 the MUD file in place"), it is prudent to use a MUD URL which points 264 to a MUD file which will only have new features added over time, and 265 never removed. 267 When the firmware eventually receives built-in MUD URL support, then 268 a more specific URL may be used. 270 Note that in many cases it will be third parties who are generating 271 these QRcodes, so the MUD file may be hosted by the third party. 273 5. Crowd Supply of MUD Files 275 The IETF MUD is a new standard. Hence, IoT device manufacturers have 276 not yet provided MUD profiles for their devices. A research group at 277 the University of New South Wales (UNSW Sydney) has developed an 278 open-source tool, called MUDgee ([MUDgee]), which automatically 279 generates a MUD file (profile) for an IoT device from its traffic 280 trace in order to make this process faster, easier, and more 281 accurate. Note that the generated profile completeness solely 282 depends on the completeness of the input traffic traces. MUDgee 283 assumes that all the activity seen is intended and benign. 285 UNSW researchers have applied MUDgee about 30 consumer IoT devices 286 from their lab testbed, and publicly released their MUD files 287 ([MUDfiles]). MUDgee can assist IoT manufacturers in developing and 288 verifying MUD profiles, while also helping adopters of these devices 289 to ensure they are compatible with their organisational policies. 291 6. Privacy Considerations 293 The presence of the MUD URL in the QR code reveals the manufacturer 294 of the device, the type or model of the device, and possibly the 295 firmware version of the device. 297 The MAC address of the device will also need to be present, and this 298 is potentially Personally Identifiable Information (PII). Such 299 QRcodes should not be placed on the outside of the packaging, and 300 only on the device itself, ideally on a non-prominent part of the 301 device. (e.g., the bottom). 303 The QR code sticker should not placed on any part of the device that 304 might become visible to machine vision systems in the same area. 305 This includes security systems, robotic vacuum cleaners, anyone 306 taking a picture with a camera. Such systems may store the 307 picture(s) in such a way that a future viewer of the image will be 308 able to decode the QR code, possibly through assembly of multiple 309 pictures. Of course, the QR code is not, however, a certain 310 indicator that the device is present, only that the QR code sticker 311 that came with the device is present. 313 7. Security Considerations 315 To Be Determined. 317 8. IANA Considerations 319 This document makes no IANA actions. 321 9. Acknowledgements 323 This work was supported by the Canadian Internet Registration 324 Authority (cira.ca). 326 10. History 328 Previous versions of this work leveraged the QRcode format from the 329 WiFi Alliance DPP specification. This document no longer uses that. 331 11. References 333 11.1. Normative References 335 [qrcode] Wikipedia, "QR Code", December 2019, 336 . 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, 340 DOI 10.17487/RFC2119, March 1997, 341 . 343 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 344 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 345 May 2017, . 347 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 348 Description Specification", RFC 8520, 349 DOI 10.17487/RFC8520, March 2019, 350 . 352 [SQRL] Reverse Logistics Association, "SQRL Codes: Standardized 353 Quick Response for Logistics, Using the 12N Data 354 Identifier", February 2017, 355 . 357 11.2. Informative References 359 [chickenegg] 360 Wikipedia, "Chicken or the egg", December 2019, 361 . 363 [I-D.ietf-anima-bootstrapping-keyinfra] 364 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 365 and K. Watsen, "Bootstrapping Remote Secure Key 366 Infrastructures (BRSKI)", Work in Progress, Internet- 367 Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11 368 November 2020, . 371 [I-D.richardson-opsawg-mud-acceptable-urls] 372 Richardson, M., Yang, J., and E. Lear, "Authorized update 373 to MUD URLs", Work in Progress, Internet-Draft, draft- 374 richardson-opsawg-mud-acceptable-urls-03, 2 November 2020, 375 . 378 [ieee802-1AR] 379 IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 380 2009, . 383 [isoiec18004] 384 ISO/IEC, "Information technology - Automatic 385 identification and data capture techniques - QR Code bar 386 code symbology specification (ISO/IEC 18004)", February 387 2015. 389 [MUDfiles] UNSW Sydney, ., "MUD Profiles", July 2019, 390 . 392 [MUDgee] Hamza, A., "MUDgee", July 2019, 393 . 395 [qrcodewebservice] 396 Internet, "QR Code Generators", December 2019, 397 . 399 [qrencode] Fukuchi, K., "QR encode", December 2019, 400 . 402 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 403 Interchange Format", STD 90, RFC 8259, 404 DOI 10.17487/RFC8259, December 2017, 405 . 407 Authors' Addresses 409 Michael Richardson 410 Sandelman Software Works 412 Email: mcr+ietf@sandelman.ca 414 Jacques Latour 415 CIRA Labs 417 Email: Jacques.Latour@cira.ca 419 Hassan Habibi Gharakheili 420 UNSW Sydney 422 Email: h.habibi@unsw.edu.au