idnits 2.17.1 draft-richardson-anima-smartpledge-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-anima-bootstrapping-keyinfra]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 06, 2018) is 2056 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-16 Summary: 1 error (**), 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: March 10, 2019 CIRA Labs 6 F. Khan 7 Twelve Dot Systems 8 September 06, 2018 10 BRSKI enrollment for Smart Pledges 11 draft-richardson-anima-smartpledge-00 13 Abstract 15 This document details the mechanism used for initial enrollment by a 16 smartphone into a BRSKI based enrollment system. 18 There are two key differences in assumption from 19 [I-D.ietf-anima-bootstrapping-keyinfra]: that the intended registrar 20 has Internet, and that the Pledge has no user-interface. 22 This variation on BRSKI is intended to be used in the situation where 23 the registrar device is new out of the box and is the intended 24 gateway to the Internet (such as a home gateway), but has not yet 25 been configured. This work is also intended as a transition to the 26 Wi-Fi Alliance work on the Device Provisioning Protocol (DPP). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 10, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Additional Motivation . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 66 4. Assumptions and Required Setup . . . . . . . . . . . . . . . 5 67 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Scan the QR code . . . . . . . . . . . . . . . . . . . . 6 69 5.2. Enroll with the manufacturer . . . . . . . . . . . . . . 6 70 5.3. Connect to BRSKI join network . . . . . . . . . . . . . . 6 71 5.4. Connect to Adolescent Registrar (AR) . . . . . . . . . . 7 72 5.5. Pledge Requests Voucher-Request from the Adolescent 73 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.6. AR processing of voucher-request, request. . . . . . . . 7 75 5.7. Smartpledge validates connection . . . . . . . . . . . . 8 76 5.8. Smart-Pledge connects to MASA . . . . . . . . . . . . . . 8 77 5.9. MASA processing . . . . . . . . . . . . . . . . . . . . . 9 78 5.10. Smartpledge processing of voucher . . . . . . . . . . . . 9 79 5.11. Adolescent Registrar (AR) receives voucher . . . . . . . 9 80 5.12. Adolescent Registrar (AR) grows up . . . . . . . . . . . 9 81 5.13. Smartpledge enrolls . . . . . . . . . . . . . . . . . . . 10 82 5.14. Validation of connection . . . . . . . . . . . . . . . . 10 83 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 84 6.1. Quick Response Code (QR code) . . . . . . . . . . . . . . 11 85 6.1.1. The SmartPledge Attribute . . . . . . . . . . . . . . 11 86 6.1.2. Link-Layer Address Attribute . . . . . . . . . . . . 11 87 6.1.3. ESSID Name Attribute . . . . . . . . . . . . . . . . 12 88 6.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 12 89 6.2.1. Voucher-Request Challenge . . . . . . . . . . . . . . 12 90 6.2.2. Additions to Voucher-Request . . . . . . . . . . . . 12 91 6.3. Enrollment using EST . . . . . . . . . . . . . . . . . . 12 92 7. Smart Pledge enrollment with manufacturer . . . . . . . . . . 12 93 8. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 12 94 8.1. Wrong Administrator . . . . . . . . . . . . . . . . . . . 12 95 8.2. Rogue Administrator . . . . . . . . . . . . . . . . . . . 13 96 8.3. Attack from Internal device . . . . . . . . . . . . . . . 13 97 8.4. Attack from camera enabled robot . . . . . . . . . . . . 13 98 8.5. Attack from manipulator enabled robot . . . . . . . . . . 13 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 101 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 104 12.2. Informative References . . . . . . . . . . . . . . . . . 14 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 107 1. Introduction 109 The problem of bootstrapping a new device is described at length in 110 [I-D.ietf-anima-bootstrapping-keyinfra] (aka BRSKI). The problem 111 that BRSKI solves is the case of a smart, properly configured network 112 with a minimum of network connectivity (or previously pre-previoned 113 with nonceless vouchers), and a relatively stupid new device (the 114 Pledge), which lacks a network interface. 116 The BRSKI problem is one of trust: how does the new device trust that 117 it has found the correct network to join, and how does the new 118 network become convinced that the new device is a device that is 119 intended to join. BRSKI solves the problem well for the case where 120 the network is well connected and easily talk to the device's 121 Manufacturer Authorized Signing Authority (MASA), while providing 122 appropriate proxy mechanisms to enable the new pledge to communicate 123 it's proximity assertion to the MASA as well. 125 This document is about a variation of the problem: when the new 126 device being introduce has no network connectivity, but a new device 127 is intended to serve as the Registrar for the network. This new 128 device is likely a home (or small office) gateway, and until it is 129 properly configured there will be no direct network connectivity. 131 There are a number of protocols that permit an ISP to consider a new 132 router brought into a home to be a new pledge to the ISPs' network, 133 and for that new device to integrated into the ISP's (autonomic) 134 network. BRSKI can be used itself, and there are ways to use the 135 Broadband Form's TR-069 to bootstrap the device in this way. This 136 document is not about the situation where the router device is 137 intended to belong to the ISP, but about the situation where the home 138 user intends to own and control the device. 140 1.1. Additional Motivation 142 The Wi-Fi Alliance has released the Device Provisioning Protocol 143 [dpp]. The specification is not public. The specification relies on 144 being able to send and receive 802.11 Public Action frames, as well 145 as Generic Advertisement Service (GAS) Public Action frames. Access 146 to send new layer-2 frames is generally restricted in most smartphone 147 operating systems (iOS, Android). At present there are no known 148 public APIs that a generic application writer could use, and 149 therefore the smart-phone side of the DPP can only be implemented at 150 present by the vendors of those operating systems. 152 As both dominant vendors have competing proprietary mechanisms, it is 153 unclear if generic applications will be produced soon. It is there 154 impossible for a vendor an a smart-appliance to independantly produce 155 an application that can do proper DPP in 2018. 157 In addition to the above concern, DPP is primary concerned about 158 provisioning WiFi credentials to devices. It assumes that the WiFi 159 Access Point is already provisioned and functioning correctly. 161 The smartpledge enrollment described in this document is about 162 securely initializing the administrative connection with a device 163 that is the WiFi Access Point. 165 2. Terminology 167 The following terminology is copied from 168 [I-D.ietf-anima-bootstrapping-keyinfra] 170 enrollment: The process where a device presents key material to a 171 network and acquires a network specific identity. For example 172 when a certificate signing request is presented to a certification 173 authority and a certificate is obtained in response. 175 pledge: The prospective device, which has an identity installed at 176 the factory. 178 IDevID: a manufacturer signed keypair (different from the QRkey) 179 which is generated at the factory. This is the 802.1AR artifact 180 which is mandated by [I-D.ietf-anima-bootstrapping-keyinfra]. 182 The following new terminology has been added 184 smartpledge: The prospective administrator device, usually a 185 smartphone equipped with a QR capable camera, wifi and 3G 186 connectivity. 188 adolescent router (AR): a home router or device containing a 189 registrar. The device does not yet have network connectivity, and 190 has no administrator. It is considered not a "baby" device in the 191 same way that the pledge is, but it is not yet an adult. A better 192 term would be welcome. 194 SelfDevID: a public/private key pair generated by the smartpledge, 195 formed into a self-signed PKIX certificate. The private key part 196 remains always on the smartpledge, but like other secondary device 197 keys, should be encrypted for backup purposes. {EDNOTE: any 198 references to Apple or Android APIs/specifications here?} 200 QRkey: a unique, raw ECDSA or EdDSA key pair generated in (or for) 201 the adolescent router at the factory, and stored in the 202 configuration portion of the firmware. The public portion is 203 printed in a QRcode. This key is not formed into a certificate of 204 any kind. 206 3. Requirements Language 208 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 209 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 210 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 211 [RFC2119] and indicate requirement levels for compliant STuPiD 212 implementations. 214 4. Assumptions and Required Setup 216 The first assumption is that intended device owner is active and is 217 present. The device owner has a smart-phone that is capable of using 218 Wi-Fi or being wired into the adolescent router (AR). 220 The smartpledge application generates a self-signed certificate with 221 public/private keypair that it knows. It may generate a unique 222 certificate for each manufacturer. This certificate is called the 223 SelfDevID. 225 The second assumption is that the device has a QR code printed on the 226 outside of the unit, and/or provided with the packaging/ 227 documentation. The QR code is as specified in section 5.3 of [dpp], 228 with the additions specified in Section 6.1 230 The third assumption is that the AR, at manufacturing time, has the 231 anchor for it's MASA (same assumption as for BRSKI pledge's). In 232 addition, like the BRSKI pledge, the AR has an IDevID certificate 233 (and associated private key) signed by the manufacturer. 235 The fourth assumption is that the key in the "K:" attribute 236 Section 6.1 is a different public key pair. It MUST be different 237 from the key used in the IDevID. This key is called the DPP-Keypair. 239 5. Protocol Overview 241 This is the overview of the process. {EDNOTE: there are many details 242 here that belong in the next section. The goal in this section is to 243 consisely explain the interaction among the components. Clearly this 244 text currently fails in that regard} 246 5.1. Scan the QR code 248 The operator of the smartphone invokes the smartpledge application, 249 and scans the QR code on the AR. The smartpledge learns the ESSID, 250 Public-Key, mac-address, smartpledge URL, and link-local address of 251 the AR. 253 5.2. Enroll with the manufacturer 255 The smartpledge uses it's 3G, or other WiFi internet access to 256 connect to the manufacturer with TLS. The smartpledge does an HTTP 257 POST to the provided URL using it's generated certificate as it's 258 ClientCertificate. As described in Section 7, the manufacturer MAY 259 respond with a 302 result code, and have the end user go through a 260 web browser based process to enroll. After that process, a 261 redirection will occur using OAUTH2. 263 The result should finally be a 201 result code, and at that URL is a 264 new certificate signed by the manufacturer. 266 5.3. Connect to BRSKI join network 268 The application then reconnects the Wi-Fi interface of the smartphone 269 to the ESSID of the AR. This involves normal 802.11 station 270 attachment. The ESSID explicitely has no WPA or other security 271 required on it. 273 There will be no DHCPv4. A IPv6 Router Solicitation may elicit an 274 answer (confirming the device is there), but it is acceptable for 275 there to be no prefix information. An IPv6 Neighbour Discovery is 276 done for the IPv6 Link-Local address of the AR. Receipt of an answer 277 confirms that the ESSID is correct and present. 279 (XXX - not using GRASP here. Could use GRASP, but QR code is better) 281 5.4. Connect to Adolescent Registrar (AR) 283 The smartpledge application then makes a direct (no proxy) TLS 284 connection to port 443 of the AR, on the IPv6 Link-Local address 285 given. This is as in section 5.1 of 286 [I-D.ietf-anima-bootstrapping-keyinfra]. The smartpledge uses it's 287 SelfDevID as the TLS ClientCertificate, as the smartpledge does not 288 have a manufacturer signed IDevID. 290 Additionally, the AR will use it's IDevID certificate as the 291 ServerCertificate of the TLS conncetion. As with other BRSKI IDevID, 292 it will have a MASA URL extension, as described in 293 [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.2. 295 5.5. Pledge Requests Voucher-Request from the Adolescent Registrar 297 The smartpledge generates a random nonce _SPnonce_. To this is adds 298 SOMETHING-that-is-time-unique, to create a _voucher-request 299 challenge_. This is placed in the voucher-challenge-nonce field. 301 Using the public-key of the AR that was scanned from the QR code, the 302 smartpledge encrypts the challenge using CMS (or COSE?). 304 NOTE: DPP has a round with the SHA256 of the device's key to make 305 sure that the correct device has been chosen. The TLS connection 306 effectively provides the same privacy that the Bx keys provided. 308 The resulting object is POST'ed to the new BRSKI endpoint: 310 /.well-known/est/requestvoucherrequest 312 [or should it be named: /.well-known/est/requestvoucherchallenge 314 ] 316 5.6. AR processing of voucher-request, request. 318 The AR processes this POST. First it uses the private key that is 319 associated with it's QR printed public key to decrypt the voucher- 320 request challenge. Included in this challenge is a nonce, and also 321 the link-local address of the smartpledge. 323 The AR SHOULD verify that the link-local address matches the 324 originating address of the connection on which the request is 325 received. 327 The AR then forms a voucher-request identically to as described in 328 section 5.2 of [I-D.ietf-anima-bootstrapping-keyinfra]. Note that 329 the AR uses it's IDevID to sign the voucher-request. This is the 330 same key used to terminate the TLS connection. It MUST be different 331 from the public key printed in the QR code. 333 In addition to the randomly generated nonce that the AR generates to 334 place in the the voucher-request, into the nonce field, it also 335 includes the _SPnonce_ in a new _voucher-challenge-nonce_ field. 336 {EDNOTE: hash of nonce?} 338 This voucher-request is then _returned_ during the POST operation to 339 the smartpledge. (This is in constrast that in ANIMA the voucher- 340 request is sent by the device to the Registrar, or the MASA) 342 5.7. Smartpledge validates connection 344 The smartpledge then examines the resulting voucher-request. The 345 smartpledge validates that the voucher-request is signed by the same 346 public key as was seen in the TLS ServerCertificate. 348 The smartpledge then examines the contents of the voucher-request, 349 and looks for the _voucher-challenge-nonce_. As this nonce was 350 encrypted to the AR, the only way that the resulting nonce could be 351 correct is if the correct private key was present on the AR to 352 decrypt it. Succesful verification of the _voucher-challenge-nonce_ 353 (or the hash of it, see below) results in the smartpledge moving it's 354 end of the connection from provisional to validated. 356 5.8. Smart-Pledge connects to MASA 358 The smartpledge application then examines the MASA URL provided in 359 the TLS ServerCertificate of the AR. The smartpledge application 360 then connects to that URL using it's 3G/LTE connection, taking on the 361 role of Registrar. 363 A wrapped voucher-request is formed by the smartpledge in the same 364 way as described in section 5.4 of 365 [I-D.ietf-anima-bootstrapping-keyinfra]. The inner prior-signed- 366 voucher-request is filled in with the voucher-request that was 367 created by the AR in the previous step. 369 The pinned-domain-cert of this voucher-request is set to be the 370 SelfDevID certificate of the smartpledge. The voucher-request is to 371 be signed by the SelfDevID. 373 The voucher-request is POST'ed to the MASA using the same URL that is 374 used for Registrar/MASA operation: 376 /.well-known/est/requestvoucher 378 5.9. MASA processing 380 The MASA processing occurs as specified in section 5.5 of 381 [I-D.ietf-anima-bootstrapping-keyinfra] as before. The MASA MUST 382 also copy the voucher-challenge-nonce into the resulting voucher. 384 5.10. Smartpledge processing of voucher 386 The smartplege will receive a voucher that contains it's IDevID as 387 the pinned-domain-cert, and the voucher-challenge-nonce that it 388 created will also be present. The smartpledge SHOULD verify the 389 signature on the artifact, but may be unable to validate that the 390 certificate used has a relationship to the TLS ServerCertificate used 391 by the MASA. (This limitation exists in ANIMA as well). 393 The smartpledge will then POST the resulting voucher to the AR using 394 the URL 396 /.well-known/est/voucher 398 5.11. Adolescent Registrar (AR) receives voucher 400 When the AR receives the voucher, it validates that it is signed by 401 it's manufacturer. This process is the same as section 5.5.1 of 402 [I-D.ietf-anima-bootstrapping-keyinfra]. Note that this is the 403 future Registrar that is performing what in ANIMA is a pledge 404 operation. 406 Inside the voucher, the pinned-domain-cert is examined. It should 407 match the TLS ClientCertificate that the smartpledge used to connect. 408 This is the SelfDevID. 410 At this point the AR has validated the identity of the smartpledge, 411 and the AR moves it's end of the connection from provisional to 412 validated. 414 5.12. Adolescent Registrar (AR) grows up 416 The roles are now slightly changed. The AR generates a new key pair 417 as it's Domain CA key. It MAY generate intermediate CA certificates 418 and a seperate Registrar certificate, but this is discouraged for 419 home network use. 421 The AR is now considered a full registrar. 423 5.13. Smartpledge enrolls 425 The smartpledge MUST now request the full list of CA Certificates, as 426 per [RFC7030] section 4.1. As the Registrar's CA certificate has 427 just been generated, the smartpledge has no other way of knowing it. 429 The smartpledge MUST now also generate a CSR request as per 430 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.8.3. The 431 smartpledge MAY reuse the SelfDevID key pair for this purpose. (XXX 432 - maybe there are good reasons not to reuse) 434 The Registrar SHOULD grant administrator privileges to the 435 smartpledge via the certificate that is issued. This may be done via 436 special attributes in the issued certificate, or it may pin the 437 certificate into a database. Which method to use is a local matter. 439 The EST connection MUST remain open at this point. 441 5.14. Validation of connection 443 The smartpledge MUST now open a new HTTPS connection to the Registrar 444 (AR), using it's newly issued certificate. (XXX should this be on a 445 different IP, or a different port? If so, how is this indicated?) 447 The smartpledge MUST validate that the new connection has a 448 certificate that is validated by the Registrar's new CA certificate. 450 The registrar MUST validate that the smartpledge's ClientCertificate 451 is validated by the Registrar's CA. The smartpledge SHOULD perform a 452 POST operation on this new connection to the 453 [I-D.ietf-anima-bootstrapping-keyinfra] Enrollment Status Telemetry 454 mechanism, see section 5.8.3. The EST connection MAY not be closed. 456 Should the validations above fail, then the original EST connection 457 MUST be used to GET a value from the 459 /.well-known/est/enrollstatus 461 from the Registrar. The contents of this value SHOULD then be send 462 to the MASA, using a POST to the enrollstatus, and including the 463 reply from the AR in a new attribute, "adolescent-registrar-reason". 465 6. Protocol Details 466 6.1. Quick Response Code (QR code) 468 Section 5.3 of [dpp] describes the contents for an [iso18004] image. 469 It specifies content that starts with DPP:, and the contains a series 470 of semi-colon (;) deliminated section with a single letter and colon. 471 This markup is terminated with a double semi-colon. 473 Although no amending formula is defined in DPP 1.0, this document is 474 defining two extensions. This requires amending the ABNF from 475 section 5.2.1 as follows: 477 dpp-qr = "DPP:" [channel-list ";"] [channel-list ";"] 478 [mac ";"] [information ";"] public-key 479 [";" llv6-addr ] [";" smartpledge ] [";" essid ] ";;" 480 llv6-addr = "L:" 8*hex-octet 481 essid = "E:" *(%x20-3A / %x3C-7E) ; semicolon not allowed 482 smartpledge = "S:" *(%x20-3A / %x3C-7E) ; semicolon not allowed 484 While the ABNF defined in the [dpp] document assumes a specific order 485 (C:, M:, I:, K:) the tags can come in any order. However, in order 486 to make interoperation with future DPP-only clients as seamless as 487 possible, the extensions suggested here are placed at the end of the 488 list. This is consistent with the Postel Principle. 490 It is intended that parts of this protocol could be performed by an 491 actual DPP implementation, should it become possible to implement DPP 492 using current smartphone operating systems in an unprivileged way. 494 6.1.1. The SmartPledge Attribute 496 The _smartpledge_ attribute indicates that the device is capable of 497 the protocol specified in this document. The contents of the 498 smartpledge attribute contains part of a URL which identifies the 499 manufacturer of this device, along with a unique token enabling 500 service access to the device. 502 Short URLs are essential to fit into typical QR code space. 504 The smartpledge application prepends the text "https://" to the value 505 provided to form the full address of the smartpledge enrollment. 507 6.1.2. Link-Layer Address Attribute 509 The _llv6-addr_ attribute is optional. When present, it specifies 510 the IPv6 Link-Local address at which the adolescent router is 511 listening. If not specified, then the link-local address may be 512 formed according to the historical (privacy-violating) process 513 described in [RFC4291] Appendix A. The _llv6-addr_ attribute is 514 present so that devices that have implemented [RFC7217] stable 515 addresses can express that address clearly. 517 6.1.3. ESSID Name Attribute 519 The _essid_ attribute provides the name of the 802.11 network to 520 which the _smartpledge_ SHOULD join in order to reach the AR. If 521 this attribute is absent, then it defaults to "BRSKI". 523 6.2. Artifacts 525 6.2.1. Voucher-Request Challenge 527 The smartpledge generates a random nonce _SPnonce_. To this is adds 528 SOMETHING-that-is-time-unique, to create a _voucher-request 529 challenge_. This is placed in the voucher-challenge-nonce field. 531 Using the public-key of the AR that was scanned from the QR code, the 532 smartpledge encrypts the challenge using CMS (or COSE?). 534 6.2.2. Additions to Voucher-Request 536 QUESTION: should the _voucher-challenge-nonce_ be provided directly 537 in the voucher-request, or should only a hash of the nonce be used? 538 The nonce is otherwise not disclosed, and a MITM on the initial TLS 539 connection would get to see the nonce. A hash of the nonce validates 540 the nonce as easily. 542 6.3. Enrollment using EST 544 TBD 546 7. Smart Pledge enrollment with manufacturer 548 TBD. 550 8. Threat Analysis 552 The following attacks have been considered. 554 8.1. Wrong Administrator 556 Neighbours with similar setups wind up managing each other's network 557 (by mistake). 559 8.2. Rogue Administrator 561 Uninitialized networks can be adopted by 'wardrivers' who search for 562 networks that have no administrator. 564 8.3. Attack from Internal device 566 A compromised device inside the home can be used by an attack to take 567 control of the home router. 569 8.4. Attack from camera enabled robot 571 A robot (such as a home vacuum cleaner) could be compromised, and 572 then used by an attacker to observe and/or scan the router QRcode. 574 8.5. Attack from manipulator enabled robot 576 A robot (for instance, a toy) could be compromised, and then used by 577 an attacker to push the WPA and/or factory reset button on the 578 router. 580 9. Security Considerations 582 Go through the list of attacks above, and explain how each has been 583 mitigated. 585 Go through the list of concerns in ANIMA and EST-RFC7030 and indicate 586 if there are additional concerns, or if a concern does not apply. 588 10. IANA Considerations 590 TBD. 592 11. Acknowledgements 594 This work was supported by the Canadian Internet Registration 595 Authority https://cira.ca/blogs/cira-labs/about-cira-labs. 597 12. References 599 12.1. Normative References 601 [dpp] "Device Provisioning Protocol Specification", n.d., 602 . 606 [I-D.ietf-anima-bootstrapping-keyinfra] 607 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 608 S., and K. Watsen, "Bootstrapping Remote Secure Key 609 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 610 keyinfra-16 (work in progress), June 2018. 612 [iso18004] 613 "Information technology --- Automatic identification and 614 data capture techniques --- Bar code symbology --- QR 615 Codes (ISO/IEC 18004:2015)", n.d., 616 . 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, 621 DOI 10.17487/RFC2119, March 1997, 622 . 624 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 625 "Enrollment over Secure Transport", RFC 7030, 626 DOI 10.17487/RFC7030, October 2013, 627 . 629 12.2. Informative References 631 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 632 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 633 2006, . 635 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 636 Interface Identifiers with IPv6 Stateless Address 637 Autoconfiguration (SLAAC)", RFC 7217, 638 DOI 10.17487/RFC7217, April 2014, 639 . 641 Authors' Addresses 643 Michael Richardson 644 Sandelman Software Works 646 Email: mcr+ietf@sandelman.ca 648 Jacques Latour 649 CIRA Labs 651 Email: Jacques.Latour@cira.ca 652 Faud Khan 653 Twelve Dot Systems 655 Email: faud.khan@twelvedot.com