idnits 2.17.1 draft-richardson-opsawg-securehomegateway-mud-03.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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. 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 (6 March 2020) is 1484 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-37 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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: 7 September 2020 CIRA Labs 6 H. Habibi Gharakheili 7 UNSW Sydney 8 6 March 2020 10 Loading MUD URLs from QR codes 11 draft-richardson-opsawg-securehomegateway-mud-03 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 The document describes extensions to the WiFi Alliance DPP QR code to 20 support the use of MUD URLs. 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 7 September 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Generic URL or Version Specific URL . . . . . . . . . . . . . 4 59 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 9.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 The Manufacturer Usage Description (MUD) [RFC8520] defines a YANG 71 data model to express what sort of access a device requires to 72 operate correctly. The document additionally defines three ways for 73 the device to communicate the URL of the resulting JSON [RFC8259] 74 format file to a network enforcement point: DHCP, within an X.509 75 certificate extension, and via LLDP. 77 Each of the above mechanism conveys the MUD URL inband, and requires 78 modifications to the device firmware. Most small IoT devices do not 79 have LLDP, and have very restricted DHCP clients. Adding the LLDP or 80 DHCP options requires at least some minimal configuration change, and 81 possibly entire new subsystems. The X.509 certificateion extension 82 only makes sense to deploy as part of a larger IDevID based 83 [ieee802-1AR] system such as [I-D.ietf-anima-bootstrapping-keyinfra]. 85 In all cases these mechanisms can only be implemented by persons with 86 access to modify and update the firmware of the device. The MUD 87 system was designed to be implemented by Manufacturers afterall! 89 In the meantime there is a chicken or egg problem ([chickenegg]): no 90 manufacturers include MUD URLs in their products as there are no 91 gateways that use them. No gateways include code that processes MUD 92 URLs as no products produce them. 94 The mechanism described here allows any person with physical access 95 to the device to affix a reference to a MUD URL that can later be 96 scanned by an end user. This can be done by the (marketing 97 department) of the Manufacturer, by an outsourced assembler plant, by 98 value added resellers, by a company importing the product (possibly 99 to comply with a local regulation), by a network administrator 100 (perhaps before sending devices home with employees), or even by a 101 retailer as a value added service. 103 The mechanism uses the QRcode, which is informally described in 104 [qrcode]. QR code generators are available as web services 105 ([qrcodewebservice]), or as programs such as [qrencode]. They are 106 formally defined in [isoiec18004]. 108 This document details how the CIRALabs Secure Home Gateway encode MUD 109 URLs as QR codes. 111 Section {#genericfirmware} addresses the question of whether and when 112 the MUD file should be specific to a specific version of the device 113 firmware. 115 The third issue is that an intermediary (ISP, or third-party security 116 service) may want to extend or amend a MUD file received from a 117 manufacturer. In order to maintain an audit trail of changes, a way 118 to encode the previous MUD URL and signature file (and status) is 119 provided. (FOR DISCUSSION) 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 3. Protocol 131 The [dpp] specification from the Wi-Fi Alliance has created a base 132 for a QRcode based enrollment system. This specification extends it 133 to include a MUD URL. 135 The QR code is as specified in section 5.2.1 of [dpp] is repeated 136 here: 138 dpp-qr = “DPP:” [channel-list “;”] [mac “;”] 139 [information “;”] public-key “;;” 141 This is amended as follows: 143 dpp-qr = “DPP:” [channel-list “;”] [channel-list “;”] 144 [mac “;”] [information “;”] public-key 145 [";" mudurl ] “;;” 146 mudurl = "D:" *(%x20-3A / %x3C-7E) ; semicolon not allowed 148 While the ABNF defined in the [dpp] document assumes a specific order 149 (C:, M:, I:, K:), this specification relaxes this so that the tags 150 can come in any order. However, in order to make interoperation with 151 future DPP-only clients as seamless as possible, the MUD extension 152 suggested here are placed after those defined in [dpp]. 154 This document establishes an IANA registry for DPP attributes. 156 The syntax of the QR code definition given above does not permit a 157 semicolon to be included. Semicolons (";") would otherwise be 158 permitted in MUD URLs. This restriction on the content the URL is 159 not considered a concern as it is uncommon to use them in a URL. 161 The URL provided MUST NOT have a query (?) portion present. 163 An IANA registry is created for the attributes below. 165 4. Generic URL or Version Specific URL 167 MUD URLs which are communicated inband by the device, and which are 168 programmed into the device's firmware may provide a firmware specific 169 version of the MUD URL. This has the advantage that the resulting 170 ACLs implemented are specific to the needs of that version of the 171 firmware. 173 If the device evolves, requiring new entries then a failure to use 174 the correct version may result in the device cause false positives in 175 the enforcement point audit trail. This can be a serious problem, as 176 repeated false positives train users/owners to ignore reports. 178 If an older firmware device is described by a newer MUD file, then 179 the possibility is that the device may have permissions that it can 180 never use. Unless those permissions result in the device being open 181 to an attacker, this is not a problem. If the new MUD file has 182 removed or changed permissions (such as because the name of an 183 external resource has changed), then the older device will not be 184 able to access the resource under the old name. 186 The QR code is updated when the device firmware is updated. The URL 187 given in the QR code SHOULD be a reference to the latest version of 188 the MUD file, with no firmware version information. A symbolic name 189 like "/model/latest.json" which is updated by the manufacturer when 190 revisions to the MUD file are made is most appropriate. The 191 manufacturer should be careful to never remove important access 192 rights that older device may need, as the QRcode provided MUD URL is 193 what a freshly unpacked device will use. Such a device will point to 194 the latest MUD URL, but having been a in box for some time, will have 195 an ancient version of the firmware. 197 5. Privacy Considerations 199 The presence of the MUD URL in the QR code reveals the manufacturer 200 of the device, the type or model of the device, and possibly the 201 firmware version of the device. 203 If the QR code is printed on a sticker and is affixed to the device 204 itself, then the QR code does not reveal anything that a human could 205 not have determined by simply examining the device. (Save perhaps 206 the firmware version). The QR code however, may be visible my 207 machine vision systems in the same area. This includes security 208 systems, robotic vacuum cleaners, anyone taking a picture with a 209 camera. Such systems may store the picture(s) in such a way that a 210 future viewer of the image will be able to decode the QR code, 211 possibly through assembly of multiple pictures. The QR code is not, 212 however, a certain indicator that the device is present, only that 213 the QR code sticker that came with the device is present. 215 6. Security Considerations 217 The security of the Device Provisioning Protocol is enhanced when the 218 public key for a device is not available without physical access to 219 the device. Placement of a QR code for use by a MUD controller has 220 no such dependancy, and so such QR codes may be affixed in prominant 221 places on the outside of packaging. This is not a recommended 222 practice as future versions of the sticker may include full DPP 223 information. 225 The QRcode described in this document is identical for all instances 226 of the device, and the stickers may be mass produced. The situation 227 is not the same when a full DPP content is present: each sticker is 228 unique. A manufacturing plant designed to affix MUD URLs may get 229 confused and not be ready for the full DPP. 231 It is recommended that the manufacturing process be designed with the 232 full DPP process -- unique QR codes per device -- initially so that 233 no changes are necessary when/if DPP is introduced. 235 7. IANA Considerations 237 IANA is requested to create a new Registry entitled: "Device 238 Provisioning Protocol Attributes". New items can be added to using 239 Specification Required. In order to conserve space, registrations 240 are expected to be single upper-case ASCII letters, but the Expert 241 Reviewer MAY make exceptions. No entry may contain a colon. All 242 entries beginning with "X" are reserved as Private-Use values. 244 The following items are to be added to the initial table: 246 +--------+--------------+-----------------+ 247 | Letter | Name | Document | 248 +========+==============+=================+ 249 | C | channel-list | [dpp] | 250 +--------+--------------+-----------------+ 251 | M | MAC address | [dpp] | 252 +--------+--------------+-----------------+ 253 | I | information | [dpp] | 254 +--------+--------------+-----------------+ 255 | K | public key | [dpp] | 256 +--------+--------------+-----------------+ 257 | D | MUD URL | [This document] | 258 +--------+--------------+-----------------+ 260 Table 1 262 (EDITORIAL NOTE: the authors of the DPP specification have consented 263 to seeding control to IANA) 265 8. Acknowledgements 267 This work was supported by the Canadian Internet Registration 268 Authority (cira.ca). 270 9. References 272 9.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 280 Description Specification", RFC 8520, 281 DOI 10.17487/RFC8520, March 2019, 282 . 284 [qrcode] Wikipedia, ., "QR Code", December 2019, 285 . 287 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 288 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 289 May 2017, . 291 9.2. Informative References 293 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 294 Interchange Format", STD 90, RFC 8259, 295 DOI 10.17487/RFC8259, December 2017, 296 . 298 [I-D.ietf-anima-bootstrapping-keyinfra] 299 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 300 and K. Watsen, "Bootstrapping Remote Secure Key 301 Infrastructures (BRSKI)", Work in Progress, Internet- 302 Draft, draft-ietf-anima-bootstrapping-keyinfra-37, 26 303 February 2020, . 306 [ieee802-1AR] 307 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 308 2009, . 311 [chickenegg] 312 Wikipedia, ., "Chicken or the egg", December 2019, 313 . 315 [qrcodewebservice] 316 Internet, ., "QR Code Generators", December 2019, 317 . 319 [dpp] "Device Provisioning Protocol Specification", April 2018, 320 . 324 [qrencode] Fukuchi, K., "QR encode", December 2019, 325 . 327 [isoiec18004] 328 ISO/IEC, ., "Information technology - Automatic 329 identification and data capture techniques - QR Code bar 330 code symbology specification (ISO/IEC 18004)", February 331 2015. 333 Authors' Addresses 335 Michael Richardson 336 Sandelman Software Works 338 Email: mcr+ietf@sandelman.ca 340 Jacques Latour 341 CIRA Labs 343 Email: Jacques.Latour@cira.ca 345 Hassan Habibi Gharakheili 346 UNSW Sydney 348 Email: h.habibi@unsw.edu.au