idnits 2.17.1 draft-richardson-anima-masa-considerations-05.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 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 178: '...the manufacturer SHOULD plan for a sit...' RFC 2119 keyword, line 189: '...tting mechanisms SHOULD be employed. ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 March 2021) is 1141 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: 'I-D.moskowitz-ecdsa-pki' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'BedOfNails' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'RambusCryptoManager' is defined on line 489, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-richardson-t2trg-idevid-considerations-01 ** Downref: Normative reference to an Informational draft: draft-richardson-t2trg-idevid-considerations (ref. 'I-D.richardson-t2trg-idevid-considerations') == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-09 == Outdated reference: A later version (-08) exists of draft-richardson-anima-registrar-considerations-04 == Outdated reference: A later version (-10) exists of draft-moskowitz-ecdsa-pki-09 ** Downref: Normative reference to an Informational draft: draft-moskowitz-ecdsa-pki (ref. 'I-D.moskowitz-ecdsa-pki') -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). 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 J. Yang 5 Expires: 13 September 2021 Huawei Technologies Co., Ltd. 6 12 March 2021 8 Operatonal Considerations for Voucher infrastructure for BRSKI MASA 9 draft-richardson-anima-masa-considerations-05 11 Abstract 13 This document describes a number of operational modes that a BRSKI 14 Manufacturer Authorized Signing Authority (MASA) may take on. 16 Each mode is defined, and then each mode is given a relevance within 17 an over applicability of what kind of organization the MASA is 18 deployed into. This document does not change any protocol 19 mechanisms. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 13 September 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Operational Considerations for Manufacturer Authorized Signing 56 Authority (MASA) . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Self-contained multi-product MASA, no PKI . . . . . . . . 5 58 2.2. Self-contained multi-product MASA, with one-level PKI . . 5 59 2.3. Self-contained per-product MASA . . . . . . . . . . . . . 6 60 2.4. Per-product MASA keys intertwined with IDevID PKI . . . . 7 61 2.5. Rotating MASA authorization keys . . . . . . . . . . . . 8 62 3. Operational Considerations for Constrained MASA . . . . . . . 9 63 4. Operational Considerations for creating Nonceless vouchers . 9 64 5. Business Continuity and Escow Considerations . . . . . . . . 9 65 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 11.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 [I-D.ietf-anima-bootstrapping-keyinfra] introduces a mechanism for 78 new devices (called pledges) to be onboarded into a network without 79 intervention from an expert operator. 81 This mechanism leverages the pre-existing relationship between a 82 device and the manufacturer that built the device. There are two 83 aspects to this relationship: the provision of an identity for the 84 device by the manufacturer (the IDevID), and a mechanism which 85 convinces the device to trust the new owner (the [RFC8366] voucher). 87 The manufacturer, or their designate, is involved in both aspects of 88 this process. This requires the manufacturer (or designate) to 89 maintain on online presence. 91 This document offers a number of operational considerations 92 recommendations. 94 The first aspect is the device identity in the form of an 95 [ieee802-1AR] certificate that is installed at manufacturing time in 96 the device. Some of the background for the operational 97 considerations of building this public key infrastructure is 98 described in [I-D.richardson-t2trg-idevid-considerations]. 100 The second aspect is the use of the Manufacturer Authorized Signing 101 Authority (MASA), as described in 102 [I-D.ietf-anima-bootstrapping-keyinfra] section 2.5.4. The device 103 needs to have the MASA anchor built in; the exact nature of the 104 anchor is open to a number of possibilities which are explained in 105 this document. This document primarily deals with a number of 106 options for architecting the security of the MASA relationship. 108 There are some additional considerations for a MASA that deals with 109 constrained vouchers as described in 110 [I-D.ietf-anima-constrained-voucher]. In particular in the COSE 111 signed version, there may be no PKI structure included in the voucher 112 mechanism, so cryptographic hygiene needs a different set of 113 tradeoffs. 115 2. Operational Considerations for Manufacturer Authorized Signing 116 Authority (MASA) 118 The manufacturer needs to make a Signing Authority available to new 119 owners so that they may obtain [RFC8366] format vouchers to prove 120 ownership. This section initially assumes that the manufacturer will 121 provide this Authority internally, but subsequent sections deal with 122 some adjustments when the authority is externally run. 124 The MASA is a public facing web system. It will be subject to 125 network load from legitimate users when a network is bootstrapped for 126 the first time. The legitimate load will be proportional to sales. 128 The MASA will also be subject to a malicious load: a way to deflect 129 unwanted users from the application framework backend is to require 130 TLS Client Certificates for all connections. This offloads much of 131 the defense to what is typically a hardware TLS termination system. 132 This can be effective even if the hardware is unable to validate the 133 TLS Client Certificate is not validated. This increases the effort 134 requires for attackers, and if they repeat the same certificate then 135 it becomes easier to reject such attackers earlier. The use of this 136 certificate forces attackers to generate new key pairs and 137 certificates each time. The accompanying document 138 [I-D.richardson-anima-registrar-considerations] recommends in section 139 5.2.1 recommends the use of a public anchor, or an anchor that is 140 known to the MASA. 142 Web framework three-tier mechanisms are a very common architecture. 143 See [threetier] for an overview. There are Internet scale frameworks 144 exist for Ruby (RubyOnRails), Python (Django), Java (J2EE), GO, PHP 145 and others. The methods of deploying them and dealing with expected 146 scale are common in most enterprise IT departments. 148 Consideration should be made to deploying the presentation layer into 149 multiple data centers in order to provide resiliency against 150 distributed denial of service (DDoS) attacks that affect all tenants 151 of that data center. 153 Consideration should also be given to the use of a cloud front end to 154 mitigate attacks, however, such a system needs to be able to securely 155 transmit the TLS Client Certificates, if the MASA wants to identify 156 Registrars at the TLS connection time. 158 The middle (application) tier needs to be scalable, but it is 159 unlikely that it needs to scale very much on a per-minute or even 160 per-hour basis. It is probably easier and more reliable to have 161 application tiers do database operations across the Internet or via 162 VPN to a single location database cluster than it is to handle 163 asynchronous database operations resulting from geographically 164 dispersed multi-master database systems. 166 But, these are local design decisions which web deployment make on a 167 regular basis. 169 The assets tables that the MASA needs scale linearly with the number 170 of products sold. 172 Many columns could be replicated in a read-only manner from a sales 173 database. 175 Direct integration with a sales system could be considered, but would 176 involve a more significant security impact analysis. 178 In any case, the manufacturer SHOULD plan for a situation where the 179 manufacturer is no longer able or interested in running the 180 Authority: this does not have to an unhappy situation! While the 181 case of the manufacturer going out of business is discussed in 182 Section 5, there are more happy events which should be prepared for. 183 For instance, if a manufacturer goes through a merge or acquisition 184 and it makes sense to consolidate the Signing Authority in another 185 part of the organization. 187 Business continuity plan should include backing up the voucher 188 signing keys. This may involve multiple Hardware Security Modules, 189 and secret splitting mechanisms SHOULD be employed. For large value 190 items, customers are going to need to review the plan as part of 191 their contingency audits. The document 192 [I-D.richardson-t2trg-idevid-considerations] can provide some common 193 basis for this kind of evaluation. 195 The trust anchors needs to validate [RFC8366] vouchers will typically 196 be part of the firmware loaded inot the devie firmware. 198 There are many models to manage these trust anchors, but in order 199 having only a single key, a PKI infrastructure is appropriate, but 200 not required. 202 On constrained devices without code space to parse and validate a 203 public key certificate chain require different considerations, a 204 single key may be necessary. This document does not (yet) provide 205 appropriate considerations for that case. 207 What follows are a number of ways to construct a resilient PKI to 208 sign vouchers. 210 2.1. Self-contained multi-product MASA, no PKI 212 2.2. Self-contained multi-product MASA, with one-level PKI 214 A simple way is to create an new offline certification authority 215 (CA), have it periodically sign a new End-Entity (EE) identity's 216 certificate. This End-Entity identity should have an online private 217 key, and use that to sign voucher requests. Note that the entity 218 used to sign [RFC8366] format vouchers does not need to be a 219 certificate authority. 221 If the public key of this offline CA is then built-in to the firmware 222 of the device, then the devices do not need any further anchors. 224 There is no requirement for this CA to be signed by any other 225 certification authority. That is, it may be a root CA. There is 226 also no prohibition against it. 228 If the offline CA signs any other certificates, then it is important 229 that the device know which End-Entity certificates may sign vouchers. 230 This is an authorization step, and it may be accomplished it a number 231 of ways: 233 1. the Distinguished Name (DN) of the appropriate End-Entity 234 certificate can be built-in to the firmware 236 2. a particular policy OID may be included in certificates intended 237 to sign vouchers 239 a voucher created for one product could be used to sign a voucher for 240 another product. This situation is also mitigated by never repeating 241 serialNumbers across product lines. 243 An End-Entity certificate used to sign the voucher is included in the 244 certificate set in the CMS structure that is used to sign the 245 voucher. The root CA's trust anchor should _also_ be included, even 246 though it is self-signed, as this permits auditing elements in a 247 Registrar to validate the End-Entity Certificate. 249 The inclusion of the full chain also supports a Trust-on-First-Use 250 (TOFU) workflow for the manager of the Registrar: they can see the 251 trust anchor chain and can compare a fingerprint displayed on their 252 screen with one that could be included in packaging or other sales 253 channel information. 255 When building the MASA public key into a device, only the public key 256 contents matter, not the structure of the self-signed certificate 257 itself. Using only the public key enables a MASA architecture to 258 evolve from a single self-contained system into a more complex 259 architecture later on. 261 2.3. Self-contained per-product MASA 263 A simple enhancement to the previous scenario is to have a unique 264 MASA offline key for each product line. This has a few advantages: 266 * if the private keys are kept separately (under different 267 encryption keys), then compromise of a single product lines MASA 268 does not compromise all products. 270 * if a product line is sold to another entity, or if it has to go 271 through an escrow process due to the product going out of 272 production, then the process affects only a single product line. 274 * it is safe to have serialNumber duplicated among different product 275 lines since a voucher for one product line would not validate on 276 another product line. 278 The disadvantage is that it requires a private key to be stored per 279 product line, and most large OEMs have many dozens of product lines. 280 If the keys are stored in a single Hardware Security Module (HSM), 281 with the access to it split across the same parties, then some of the 282 cryptographic advantages of different private keys will go away, as a 283 compromise of one key likely compromises them all. Given a HSM, the 284 most likely way a key is compromised is by an attacker getting 285 authorization on the HSM through theft or coercion. 287 The use of per-product MASA signing keys is encouraged. 289 2.4. Per-product MASA keys intertwined with IDevID PKI 291 The IDevID certificate chain (the intermediate CA and root CA that 292 signed the IDevID certificate) should be included in the device 293 firmware so that they can be communicated during the BRSKI-EST 294 exchange. 296 Since they are already present, could they be used as the MASA trust 297 anchor as well? 299 In order to do this there is an attack that needs to mitigated. 300 Since the root-CA that creates IDevIDs and the root-CA that creates 301 vouchers are the same, when validating a voucher, a pledge needs to 302 make sure that it is signed by a key authorized to sign vouchers. In 303 other scenarios any key signed by the voucher-signing-root-CA would 304 be valid, but in this scenario that would also include any IDevID, 305 such as would be installed in any other device. Without an 306 additional signal as to which keys can sign vouchers, and which keys 307 are just IDevID keys, then it would be possible to sign vouchers with 308 any IDevID private key, rather than just the designated voucher- 309 signing key. An attacker that could extract a private key from even 310 one instance of a product, could use that to sign vouchers, and 311 impersonate the MASA. 313 The challenge with combining it into the IDevID PKI is making sure 314 that only an authorized entity can sign the vouchers. The solution 315 is that it can not be the same intermediate CA that is used to sign 316 the IDevID, since that CA should have the authority to sign vouchers. 318 The PKI root CA therefore needs to sign an intermediate CA, or End- 319 Entity certificate with an extension OID that is specific for Voucher 320 Authorization. This is easy to do as policy OIDs can be created from 321 Private Enterprise Numbers. There is no need for standardization, as 322 the entity doing the signing is also creating the verification code. 323 If the entire PKI operation was outsource, then there would be a 324 benefit for standardization. 326 2.5. Rotating MASA authorization keys 328 As a variation of the scenario described in Section 2.3, there could 329 be multiple Signing Authority keys per product line. They could be 330 rotated though in some deterministic order. For instance, serial 331 numbers ending in 0 would have MASA key 0 embedded in them at 332 manufacturing time. The asset database would have to know which key 333 that corresponded to, and it would have to produce vouchers using 334 that key. 336 There are significant downsides to this mechanism: 338 * all of the MASA signing keys need to be online and available in 339 order to respond to any voucher request 341 * it is necessary to keep track of which device trust which key in 342 the asset database 344 There is no obvious advantage to doing this if all the MASA signing 345 private keys are kept in the same device, under control of the same 346 managers. But if the keys are spread out to multiple locations and 347 are under control of different people, then there may be some 348 advantage. A single MASA signing authority key compromise does not 349 cause a recall of all devices, but only the portion that had that key 350 embedded in it. 352 The relationship between signing key and device could be temporal: 353 all devices made on Tuesday could have the same key, there could be 354 hundreds of keys, each one used only for a few hundred devices. 355 There are many variations possible. 357 The major advantage comes with the COSE signed constrained-vouchers 358 described in [I-D.ietf-anima-constrained-voucher]. In this context 359 there isn't space in the voucher for a certificate chain, nor is 360 there code space in the device to validate a certificate chain. The 361 (public) key used to sign is embedded directly in the firmware of 362 each device without the benefit of any public key infrastructure to 363 allow indirection of the key. 365 3. Operational Considerations for Constrained MASA 367 TBD 369 4. Operational Considerations for creating Nonceless vouchers 371 TBD 373 5. Business Continuity and Escow Considerations 375 A number of jurisdictions have legal requirements for businesses to 376 have contingency plans in order to continue operating after an 377 incident or disaster. Specifications include [iso22301_2019], but 378 the problem of continuity goes back over 40 years. 380 The [holman2012] document defined an eight tier process to understand 381 how data would be backed up. Tier 0 is "no off-site data", and would 382 be inappropriate for the MASA's signing key. The question as to how 383 much delay (downtime) is tolerable during a disaster for activating 384 new devices. The consideration should depend upon the type of the 385 device, and what kind of disasters are being planned for. Given 386 current technologies for replicating databases online, a tier-4 387 ("Point-in-time copies") or better solution may be quite economically 388 deployed. 390 A key aspect of the MASA is that it was designed as a component that 391 can be outsourced to a third party, and this third party can leverage 392 economies of scale to provide more resilient systems at much lower 393 costs. 395 The PKI components that are used to provision the IDevID 396 certificiates into new devices need to be operational only when the 397 factory that produces the devices is active. The business continuity 398 planning needs to include provision for backing up the private keys 399 used within the PKI. It may be enough to backup just the root CA 400 key: the rest of the levels of the PKI can be regenerated in another 401 location if necessary. 403 6. Privacy Considerations 405 YYY 407 7. Security Considerations 409 ZZZ 411 8. IANA Considerations 413 This document makes no IANA requests. 415 9. Acknowledgements 417 Hello. 419 10. Changelog 421 11. References 423 11.1. Normative References 425 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 426 "A Voucher Artifact for Bootstrapping Protocols", 427 RFC 8366, DOI 10.17487/RFC8366, May 2018, 428 . 430 [I-D.richardson-t2trg-idevid-considerations] 431 Richardson, M. and J. Yang, "A Taxonomy of operational 432 security of manufacturer installed keys and anchors", Work 433 in Progress, Internet-Draft, draft-richardson-t2trg- 434 idevid-considerations-01, 27 August 2020, 435 . 438 [I-D.ietf-anima-constrained-voucher] 439 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 440 Voucher Artifacts for Bootstrapping Protocols", Work in 441 Progress, Internet-Draft, draft-ietf-anima-constrained- 442 voucher-09, 2 November 2020, . 446 [I-D.ietf-anima-bootstrapping-keyinfra] 447 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 448 and K. Watsen, "Bootstrapping Remote Secure Key 449 Infrastructures (BRSKI)", Work in Progress, Internet- 450 Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11 451 November 2020, . 454 [I-D.richardson-anima-registrar-considerations] 455 Richardson, M. and J. Yang, "Operational Considerations 456 for BRSKI Registrar", Work in Progress, Internet-Draft, 457 draft-richardson-anima-registrar-considerations-04, 29 458 July 2020, . 461 [I-D.moskowitz-ecdsa-pki] 462 Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, 463 "Guide for building an ECC pki", Work in Progress, 464 Internet-Draft, draft-moskowitz-ecdsa-pki-09, 9 August 465 2020, . 468 [threetier] 469 Wikipedia, ., "Multitier architecture", December 2019, 470 . 472 [ieee802-1AR] 473 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 474 2009, . 477 11.2. Informative References 479 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 480 "Enrollment over Secure Transport", RFC 7030, 481 DOI 10.17487/RFC7030, October 2013, 482 . 484 [BedOfNails] 485 Wikipedia, "In-circuit test", 2019, 486 . 489 [RambusCryptoManager] 490 Qualcomm press release, "Qualcomm Licenses Rambus 491 CryptoManager Key and Feature Management Security 492 Solution", 2014, . 496 [kskceremony] 497 Verisign, "DNSSEC Practice Statement for the Root Zone ZSK 498 Operator", 2017, . 501 [rootkeyceremony] 502 Community, "Root Key Ceremony, Cryptography Wiki", April 503 2020, 504 . 506 [keyceremony2] 507 Digi-Sign, "SAS 70 Key Ceremony", April 2020, 508 . 511 [nistsp800-57] 512 NIST, "SP 800-57 Part 1 Rev. 4 Recommendation for Key 513 Management, Part 1: General", 1 January 2016, 514 . 517 [iso22301_2019] 518 ISO, "ISO 22301: Societal security — Business continuity 519 management systems — Requirements", 1 January 2019, 520 . 522 [holman2012] 523 Holman, E., "A Business Continuity Solution Selection 524 Methodology", 13 March 2012, 525 . 529 Authors' Addresses 531 Michael Richardson 532 Sandelman Software Works 534 Email: mcr+ietf@sandelman.ca 536 Jie Yang 537 Huawei Technologies Co., Ltd. 539 Email: jay.yang@huawei.com