idnits 2.17.1 draft-richardson-anima-registrar-considerations-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 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 (December 02, 2019) is 1599 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8174' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 811, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-21 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-30 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-05 == Outdated reference: A later version (-18) exists of draft-hallambaker-mesh-udf-07 == Outdated reference: A later version (-10) exists of draft-moskowitz-ecdsa-pki-07 == Outdated reference: A later version (-03) exists of draft-richardson-anima-state-for-joinrouter-02 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track December 02, 2019 5 Expires: June 4, 2020 7 Operational Considerations for BRSKI Registrar 8 draft-richardson-anima-registrar-considerations-00 10 Abstract 12 This document describes a number of operational modes that a BRSKI 13 Registration Authority (Registrar) may take on. 15 Each mode is defined, and then each mode is given a relevance within 16 an over applicability of what kind of organization the Registrar is 17 deployed into. This document does not change any protocol 18 mechanisms. 20 This document includes operational advice about avoiding unwanted 21 consequences. 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 June 4, 2020. 40 Copyright Notice 42 Copyright (c) 2019 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Reference Network and Diagrams . . . . . . . . . . . . . 4 60 1.2.1. Tier-1 Network . . . . . . . . . . . . . . . . . . . 4 61 1.2.2. Enterprise Network . . . . . . . . . . . . . . . . . 4 62 1.2.3. Home Network . . . . . . . . . . . . . . . . . . . . 5 63 1.3. Internal architectural view . . . . . . . . . . . . . . . 5 64 1.3.1. Pledge Interface (Southbound Interface) . . . . . . . 5 65 1.3.2. MASA client (Northbound Interface) . . . . . . . . . 6 66 1.3.3. Join Proxy (Southbound Interface) . . . . . . . . . . 7 67 1.3.4. EST and BRSKI GRASP announcements . . . . . . . . . . 7 68 1.3.5. Certificate Authority . . . . . . . . . . . . . . . . 7 69 1.3.6. Management Interface . . . . . . . . . . . . . . . . 8 70 2. Connecting the Autonomic Control Plane to the Network 71 Operations Center (NOC) . . . . . . . . . . . . . . . . . . . 8 72 3. Public Key Infrastructure Recommendations for the Registrar . 8 73 3.1. PKI recommendations for Tier-1/ISP Networks . . . . . . . 9 74 3.1.1. Enterprise Network . . . . . . . . . . . . . . . . . 10 75 3.1.2. Home Network . . . . . . . . . . . . . . . . . . . . 11 76 4. Architecture Considerations for the Registrar . . . . . . . . 11 77 4.1. Completely Synchronous Registrar . . . . . . . . . . . . 12 78 4.2. Partially Synchronous Registrar . . . . . . . . . . . . . 13 79 4.3. Asynchronous Registrar . . . . . . . . . . . . . . . . . 13 80 5. Certificates needed for the Registrar . . . . . . . . . . . . 13 81 5.1. TLS Server Certificate for BRSKI-EST . . . . . . . . . . 13 82 5.2. TLS Client Certificate for BRSKI-MASA . . . . . . . . . . 14 83 5.3. Certificate for signing of Voucher-Requests . . . . . . . 14 84 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 7.1. Denial of Service Attacks against the Registrar . . . . . 15 87 7.2. Loss of Keys/Corruption of Infrastructure . . . . . . . . 16 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 90 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 93 11.2. Informative References . . . . . . . . . . . . . . . . . 17 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 [I-D.ietf-anima-bootstrapping-keyinfra] introduces a mechanism for 99 new devices (called pledges) to be onboarded into a network without 100 intervention from an expert operator. 102 A key aspect of this is that there has to be a thing for the pledge 103 to join! [I-D.ietf-anima-bootstrapping-keyinfra] refers to this 104 thing as the "Domain", identified technically by the "DomainID". The 105 domain is embodied by the Registrar component. Membership in the 106 domain is proven by possession of a valid Local DeviceID, a form of 107 [ieee802-1AR] certificate. 109 The Registrar is the component that implements the domain, 110 authorizing new devices (pledges) to join. Proper and efficient 111 operation of the Registrar is key aspect for the Autonomic 112 mechanisms, and for enabling secure onboarding. 114 This document provides implementation, deployment and operational 115 guidance for the BRSKI Registrar. 117 There are however several classes of operator of a local domain: ISP 118 and large managed multi-side Enterprises are the primary target for 119 this document. Medium sized single site Enterprises and Industrial 120 Plant users are a secondary target for this document. Unmanaged 121 small enterprises and home users are addressed in a separate section 122 at the end as special case. 124 This document first introduces the different scales of deployment as 125 a reference for further discussion and contrasts, and then provides 126 analyses some consequences of architectural choices that may be 127 appropriate for different scales of deployments. 129 The document includes security best practices for the management of 130 the certificates and the certificate authorities. 132 1.1. Terminology 134 ::boilerplate bcp14 136 This document, while a Best Current Practices, makes use of BCP14 137 language to indicate which practices are mandatory, and which ones 138 are just recommendations. 140 1.2. Reference Network and Diagrams 142 In order to deal with the full complexity and generality of 143 operations, the reference network described herein is a bit more 144 complicated than many networks actually are. 146 1.2.1. Tier-1 Network 148 In this guide one target is a world-wide Tier-1 ISP. It has three 149 network operations centers (NOC), the two major ones in Frankfurt and 150 Denver, with an secondary center located in Perth, Australia. The 151 exact location of these NOCs is not important: the locations have 152 been chosen to have an hour overlap in their 8-6 daytime shift, 153 typical of world-wide operations. This overlap is also not 154 important, it just adds a degree of realism to this discussion. The 155 use of actual names makes subsequent discussion about failures 156 easier. 158 .---------. .-----. 159 | Denver | | NYC | 160 .----|---------|----| rtr |--. .-----------. 161 / | NOC/JRC | '-----' \ | Frankfurt | 162 ' '---------' '|-----------| 163 .---------. | NOC/JRC | 164 | SanJose | '-----------' 165 | rtr | . 166 '---------' / 167 .- / 168 ' / 169 .-----------. / 170 | Perth | .-------. / 171 |-----------| | Tokyo | / 172 | NOC/EST |--------------| rtr |-----' 173 | | '-------' 174 '-----------' ' 176 Reference Tier-1 ISP network 178 1.2.2. Enterprise Network 180 A second target is a medium Enterprise that has a single (probably 181 on-premise) data center. The Enterprise has Information Technology 182 (IT) operations that include the routers and systems supporting it's 183 office staff in it's buildings. It has Building Operations which 184 integrates the IoT devices found in the buildings that it owns, and 185 it has Operations Technology (OT) that manages the automated systems 186 in it's on-site manufacturing facilities. 188 INSERT DIAGRAM 190 1.2.3. Home Network 192 A third target is a resident with a single CPE device. The home 193 owner has a few medium sized devices (a home NAS) as well as a few 194 IoT devices (light bulbs, clothes washing machine). 196 1.3. Internal architectural view 198 A Registrar will have four major interfaces, connected together by a 199 common database. 201 .------------. 202 | MASA | 203 | client | 204 | BRSKI-MASA | 205 '------------' 206 ^ 207 | 208 .------------. | .-------------. 209 | management | .----------. | certificate | 210 | interface |<---| database |----->| authority | 211 '------------' '----------' '-------------' 212 | 213 | 214 v 215 .------------. .-----------. .------------. 216 | Join Proxy | | Pledge |--. | EST/BRSKI | 217 |------------| | Interface | | |------------| 218 | GRASP | | BRSKI-EST |e | | full-GRASP | 219 | (DULL) | '-----------'T | '------------' 220 '------------' '-----------' 222 Figure 1: Reference Internal Architecture for Registrar 224 1.3.1. Pledge Interface (Southbound Interface) 226 The pledge interface is the southbound interface. This interface 227 runs the BRSKI-EST protocol. This interface faces into the 228 operator's network, receiving requests from devices to join the 229 network. 231 For [I-D.ietf-anima-bootstrapping-keyinfra] use, the pledge interface 232 is an HTTPS interface. It may run on arbitrary port numbers and due 233 to the way that the voucher interface pins the associated certificate 234 it does not need to have a specific DNS name, as it will not be 235 verified by the pledge. 237 For [I-D.ietf-anima-constrained-voucher] use, the pledge interface is 238 a CoAP or CoAPS interface over UDP. For use with CoAP/EDHOC, then a 239 plain CoAP interface is used, and the security (EDHOC and OSCORE) 240 lives above CoAP. For CoAP/DTLS (CoAPS) then there is DTLS layer 241 below the CoAP layer. 243 [I-D.richardson-anima-state-for-joinrouter] offers some additional 244 mechanisms, one of which involves dynamically created IPIP tunnels. 245 If these mechanisms are in use, then the southbound interface would 246 need to support these options as well. 248 The Pledge Interface requires a TLS ServerCertificate, and 249 Section 5.1 discusses option for creating this certificate. 251 The Pledge Inteface does not require a public IP address, nor does it 252 have have to run on port 443. 254 In an ACP application ([I-D.ietf-anima-autonomic-control-plane]), the 255 Pledge Interface SHOULD have an IPv6 ULA address from the prefix 256 allocated to the ACP. Section 2 provides some options for how the 257 Pledge Interface can be best connected to the ACP. 259 Outside of the ACP context, running the Pledge interface on an IP 260 address that has a FQDN that resolves to that IP address (if only 261 internally), and operating it on port 443 may have operational 262 advantages. 264 1.3.2. MASA client (Northbound Interface) 266 The MASA client interface connects outward to the Internet to speak 267 to the Manufacturer Authorized Signing Authority (MASA). This is a 268 TLS Client interface. 270 Use of a TLSClientCertificate is RECOMMENDED as this may be the best 271 way for a manufacturer to identify clients. Section 5.2 discusses 272 options for signing this certificate. 274 The MASA client interface is outgoing only and does not require any 275 special connectivity. It may be placed behind a typical enterprise 276 or residential NAT44 gateway. IPv6 connectivity is RECOMMENDED. It 277 does need access to DNS, and the DNS lookups SHOULD be validated with 278 DNSSEC. 280 The MASA client interface will need to validate the server 281 certificates of the MASA, and to do this it will need access to the 282 common public WebPKI ([WebPKI]) trust anchors to validate the MASA. 283 The MASA client MAY also require access to a database of pinned 284 certificates to validate specific manufacturers as called out for in 285 [I-D.ietf-anima-bootstrapping-keyinfra] section 2.8 and section 5.4. 287 1.3.3. Join Proxy (Southbound Interface) 289 In the ACP context, the Registrar is expected to have a Join Proxy 290 operating on the Southbound Interface in order to announce the 291 existence of the Registrar to the local network, for the benefit of 292 directly connected devices. This permits the machines in the NOC 293 itself to autonomically join the domain. 295 The Join Proxy MAY announce the IP address (ULA) and port of the 296 actual Pledge Interface, rather than announcing a link-local address 297 and then performing a proxy operation. 299 1.3.4. EST and BRSKI GRASP announcements 301 As specified in [I-D.ietf-anima-bootstrapping-keyinfra] section 4.3, 302 in an ACP context, the Registrar MUST announce itself inside the ACP 303 using GRASP. The Registrar MUST incorporate enough of a GRASP daemon 304 in order to perform the M_FLOOD announcements. 306 As specified in [I-D.ietf-anima-autonomic-control-plane] section 307 6.1.2, in an ACP context, if the Registrar will also be providing for 308 renewal of certificates using EST, then it SHOULD announce itself 309 inside the ACP using GRASP. Unless made impossible due to loading 310 concerns, it is RECOMMENDED that all Registrar instances offer 311 certificate renewal services in this fashion. 313 The use of [I-D.ietf-acme-star] Short-Term Automatically-Renewed 314 Certificates is RECOMMENDED. This mandates that the EST server be 315 highly available. If STAR-style renewals are not used, then the 316 Certificate Authority will need to make OCSP or CRL Distribution 317 points available. 319 1.3.5. Certificate Authority 321 If the Enterprise/ISP has an existing certificate authority system 322 that it wishes to use, then an interface to it has to be enabled. 323 This may run protocols like EST, CMP or ACME. 325 Smaller Enterprises and Residential uses of BRSKI are encouraged to 326 use an internal (private) certificate authority. See Section 3 for a 327 discussion of securing this CA. 329 1.3.6. Management Interface 331 The Registrar will require a management interface. As is the trend, 332 this will often be a web-based single page application using AJAX API 333 calls to perform communications. This interface SHOULD be made 334 available on the Southbound NOC interface only, and it MUST be on a 335 different IP address and port number then the BRSKI-EST interface. 336 It should be secured with HTTPS, and use of a public ([WebPKI]) 337 anchor is reasonable as it may be that the internal certificate 338 authority may be unavailable or require maintenance. 340 An entirely separate process is justified with the only connection to 341 the other procesess being the database. (This does not mean it can 342 not share code modules) 344 2. Connecting the Autonomic Control Plane to the Network Operations 345 Center (NOC) 347 [I-D.ietf-anima-autonomic-control-plane] section 8.1 describes a 348 mechanism to connect non-ACP capable systems to the ACP. The use of 349 this mechanism is critical to incremental deployment of ANIMA and 350 BRSKI in operators. 352 The deployment of BRSKI capable equipment would ideally occur in a 353 concentric ring outward from the NOC. This would start by an upgrade 354 of the router that connects the NOC to the production network. This 355 device needs to support the ACP connect functionality. 357 It is possible, but beyond the scope of this document, to do initial 358 connectivity of the ACP and of multiple NOCs by manually configured 359 IPsec tunnels. This is likely an important step for incremental 360 initial deployment. 362 The Registrar described in the next section either needs to be 363 connected via one of the above mentioned tunnels, or it must be 364 located on a network with ACP Connect, or it must itself be part of 365 an automatically configured ACP. It is quite reasonable for the 366 Registrar to be part of a larger appliance that also includes an ACP 367 Connect functionality. 369 3. Public Key Infrastructure Recommendations for the Registrar 371 The Registrar requires access to, or must contain a Certificate 372 Authority (CA). 374 This section deals with the situation where the CA is provided 375 internally. [I-D.friel-acme-integrations] deals with the case where 376 the CA is provided by an external service, and the CA trust anchors 377 are public. These use ACME ([RFC8555]) is used as the interface. 378 That is out of scope for this document. 380 There are also a number of commercial offerings where a private CA is 381 operated by an external entity using a wide variety of protocols, 382 including proprietary ones. Those are also out of scope for this 383 document. 385 The requirements for the PKI depends upon what kind of network is 386 being managed. 388 3.1. PKI recommendations for Tier-1/ISP Networks 390 A three-tier PKI infrastructure is appropriate for an ISP. This 391 entails having a root CA created with the key kept offline, and a 392 number of intermediate CAs that have online keys that issue "day-to- 393 day" certificates. 395 Whether the root private key is secured by applying secret-splitting, 396 and then storing the results on multiple USBs key kept in multiple 397 safes, or via Hardware Security Module is a local decision informed 398 by best current practices. 400 The root CA is then used to sign a number of intermediate entities: 401 this will include an intermediate CA for the Registrar that is 402 deployed into each redundant NOC location. Multiple intermediate CAs 403 with a common root provides significantly more security and 404 operational flexibility than attempts to share a private key among 405 locations. 407 While the root CA should have a longevity of at least 5 years, after 408 which it can be resigned rather than re-generated, the intermediate 409 CA keys need only have a 1-2 year duration, and at the end of their 410 lifetime, a new private key should be generated. Shorter periods are 411 possible, but until there is more experience with them, not 412 recommended. The intermediate CA key should be regenerated because 413 the intermediate CA private key will need to be online, available to 414 the Registrar CA system. There are many more opportunities for the 415 key to leak, such as into backups. 417 The intermediate CA is then used to sign End-Entity certificates 418 which are returned as part of the BRSKI-EST mechanism. 420 The Registrar needs client and server certificates for it's BRSKI-EST 421 and BRSKI-MASA connections. It is recommended that an additional 422 intermediate CA be created for manually issued certificates such as 423 these. This intermediate CA could be called the NOC Infrastructure 424 CA, and could be used to issue certificates for all manner of 425 infrastructure such as web-based monitoring tools. The private root 426 CA certificate should be installed into the browsers of NOC 427 personnel. 429 The document [I-D.moskowitz-ecdsa-pki] provides some practical 430 instructions on setting up this kind of system. This document 431 recommends the use of ECDSA keys for the root and intermediate CAs, 432 but there may be operational reasons why an RSA intermediate CA will 433 be required for some legacy equipment. 435 3.1.1. Enterprise Network 437 Enterprises that have multiple Network Operations Center should 438 consider the recommendations above for an ISP. 440 This section applies to Enterprises that have all NOC operations/ 441 personel into a single location. This is not a hard rule for 442 scaling, but the intent is that physical security for the ACP Connect 443 network is rather easy, that only a single legal jurisdiction will 444 apply, and that it is possible to get people together easily to do 445 things like resign keys. 447 A three-tier PKI infrastructure is still recommended for the reason 448 that it provides operational continuity options not available with a 449 two-level system. The recommendation is to have a root CA mechanism 450 installed on a Virtual Machine which is not connected to a network. 451 The root CA private key is kept offline, secret split among a number 452 of USB keys, kept in the possession of key personnel. 454 The secret split should have at least five components, of which at 455 least three are required to reconstruct the key. See 456 [I-D.hallambaker-mesh-udf] section 4.5 for one such mechanism, there 457 are many others, and there are no interoperability requirements for 458 the secret split. 460 The essential point is that the Enterprise is able to recover the 461 root CA key even without some number of personnel and is able to 462 continue operating it's network. 464 As in the ISP case, the intermediate CA is then used to sign End- 465 Entity certificates which are returned as part of the BRSKI-EST 466 mechanism. One intermediate CA key suffices as there is only one NOC 467 location with a Registrar. Incidental keys for internal operations, 468 and for the BRSKI-EST server certificate can be done with this single 469 intermediate CA. 471 The BRSKI-MASA TLS Client Certificate key for an enterprise may not 472 be needed; it depends upon the policies of the manufacturers which 473 are involved. It may be simpler to use a certificate produced by a 474 public CA (such as LetsEncrypt), as this makes it easier for 475 manufacturers to validate the provided certificate. 477 The document [I-D.moskowitz-ecdsa-pki] provides some practical 478 instructions on setting up this kind of system. This document 479 recommends the use of ECDSA keys for the root and intermediate CAs. 480 In an Enterprise, there are likely many more legacy devices that 481 might need to become involved in the secure domain. It is 482 recommended that an RSA root and intermediate CA be more strongly 483 considered. 485 3.1.2. Home Network 487 Home networks and small offices that use residential class equipment 488 are the most challenging situation. The three-tier PKI architecture 489 is not justified because the ability to keep the root CA offline has 490 no operational value. 492 The home network registrar should be initialized with a single key 493 pair used as the certificate authority. 495 Secret splitting is useful in order to save the generated key with a 496 few neighbours. It is recommended that the entire PKI system 497 database (including CA private key) be encrypted with a symmetric key 498 and the results made available regularly for download to a variety of 499 devices. The symmetric key is split among the neighbours. 501 The most difficult part of the Home Network PKI and Registrar is 502 where to locate it. Generally it should be located on a device that 503 is fully owned by the home user. This is sometimes the Home Router, 504 but in a lot of situations the Home Router is the ISP's CPE router. 505 If the home has a Network Attached Storage (NAS) system, then running 506 it there is probably better. 508 A compromise for CPE devices owned by the ISP that can run containers 509 is for the Registrar to be located on detachable storage that is 510 inserted into the CPE. The detachable storage is owned by the home 511 owner, and can be removed from the CPE device if it is replaced. 512 More experience will be necessary in order to determine if this is a 513 workable solution. 515 4. Architecture Considerations for the Registrar 517 There are a number of ways to scale the Registrar. Web framework 518 three-tier mechanisms are the most obvious. See [threetier] for an 519 overview. This architecture is very familiar and can work well for a 520 Registrar. There are a few small issues that need to be addressed 521 relating to the TLS connections. 523 The BRSKI-EST connection uses TLS Client Certificate information, so 524 it is necessary for the presentation tier to pass the entire 525 certificate through to the application layer. The presentation tier 526 MUST accept all Client Certificates, many of which might it might not 527 have anchors for. 529 In addition, the Registrar Voucher-Request MUST be signed using the 530 same key pair that is used to terminate the TLS connection, so the 531 application layer will need access to the same keypair that the 532 presentation tier uses. This can be operationally challenging if the 533 presentation tier is provided by a hardware-based TLS load balancer. 535 For this reason, an alternate architecture where the front-end load 536 balancer provides TCP level load balancing, leaving the TLS 537 operations to software TLS implementations in the application layer 538 may be simpler to build. Given that the Registrar is an inward 539 facing system, and is not subject to the Internet-scale loads typical 540 of "Black Friday" web system, the same kind of extreme scaling is not 541 necessary. 543 The BRSKI-EST flow includes a back-end call to the BRSKI-MASA flow. 544 That is, during the BRSKI-EST /voucherrequest call, a voucher will 545 need to be fetched from the MASA using a BRSKI-MASA connection. 546 There are three ways to do this. 548 4.1. Completely Synchronous Registrar 550 In this simplest version the Registrar operates as a single thread, 551 processing the voucher-request from the Pledge, and then starting a 552 BRSKI-MASA client session, while the connection from the Pledge 553 waits. 555 This flow is very simple to implement, but requires an entire 556 processing thread to block while the BRSKI-MASA protocol executes. 557 The Pledge may timeout on this request, disconnect and retry. 558 Experience so far is that typical default timeouts work fine. 560 It is recommended that the voucher-request be recorded in a database, 561 and if a corresponding fresh voucher is also found in the database, 562 that it be returned rather than fetching a new voucher from the MASA. 563 This accomodates the situation where the Pledge did timeout, but the 564 BRSKI-MASA protocol did complete. This results in the Pledge 565 receiving the voucher upon retrying without having to go through the 566 process of getting a new voucher. This only works if the Pledge 567 retries with the same Nonce each time. 569 4.2. Partially Synchronous Registrar 571 A slightly more complicated version is for the Registrar to look in a 572 database for a matching voucher-request, and if none is found, to 573 return a 202 code upon the voucher-request, asking the Pledge to 574 retry. 576 In the meantime the BRSKI-MASA connection can be performed, and the 577 resulting voucher stored in a database. The connection can be done 578 in the same thread that just deferred the connection, or in another 579 thread kicked off for this purpose. 581 4.3. Asynchronous Registrar 583 In the completely asynchronous architecture, things work as with the 584 Partially Synchronous version. The voucher request is placed into a 585 database as before. 587 A completely separate system, probably with different network 588 connectivity, but connected to the same database, performs the BRSKI- 589 MASA processing, then fills the database with the answer. 591 This version may have a noticeably higher latency as it requires a 592 database operation and a database trigger to invoke the process. 593 This architecture has the advantage that the internal facing 594 Registrar never connects to the Internet. Furthermore, the number of 595 internal facing Registrar instances can be tuned independently from 596 the number of outward facing clients. This may be an advantage for 597 networks that need to deal with a high number of malicious or lost 598 internal clients. 600 5. Certificates needed for the Registrar 602 In addition to hosting a PKI root, the Registrar needs several other 603 key pairs. They are: 605 5.1. TLS Server Certificate for BRSKI-EST 607 A certificate to be used to answer TLS connections from new devices 608 (pledges). This must be of a type that expected pledges can 609 understand. Returning an RSA key to a client that can validate only 610 ECDSA chains is a problem. The constrained IoT ecosystem prefers 611 ECDSA, and often does not have code that can verify RSA. Meanwhile, 612 older FIPS-140 validated libraries present in many router operating 613 systems support only RSA! 615 The recommendation is to use ECDSA keys, with a sensitiviity to when 616 a majority of systems might support EdDSA. There are well 617 established mechanisms in most TLS server libraries to permit 618 multiple certificates to be loaded and to return an appropriate key 619 based upon the client capabilities. This should be used. 621 The certificate used for the BRSKI-EST end point is not validated by 622 the BRSKI pledge using public trust anchors, but rather it is pinned 623 by the [RFC8366] voucher. As such it can come from the private CA, 624 as recommended above: either signed by a specific intermediate CA or 625 via a root CA as appropriate for the environment. 627 5.2. TLS Client Certificate for BRSKI-MASA 629 A certificate may optionally be used for authentication of the 630 Registrar to the MASA. It is recommended to always include one. 632 It can be the same certificate used by TLS Server Certificate above, 633 and this is most appropriate in small Registrars which are not 634 distributed, such as ones aimed as Residential/Home networks. 636 In larger, distributed Registrars, cryptographic hygiene dictates 637 that the private key not be distributed, so a unique certificate per 638 Registrar client is appropriate. They should all be signed by the 639 same intermediate CA, with the intermediate and root CA certificates 640 being supplied in the TLS connection. 642 5.3. Certificate for signing of Voucher-Requests 644 As part of the BRSKI voucher-request process the Pledge's Voucher- 645 Request is wrapped by the Registrar in another voucher-request and 646 signed. It is this certificate which which pinned by MASA to 647 validate the connection. 649 The certificate used to sign the voucher-request MUST be the same as 650 the one that is used for the TLS Server Connection. This implies 651 that the signed voucher-request MUST be constructed on the same 652 machine that terminates the BRSKI-EST MASA connection. 654 6. Privacy Considerations 656 Section 10.2 of [I-D.ietf-anima-bootstrapping-keyinfra] details a 657 number of things that are revealed by the BRSKI-EST protocol. A 658 multi-location Registrar with different TLS Server Certificates will 659 have a different privacy profile than a Registrar that uses only a 660 single certificate. 662 Section 10.3 of [I-D.ietf-anima-bootstrapping-keyinfra] details what 663 is revealed by the BRSKI-MASA protocol. The operational 664 recommendations of this document do not affect or mitigate things at 665 all. 667 7. Security Considerations 669 Section 11 of [I-D.ietf-anima-bootstrapping-keyinfra] does not deal 670 with any attacks against the Registrar, as the Registrar is 671 considered to be an internally facing system. 673 In the context of the Autonomic Control Plane 674 ([I-D.ietf-anima-bootstrapping-keyinfra] section 9, and 675 [I-D.ietf-anima-autonomic-control-plane]) it is expected that the 676 majority of equipment attached to a network are connected by wired 677 ethernet. The opportunity for a massive attack against the Registrar 678 is considered low in an ISP, or multi-side Enterprise backbone 679 network. 681 7.1. Denial of Service Attacks against the Registrar 683 However, there are some exposures which need to be taken into 684 account, particular in the Enterprise or Institutional Campus 685 network: typically these networks have large number of access ports, 686 one for each desktop system. Those systems can be infected with 687 Malware, or may be located in student computer labs physically 688 accessible with minimal authorization. While an attack on the 689 Registrar might be part of some kind of student protest, an attack by 690 malware seems more likely. 692 The different architectures proposed in Section 4 of this document 693 provides some recommendations on differing scales. The use of a 694 fully asynchronous design is recommended for Enterprise uses of BRSKI 695 where there may be a large number of IoT devices that are expected to 696 onboard. The ability to scale the BRSKI-EST Pledge Interface without 697 having the scale the rest of the system provides for resiliency of 698 the Registrary. 700 It bears repeating that the use of of a stateless technology in the 701 Join Proxy moves the load due to attacking systems from the Join 702 Proxy into the Registrar. This increases the network bandwidth 703 required from the Join Proxy to the Registrar with the benefit of 704 simplifying the Join Proxy. 706 This is an intentional design decision to centralize the impact into 707 the purpose built Registrar system(s). 709 7.2. Loss of Keys/Corruption of Infrastructure 711 In Home/Residential Network ("homenet") uses of 712 [I-D.ietf-anima-bootstrapping-keyinfra] the biggest risk is likely 713 that of loss of the Registrar's key pairs. Not to a malicious entity 714 that steals them with intent to cause damage, but from outright loss. 716 This can be due to failure to backup the database followed by a CPE 717 device failure, but the case where a CPE device is simply thrown away 718 to be replaced by an uninformed technician is probably the most 719 likely situation. 721 This situation results in loss of control for all devices in the 722 home, and much frustration from the home owner who has to go through 723 an onboarding process for all the devices. The use of a standardized 724 onboarding protocol significantly mitigates the hassle; the current 725 "state of the art" proccess involves a series of appliance-specific 726 smartphone applications, which may or not not actually work on more 727 recent devices. 729 This is why the focus on saving of the database along with a secret 730 splitting process to secure it. At present there is no cross-vendor 731 format for this database, so the saved data is only useable with a 732 Registrar from the same vendor. So this protects against device 733 failure, where it is replaced by an identical device or an upward 734 compatible device from the same manufacturer, but not against changes 735 of vendor. 737 8. IANA Considerations 739 This document makes no IANA allocations. 741 9. Acknowledgements 743 Your name here. 745 10. Changelog 747 11. References 749 11.1. Normative References 751 [I-D.ietf-acme-star] 752 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 753 Fossati, "Support for Short-Term, Automatically-Renewed 754 (STAR) Certificates in Automated Certificate Management 755 Environment (ACME)", draft-ietf-acme-star-11 (work in 756 progress), October 2019. 758 [I-D.ietf-anima-autonomic-control-plane] 759 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 760 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 761 plane-21 (work in progress), November 2019. 763 [I-D.ietf-anima-bootstrapping-keyinfra] 764 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 765 and K. Watsen, "Bootstrapping Remote Secure Key 766 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 767 keyinfra-30 (work in progress), November 2019. 769 [I-D.ietf-anima-constrained-voucher] 770 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 771 Voucher Artifacts for Bootstrapping Protocols", draft- 772 ietf-anima-constrained-voucher-05 (work in progress), July 773 2019. 775 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 776 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 777 May 2017, . 779 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 780 "A Voucher Artifact for Bootstrapping Protocols", 781 RFC 8366, DOI 10.17487/RFC8366, May 2018, 782 . 784 11.2. Informative References 786 [I-D.friel-acme-integrations] 787 Friel, O., Barnes, R., and R. Shekh-Yusef, "ACME 788 Integrations", draft-friel-acme-integrations-02 (work in 789 progress), October 2019. 791 [I-D.hallambaker-mesh-udf] 792 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 793 Data Fingerprint.", draft-hallambaker-mesh-udf-07 (work in 794 progress), October 2019. 796 [I-D.moskowitz-ecdsa-pki] 797 Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, 798 "Guide for building an ECC pki", draft-moskowitz-ecdsa- 799 pki-07 (work in progress), August 2019. 801 [I-D.richardson-anima-state-for-joinrouter] 802 Richardson, M., "Considerations for stateful vs stateless 803 join router in ANIMA bootstrap", draft-richardson-anima- 804 state-for-joinrouter-02 (work in progress), January 2018. 806 [ieee802-1AR] 807 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 808 2009, . 811 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 812 "Enrollment over Secure Transport", RFC 7030, 813 DOI 10.17487/RFC7030, October 2013, 814 . 816 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 817 Kasten, "Automatic Certificate Management Environment 818 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 819 . 821 [threetier] 822 Wikipedia, ., "Multitier architecture", December 2019, 823 . 825 [WebPKI] CA/Browser Forum, ., "CA/Browser Forum Baseline 826 Requirements for the Issuance and Management of Publicly- 827 Trusted Certificates, v.1.2.2", October 2014, 828 . 830 Author's Address 832 Michael Richardson 833 Sandelman Software Works 835 Email: mcr+ietf@sandelman.ca