idnits 2.17.1 draft-richardson-homerouter-provisioning-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 (21 May 2021) is 1071 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BCP14' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-bootstrapping-keyinfra' is defined on line 341, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7084 -- Duplicate reference: RFC8174, mentioned in 'RFC8174', was also mentioned in 'BCP14'. == Outdated reference: A later version (-09) exists of draft-richardson-t2trg-idevid-considerations-03 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IOTOPS? Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Best Current Practice 21 May 2021 5 Expires: 22 November 2021 7 Provisioning Initial Device Identifiers into Home Routers 8 draft-richardson-homerouter-provisioning-01 10 Abstract 12 This document describes a method to provisioning an 802.1AR-style 13 certificate into a router intended for use in the home. 15 The proceedure results in a certificate which can be validated with a 16 public trust anchor ("WebPKI"), using a name rather than an IP 17 address. This method is focused on home routers, but can in some 18 cases be used by other classes of IoT devices. 20 (RFCEDITOR please remove: this document can be found at 21 https://github.com/mcr/homerouter-provisioning) 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 22 November 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Primarily Home Routers . . . . . . . . . . . . . . . . . 3 58 1.2. Provisioning of certificates with public trust anchors . 4 59 1.3. Manufacturers or ISPs do provisioning . . . . . . . . . . 4 60 1.4. Users who use web browsers . . . . . . . . . . . . . . . 5 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Certificate Expiry/Renewal Protocol . . . . . . . . . . . . . 7 65 6. Using wildcard certificates with private network addresses . 7 66 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 12.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The increasing push to move all web interactions to HTTPS is a good 79 thing. [RFC6797] section 2.3.1 explains some of the attacks that 80 this defeats. 82 Residential use devices, particularly home routers, have some very 83 unfortunate challenges. The router provides access control for the 84 entire home network: controlling access to the router is critical. 85 Malware has been, so far, content to attack the outside of home 86 routers, exploiting poor authorization controls, and the fact that so 87 few devices have their password changed (see [sixtypercent]). 89 Malware continues to arrive by email and by trojan download, and one 90 must assume that at least some devices within the home may be 91 infected. 93 An obvious next step for malware is to attack home routers and IoT 94 devices from within the home. An unencrypted administrative 95 interface to these devices presents two problems: 97 1. for devices that continue to use passwords as authorization, the 98 passwords can easily be seen by active eavesdropping of the 99 network, including use of IP address spoofing attacks. In 100 residential configurations, the most common Layer Two (ethernet) 101 wifi encryption does nothing to prevent address spoofing attacks 102 at Layer Three (IP, ARP). 104 2. the lack of a useable TLS/HTTPS mechanism makes it difficult to 105 use any kind of other non-password authorization mechanisms, such 106 TLS Client Certificates, or OAUTH2 (Bearer) Tokens. 108 In addition to the above arguments relating to the control interface 109 to these devices, there are some significant advantages in management 110 if every device has a cryptographic identity. They include: ability 111 to do remote attestation, ease of use of "Enterprise" versions of 112 WPA, such as EAP-TLS for WiFi connectivity, detection of counterfeit 113 devices, and better security for interactions with a cloud. 115 [I-D.richardson-t2trg-idevid-considerations] describes a number of 116 different scenarios and considersation for manufacturer installation 117 of keying material into devices. This document is much more 118 specific, as it focuses on: 120 1. primarily Home Routers (as described in [RFC7084]) 122 2. provisioning of certificates with public trust anchors (those 123 that follow [CABFORUM]) 125 3. manufacturers or ISPs that provision many devices, and who can 126 control the firmware 128 4. users who use web browsers to do routine and management tasks 130 The next four sections expand the explanation of the above 131 applicability, explaining why the boundaries have been set up as 132 such. 134 1.1. Primarily Home Routers 136 As will be explained below, in order for the user's browser to be 137 directed to the right system by name, it is easiest if the DNS names 138 can be mapped to local IP addresses correctly. The Home Router is 139 usually in a position to answer DNS queries from other devices in the 140 home, so it can easily map names that should lead to the home router, 141 to one of the home router's IP addresses. 143 As an extension to the mechanism described here, a new mechanism is 144 described in Section 6 that provides for compatible naming of devices 145 when control over DNS queries is not possible. 147 1.2. Provisioning of certificates with public trust anchors 149 The [CABFORUM] provides a set of guidelines agreed to by Browser 150 authors and Certification Authorities (CA). A well funded CA that 151 follows the guidelines is likely to be able to negotiate to have 152 their trust anchor included by default into the trusted set 153 distributed by browsers and operating systems. 155 Few of the details of the guidelines concern this document: but the 156 key point is that an arbitrary manufacturer is unlikely to be able to 157 negotiate directly, and will need to arrange to obtain certificates 158 from one of the existing certification authorities, or it's 159 suborbinate customers. 161 There are two details that do matter: 163 1. CAs will not sign private names or reserved IP addresses. Names 164 used must be public and listed in the https://publicsuffix.org/ 165 list. 167 2. CAs are not to create certificates longer than a CABForum defined 168 limit, which is currently set to approximately 1 year (in debate 169 from approximately 2 years). However, some CAs, such as 170 https://letsencrypt.org/, use a lifetime of 90 days, and many CAs 171 are moving in this direction as well. 173 1.3. Manufacturers or ISPs do provisioning 175 The mechanism described in this document assumes that the entity 176 doing the provisioning has control over the firmware. This is most 177 easy for an hardware manufacturer who is building the devices and who 178 performs the provisioning step in the factory. This provisioning 179 step could also occur some time later in a Quality Assurance step 180 where blank devices are first loaded with firmware. This is common 181 for OEMs that have outsourced the actual manufacturing elsewhere, but 182 bring the various components together in another place. 184 An ISP who purchased a large quanity of home routers, and then 185 upgrades the firmware could also easily adapt this mechanism. The 186 upgraded devices are then put back into their boxes, and into a 187 warehouse or logistics center before shipping them to customers. It 188 is not uncommon for ISPs, particularly those that use PPPoE, to need 189 to provision a PPP username/login to be used for initial provisioning 190 into every device. Upon first being connected, the device uses this 191 default username to login to the ISP (to some captive network), at 192 which point customer-specific username and login are configured, 193 often using TR-069. 195 1.4. Users who use web browsers 197 The process in this document benefits users with browsers (whether 198 desktops or mobile browsers) who need to access a management 199 interface of a home router or similiar device (such as a NAS or home 200 automation system). 202 Devices which are exclusively configured using smartphone apps, and 203 which have no other interfaces will find some of the mechanism 204 superfluous. Smartphone apps can be provided with a private-CA trust 205 anchor, and could easily be programmed to validate different parts of 206 the certificate. 208 The lifetime and DNS name issues are of significantly less of an 209 issues as a result. 211 However, the level of sophistication required to do the above coding 212 is difficult to find in cross-platform mobile developers, and 213 smartphone OS vendors are increasingly discouraging the use of 214 private trust anchors. 216 2. Terminology 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 220 "OPTIONAL" in this document are to be interpreted as described in 221 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 222 capitals, as shown here. 224 3. Protocol Overview 226 Upon booting the device checks to see if it has been provisioned with 227 a certificate already. (Note that an expired certificate is still 228 considered to be been provisioned, see below) 230 Assuming that it has not, then it generates private key if necessary. 231 Some classes of devices may have a private key provisioned by a 232 firmware or physical TPM module during the manufacuring process. 234 The home router generates a Unique Local IPv6 Address (ULA, see 235 [RFC4193] and [RFC7084] section 4.3), if it hasn't generated one 236 already. It must store this generated prefix in the same place as 237 the private key and certificate. If any of the ULA, or private key 238 changes, then the certificate will need to be changed as well. 240 The home router uses all or a portion of the ULA to form a DNS name 241 that is unique with the manufacturer's realm. For instance, given 242 the ULA fd96:8d23:4fea::/48, one could drop the initial 7 bits which 243 are always the same, skip a bit, and truncate to 6 bytes, giving: 244 8d234f. A name is formed, for instance: n8d234f.r.example.net. 246 With this name, a Certificate Signing Request is formed, binding the 247 name n8d234f.r.example.net to the public key derived above. 249 The router then looks and waits for a network attachment on any of 250 it's (physical) ethernet interfaces. This mechanism does not work 251 for devices with only WiFi interfaces, but typical home routers have 252 at least one physical interface used to connect to the Internet. 253 Even integrated VDSL or LTE modems with a primarily WiFi orientation 254 usually have at least one physical LAN port. 256 Some devices distinguishes a "WAN" interface, and other devices 257 either only one network interface, or do not initally distinguish a 258 specific one. A recommendation is to listen on any interface, as 259 this makes provisioning the systems require less skilled labour: any 260 connector that fits is acceptable. 262 Upon finding a network connection, the home router uses the 263 [I-D.ietf-anima-grasp] protocol to do an M_DISCOVER for a service 264 called "PROVISIONING". This is done using Link-Layer IPv6 addresses. 265 The result will be a Link-Layer IPv6 address and port number on which 266 the home router should connect. 268 A TLS/HTTPS connection is made to that address, using a virtual Host: 269 that has been provisioning into the firmware by the manufacturer. 270 (The same FQDN should go into the SNI for the TLS connection). The 271 home router uses a trust anchor provisioned by the manufacturer, and 272 [RFC6125] DNS-ID policy, to validate that the home router has been 273 connected to an appropriate factory provisioning system. 275 The CSR along with some particulars about the device (the chosen ULA, 276 some serial number information), is transmitted in an HTTPS POST. 277 The provisioning system treats this as a secure connection because it 278 originates on an IPv6-Link-Local address. (It is reasonable that the 279 provisioning system is elsewhere, but that there is a local 280 provisioning device which will relay traffic to the provisioning 281 system) 283 The provisioning system obtains a certificate using ACME, and an 284 [RFC8555] DNS-01 challenge. This may require up to a minute in order 285 to do the DNS update, wait for propogation, and then receive the 286 resulting certificate. 288 The device has provided its DNS name to the provisioning system, so 289 the provisioning system installs that name into the DNS with a AAAA 290 record giving the ULA address that the device has provided. (As part 291 of the DNS-01 challenge, some challenge records are installed as 292 proof of control of the name) 294 The provisioning system then returns the certificate to the device. 295 The provisioning system SHOULD keep a copy of the certificate in a 296 database; should the provisioning process fail before the device 297 writes all its state to non-volatile memory, then the provisioning 298 system need not repeat the certificate process. 300 The device now has a certificate for a name that it knows is its own. 301 The device now creates a local DNS mapping (aka "/etc/hosts") from 302 the name it has chosen to the ULA address it has chosen. The device, 303 even when not connected to the Internet, will answer DNS queries for 304 that name from client systems, mapping the name to the address, and 305 then responding on port 443 to HTTPS queries for that name. 307 4. Protocol Details 309 Many small details to fill in. 311 5. Certificate Expiry/Renewal Protocol 313 Via store-and-forward with some javascript on port 80 and/or an App. 315 6. Using wildcard certificates with private network addresses 317 To be further described. 319 7. Privacy Considerations 321 Many to be discussed. 323 8. Security Considerations 325 9. IANA Considerations 327 10. Acknowledgements 329 Hello. 331 11. Changelog 333 12. References 335 12.1. Normative References 337 [BCP14] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 338 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 339 May 2017, . 341 [I-D.ietf-anima-bootstrapping-keyinfra] 342 Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. 343 H., and K. Watsen, "Bootstrapping Remote Secure Key 344 Infrastructures (BRSKI)", Work in Progress, Internet- 345 Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11 346 November 2020, . 349 [I-D.ietf-anima-grasp] 350 Bormann, C., Carpenter, B., and B. Liu, "A Generic 351 Autonomic Signaling Protocol (GRASP)", Work in Progress, 352 Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, 353 . 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 362 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 363 . 365 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 366 Transport Security (HSTS)", RFC 6797, 367 DOI 10.17487/RFC6797, November 2012, 368 . 370 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 371 Requirements for IPv6 Customer Edge Routers", RFC 7084, 372 DOI 10.17487/RFC7084, November 2013, 373 . 375 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 376 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 377 May 2017, . 379 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 380 Kasten, "Automatic Certificate Management Environment 381 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 382 . 384 12.2. Informative References 386 [CABFORUM] CA/Browser Forum, "CA/Browser Forum Baseline Requirements 387 for the Issuance and Management of Publicly-Trusted 388 Certificates, v.1.7.3", October 2020, 389 . 392 [I-D.richardson-t2trg-idevid-considerations] 393 Richardson, M., "A Taxonomy of operational security 394 considerations for manufacturer installed keys and Trust 395 Anchors", Work in Progress, Internet-Draft, draft- 396 richardson-t2trg-idevid-considerations-03, 22 February 397 2021, . 400 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 401 Verification of Domain-Based Application Service Identity 402 within Internet Public Key Infrastructure Using X.509 403 (PKIX) Certificates in the Context of Transport Layer 404 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 405 2011, . 407 [sixtypercent] 408 "The economics of the security of consumer-grade IoT 409 products and services", 24 April 2019, 410 . 414 Author's Address 416 Michael Richardson 417 Sandelman Software Works 419 Email: mcr+ietf@sandelman.ca