idnits 2.17.1 draft-richardson-opsawg-securehomegateway-mud-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: ---------------------------------------------------------------------------- == 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 (27 December 2019) is 1554 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-31 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6tisch Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Informational J. Latour 5 Expires: 29 June 2020 CIRA Labs 6 27 December 2019 8 Loading MUD URLs from QR codes 9 draft-richardson-opsawg-securehomegateway-mud-02 11 Abstract 13 This informational document details the mechanism used by the CIRA 14 Secure Home Gateway (SHG) to load MUD definitions for devices which 15 have no integrated MUD (RFC8520) support. 17 The document describes extensions to the WiFi Alliance DPP QR code to 18 support the use of MUD URLs. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 29 June 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 8.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 The Manufacturer Usage Description (MUD) [RFC8520] defines a YANG 68 data model to express what sort of access a device requires to 69 operate correctly. The document additionally defines three ways for 70 the device to communicate the URL of the resulting JSON [RFC8259] 71 format file to a network enforcement point: DHCP, within an X.509 72 certificate extension, and via LLDP. 74 Each of the above mechanism conveys the MUD URL inband, and requires 75 modifications to the device firmware. Most small IoT devices do not 76 have LLDP, and have very restricted DHCP clients. Adding the LLDP or 77 DHCP options requires at least some minimal configuration change, and 78 possibly entire new subsystems. The X.509 certificateion extension 79 only makes sense to deploy as part of a larger IDevID based 80 [ieee802-1AR] system such as [I-D.ietf-anima-bootstrapping-keyinfra]. 82 In all cases these mechanisms can only be implemented by persons with 83 access to modify and update the firmware of the device. The MUD 84 system was designed to be implemented by Manufacturers afterall! 86 In the meantime there is a chicken or egg problem ([chickenegg]): no 87 manufacturers include MUD URLs in their products as there are no 88 gateways that use them. No gateways include code that processes MUD 89 URLs as no products produce them. 91 The mechanism described here allows any person with physical access 92 to the device to affix a reference to a MUD URL that can later be 93 scanned by an end user. This can be done by the (marketing 94 department) of the Manufacturer, by an outsourced assembler plant, by 95 value added resellers, by a company importing the product (possibly 96 to comply with a local regulation), by a network administrator 97 (perhaps before sending devices home with employees), or even by a 98 retailer as a value added service. 100 The mechanism uses the QRcode, which is informally described in 101 [qrcode]. QR code generators are available as web services 102 ([qrcodewebservice]), or as programs such as [qrencode]. They are 103 formally defined in [isoiec18004]. 105 This document details how the CIRALabs Secure Home Gateway encode MUD 106 URLs as QR codes. 108 A issue addressed by this document is the question of whether and 109 when the MUD file should be specific to a specific version of the 110 device firmware. 112 The third issue is that an intermediary (ISP, or third-party security 113 service) may want to extend or amend a MUD file received from a 114 manufacturer. In order to maintain an audit trail of changes, a way 115 to encode the previous MUD URL and signature file (and status) is 116 provided. (FOR DISCUSSION) 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 3. Protocol 128 The [dpp] specification from the Wi-Fi Alliance has created a base 129 for a QRcode based enrollment system. This specification extends it 130 to include a MUD URL. 132 The QR code is as specified in section 5.2.1 of [dpp] is repeated 133 here: 135 dpp-qr = “DPP:” [channel-list “;”] [mac “;”] 136 [information “;”] public-key “;;” 138 This is amended as follows: 140 dpp-qr = “DPP:” [channel-list “;”] [channel-list “;”] 141 [mac “;”] [information “;”] public-key 142 [";" mudurl ] “;;” 143 mudurl = "D:" *(%x20-3A / %x3C-7E) ; semicolon not allowed 145 While the ABNF defined in the [dpp] document assumes a specific order 146 (C:, M:, I:, K:), this specification relaxes this so that the tags 147 can come in any order. However, in order to make interoperation with 148 future DPP-only clients as seamless as possible, the MUD extension 149 suggested here are placed after those defined in [dpp]. 151 This document establishes an IANA registry for DPP attributes. 153 The syntax of the QR code definition given above does not permit a 154 semicolon to be included. Semicolons (";") would otherwise be 155 permitted in MUD URLs. This restriction on the content the URL is 156 not considered a concern as it is uncommon to use them in a URL. 158 The URL provided MUST NOT have a query (?) portion present. 160 An IANA registry is created for the attributes below. 162 4. Privacy Considerations 164 TBD. 166 5. Security Considerations 168 The security of the Device Provisioning Protocol is enhanced when the 169 public key for a device is not available without physical access to 170 the device. Placement of a QR code for use by a MUD controller has 171 no such dependancy, and so such QR codes may be affixed in prominant 172 places on the outside of packaging. This is not a recommended 173 practice as future versions of the sticker may include full DPP 174 information. 176 The QRcode described in this document is identical for all instances 177 of the device, and the stickers may be mass produced. The situation 178 is not the same when a full DPP content is present: each sticker is 179 unique. A manufacturing plant designed to affix MUD URLs may get 180 confused and not be ready for the full DPP. 182 It is recommended that the manufacturing process be designed with the 183 full DPP process -- unique QR codes per device -- initially so that 184 no changes are necessary when/if DPP is introduced. 186 6. IANA Considerations 188 IANA is requested to create a new Registry entitled: "Device 189 Provisioning Protocol Attributes". New items can be added to using 190 Specification Required. In order to conserve space, registrations 191 are expected to be single upper-case ASCII letters, but the Expert 192 Reviewer MAY make exceptions. No entry may contain a colon. All 193 entries beginning with "X" are reserved as Private-Use values. 195 The following items are to be added to the initial table: 197 +--------+--------------+-----------------+ 198 | Letter | Name | Document | 199 +========+==============+=================+ 200 | C | channel-list | [dpp] | 201 +--------+--------------+-----------------+ 202 | M | MAC address | [dpp] | 203 +--------+--------------+-----------------+ 204 | I | information | [dpp] | 205 +--------+--------------+-----------------+ 206 | K | public key | [dpp] | 207 +--------+--------------+-----------------+ 208 | D | MUD URL | [This document] | 209 +--------+--------------+-----------------+ 211 Table 1 213 (EDITORIAL NOTE: the authors of the DPP specification have consented 214 to seeding control to IANA) 216 7. Acknowledgements 218 This work was supported by the Canadian Internet Registration 219 Authority (cira.ca). 221 8. References 223 8.1. Normative References 225 [qrcode] Wikipedia, ., "QR Code", December 2019, 226 . 228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 229 Requirement Levels", BCP 14, RFC 2119, 230 DOI 10.17487/RFC2119, March 1997, 231 . 233 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 234 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 235 May 2017, . 237 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 238 Description Specification", RFC 8520, 239 DOI 10.17487/RFC8520, March 2019, 240 . 242 8.2. Informative References 244 [chickenegg] 245 Wikipedia, ., "Chicken or the egg", December 2019, 246 . 248 [dpp] "Device Provisioning Protocol Specification", April 2018, 249 . 253 [I-D.ietf-anima-bootstrapping-keyinfra] 254 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 255 and K. Watsen, "Bootstrapping Remote Secure Key 256 Infrastructures (BRSKI)", Work in Progress, Internet- 257 Draft, draft-ietf-anima-bootstrapping-keyinfra-31, 16 258 December 2019, . 261 [ieee802-1AR] 262 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 263 2009, . 266 [isoiec18004] 267 ISO/IEC, ., "Information technology - Automatic 268 identification and data capture techniques - QR Code bar 269 code symbology specification (ISO/IEC 18004)", February 270 2015. 272 [qrcodewebservice] 273 Internet, ., "QR Code Generators", December 2019, 274 . 276 [qrencode] Fukuchi, K., "QR encode", December 2019, 277 . 279 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 280 Interchange Format", STD 90, RFC 8259, 281 DOI 10.17487/RFC8259, December 2017, 282 . 284 Authors' Addresses 286 Michael Richardson 287 Sandelman Software Works 289 Email: mcr+ietf@sandelman.ca 291 Jacques Latour 292 CIRA Labs 294 Email: Jacques.Latour@cira.ca