idnits 2.17.1 draft-richardson-anima-voucher-delegation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 == Line 316 has weird spacing: '...ndatory false...' -- The document date (March 09, 2020) is 1506 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) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-35 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-07 Summary: 1 error (**), 0 flaws (~~), 4 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 L. Xia 5 Expires: September 10, 2020 Huawei 6 March 09, 2020 8 Delegated Authority for Bootstrap Voucher Artifacts 9 draft-richardson-anima-voucher-delegation-01 11 Abstract 13 This document describes an extension of the RFC8366 Voucher Artifact 14 in order to support delegation of signing authority. The initial 15 voucher pins a public identity, and that public indentity can then 16 issue additional vouchers. This chain of authorization can support 17 permission-less resale of devices, as well as guarding against 18 business failure of the BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] 19 Manufacturer Authorized Signing Authority (MASA). 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 September 10, 2020. 38 Copyright Notice 40 Copyright (c) 2020 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements for the Delegation . . . . . . . . . . . . . 3 57 1.1.1. Device Onboarding with Disconnected or Offline MASA . 3 58 1.1.2. Resale of Devices . . . . . . . . . . . . . . . . . . 3 59 1.1.3. Crypto-agility for Registrar . . . . . . . . . . . . 3 60 1.1.4. Transparent Assemblers/Value-Added-Resellers . . . . 4 61 1.2. Overview of Proposed Solution . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Delegation Voucher Artifact . . . . . . . . . . . . . . . . . 5 64 3.1. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Bundling of The Vouchers . . . . . . . . . . . . . . . . 8 66 3.3. Delegation of Multiple Devices . . . . . . . . . . . . . 9 67 4. Enhanced Pledge Behavior . . . . . . . . . . . . . . . . . . 9 68 5. Changes to Registrar Behavior . . . . . . . . . . . . . . . . 10 69 5.1. Discovering The Most Recent Delegated Authority to Use . 10 70 6. Applying The Delegation Voucher to Requirements . . . . . . . 11 71 6.1. applicability one . . . . . . . . . . . . . . . . . . . . 11 72 6.2. applicability two . . . . . . . . . . . . . . . . . . . . 11 73 7. Constraints on Pinning The Delegated Authority . . . . . . . 11 74 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9.1. YANG Module Security Considerations . . . . . . . . . . . 11 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 10.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 12 79 10.2. YANG Module Names Registry . . . . . . . . . . . . . . . 12 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 81 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 13.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Appendix A. Extra references . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 The [RFC8366] voucher artifact provides a proof from a manufacturer's 91 authorizing signing authority (MASA) of the intended owner of a 92 device. This is used by an onboarding Pledge device in BRSKI 93 ([I-D.ietf-anima-bootstrapping-keyinfra], 94 [I-D.ietf-anima-constrained-voucher]), and SZTP ([RFC8572]). 96 There are a number of criticisms of the MASA concept. They include: 98 o the MASA must be reachable to the Registar during the onboarding 99 process. 101 o while the use of a nonceless voucher (see {{RFC8366} section 4) 102 can permit the MASA to be offline, it still requires the public 103 key/certificate of the Registrar to be known at issuing time. The 104 device owner is always strongly dependent on the MASA service. 106 o the MASA must approve all transfers of ownership, impacting the 107 rights of the supply chain distributors to transfer ownership as 108 they see fit. 110 o if the Registrar has any nonceless vouchers, then it can not 111 change it's public key, nor can it change which certification 112 authority it uses. 114 o it is not possible for a MASA to pin ownership to a Registrar by 115 Certification Authority plus DN. 117 o the creator of an assembly of parts/components can speak for the 118 entire assembly of parts in a transparent way. 120 1.1. Requirements for the Delegation 122 This voucher artifact satisfies the following requirements: 124 1.1.1. Device Onboarding with Disconnected or Offline MASA 126 A Registrar wishes to onboard devices while it is not being connected 127 to the Internet and MASA. 129 1.1.2. Resale of Devices 131 An owner of a device wishes to resale it which has previously been 132 onboarded to a third party without specific authorization from the 133 manufacturer. 135 1.1.3. Crypto-agility for Registrar 137 The owner/manager of a registrar wishes to be able to replace its 138 domain registration key. Replacing the registration key would 139 invalidate any previously acquired (nonceless) vouchers. Any devices 140 which have not been onboarded, or which need to be factory reset, 141 would not trust a replacement key. 143 1.1.4. Transparent Assemblers/Value-Added-Resellers 145 An assembly may consist of a number of parts which are onboarded to a 146 local controller during the manufacturing process. Subsequent to 147 this, the entire assembly will be shipped to a customer who wishes to 148 onboard all the components. The sub-components of the assembly needs 149 to communicate with other sub-components, and so all the parts need 150 to transparently onboarded. (This is contrasted with an assembly 151 where the controller acts as a security gateway. Such a gateway 152 might be a single point of failure) 154 Assemblies may nest quite deeply. 156 1.2. Overview of Proposed Solution 158 The MASA will issue a voucher that delegates it's signing authority 159 for one or more devices to a specific Registrar. This is called a 160 "delegation voucher". 162 This Registrar can then operate as an authorized signing authority 163 for the manufacturer, and can subsequently issue additional vouchers 164 binding the pledge to new Registrars. 166 This delegation can potentially be repeated multiple times to enable 167 second, third, or n-th level of resale. 169 The delegation voucher may be stored by the pledge for storage, to be 170 included by the pledge in subsequent bootstrap operations. The 171 inclusion of the delegation voucher permits next Registrar with 172 heuristics that permit it to find the delegated authorized signing 173 authority (DASA). 175 The delegation voucher pins the identity of the delegated authority 176 using a variety of different mechanisms which are covered in 177 Section 7. 179 2. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in 184 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 185 capitals, as shown here. 187 Delegated Authorized Signing Authority : the Delegated Authorized 188 Signing Authority (DASA) is a service that can generate vouchers 189 for one or more pledges to provide bootstrap authority, which is 190 separated and delegated from the manufacturer. 192 Delegation Voucher: a Delegation Voucher is an [RFC8366] format 193 voucher that has additional fields to provide details of the 194 entity to which authority has been delegated. 196 Intermediate Voucher: a voucher that is not the final voucher 197 linking a pledge to its owner. 199 End Voucher: a voucher that is the final voucher linking a pledge to 200 its owner. 202 3. Delegation Voucher Artifact 204 The following tree diagram shows the extensions to the [RFC8366] 205 voucher. 207 There are a few new fields: 209 pinned-delegation-certificate-authority: An subject-public-key-info 210 for a public key of the new DASA 212 pinned-delegation-name: A string for the rfc822Name SubjectAltName 213 contents of the new DASA; (XXX- is it enough, should other DNs be 214 considered?) 216 delegation-voucher: One or a series of Intermediate Vouchers that 217 delegate authority to the DASA. For the latter case, the series 218 of Intermediate Vouchers constitute a nested structure, and the 219 most inner voucher is from the MASA, which is called terminal 220 voucher here 222 intermediate-identities: A set of voucher identities being 223 consistent with the series of Intermediate Vouchers 225 delegation-countdown: Number of delegations still available. If 226 zero or omitted, then this is a terminal voucher and may not be 227 further delegated. 229 In addition, the serial-number field is no longer a plain leaf, but 230 can also be an array (See Section 3.3). 232 module: ietf-delegated-voucher 234 grouping voucher-delegated-grouping 235 +-- voucher 236 +-- created-on yang:date-and-time 237 +-- expires-on? yang:date-and-time 238 +-- assertion enumeration 239 +-- serial-number string 240 +-- idevid-issuer? binary 241 +-- pinned-domain-cert? binary 242 +-- domain-cert-revocation-checks? boolean 243 +-- nonce? binary 244 +-- last-renewal-date? yang:date-and-time 245 +-- pinned-certificate-authority? binary 246 +-- pinned-certificate-name? binary 247 +-- delegation-voucher? binary 248 +-- intermediate-identities? binary 249 +-- delegation-countdown? int16 251 3.1. YANG Module 253 This module uses the grouping that was created in [RFC8366] to extend 254 the definition. 256 file "ietf-delegated-voucher@2020-01-06.yang" 257 module ietf-delegated-voucher { 258 yang-version 1.1; 260 namespace 261 "urn:ietf:params:xml:ns:yang:ietf-delegated-voucher"; 262 prefix "delegated"; 264 import ietf-restconf { 265 prefix rc; 266 description 267 "This import statement is only present to access 268 the yang-data extension defined in RFC 8040."; 269 reference "RFC 8040: RESTCONF Protocol"; 270 } 272 // maybe should import from constrained-voucher instead! 273 import ietf-voucher { 274 prefix "v"; 275 } 277 organization 278 "IETF ANIMA Working Group"; 280 contact 281 "WG Web: 282 WG List: 283 Author: Michael Richardson 284 "; 286 description 287 "This module extends the RFC8366 voucher format to provide 288 a mechanism by which the authority to issue additional vouchers 289 may be delegated to another entity 291 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 292 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 293 and 'OPTIONAL' in the module text are to be interpreted as 294 described in BCP 14 RFC 2119, and RFC8174."; 296 revision "2020-01-06" { 297 description 298 "Initial version"; 299 reference 300 "RFC XXXX: Voucher Profile for Delegation Vouchers"; 301 } 303 rc:yang-data voucher-delegated-artifact { 304 // YANG data template for a voucher. 305 uses voucher-delegated-grouping; 306 } 308 // Grouping defined for future usage 309 grouping voucher-delegated-grouping { 310 description 311 "Grouping to allow reuse/extensions in future work."; 313 uses v:voucher-artifact-grouping { 315 refine voucher/pinned-domain-cert { 316 mandatory false; 317 } 319 augment "voucher" { 320 description "Base the delegated voucher 321 upon the regular one"; 323 leaf pinned-certificate-authority { 324 type binary; 325 description 326 "An subject-public-key-info for a public key of the 327 certificate authority that is to be trusted to issue 328 a voucher to the Registrar. 329 This is not used by end-vouchers."; 330 } 332 leaf pinned-certificate-name { 333 type binary; 334 description 335 "A string for the rfc822Name SubjectAltName contents 336 which will be trusted to issue vouchers. 337 This is not used by end-vouchers."; 338 } 340 leaf delegation-voucher { 341 type binary; 342 description 343 "The intermediate voucher that delegates 344 authority to the entity that signs this voucher 345 is to be included here."; 346 } 348 leaf intermediate-identities { 349 type binary; 350 description 351 "A set of identities that will be needed to 352 validate the chain of vouchers. MAY BE REDUNDANT"; 353 } 355 leaf delegation-countdown { 356 type int16; 357 description 358 "Number of delegations still available. If zero 359 or omitted, then this is a terminal voucher and 360 may not be further delegated"; 361 } 362 } 363 } 364 } 365 } 366 368 3.2. Bundling of The Vouchers 370 The [I-D.ietf-anima-bootstrapping-keyinfra] defines a mechanism to 371 return a single voucher to the pledge. 373 This protocol requires a number of additional items to be returned to 374 the pledge for evaluation: the series of Intermediate Vouchers that 375 leads to the DASA, and the public keys (often as certificates) of the 376 Registrars on the Delegation Path that leads to each Authority. 378 3.3. Delegation of Multiple Devices 380 A MASA MAY delegate multiple devices to the same Registrar by putting 381 an array of items in the "serial-number" attributes. (XXX-how to 382 describe this in the YANG, and the detailed mechanism, are TBD) 384 4. Enhanced Pledge Behavior 386 The use of a Delegation Voucher requires changes to how the pledge 387 evaluates the voucher that is returned to by the Registrar. 389 There are no significant changes to the voucher-request that is made. 390 The pledge continues to pin the identity of the Registrar to which it 391 is connected, providing a nonce to establish freshness. 393 A pledge which has previously stored a Delegation Voucher and DASA , 394 SHOULD include it in its voucher request. This will be in the form 395 of a certificate provided by the "previous" owner. This allows the 396 Registrar to discover the previous authority for the pledge. As the 397 pledge has no idea if it connecting to an entity that it previously 398 has connected to, it needs to include this certificate anyway. 400 The pledge receives a voucher from the Registrar. This voucher is 401 called the zero voucher. It will observe that the voucher is not 402 signed with its built-in manufacturer trust anchor and it can not 403 verify it. 405 The pledge will examine the voucher to look for the "delegation- 406 voucher" and the "intermediate-identities" attributes within the 407 voucher. A certificate from the set of intermediate-identities is 408 expected to validate the signature on this zeroth end-entity voucher. 409 (XXX- This attribute can be replaced by the CMS certificate chain) 411 The contained delegation-voucher object is to be interpreted as an 412 (Intermediate) Voucher. This first voucher is called the first 413 voucher, or "voucher[1]". Generically, for voucher[i], the voucher 414 found in the delegation-voucher is called voucher[i+1]. 416 If voucher[i] can be validated by a built-in trust anchor, then the 417 process is done. If not, then voucher[i] is examined in a recursive 418 process until there are no further embedded vouchers. The last 419 voucher[n] is expected to be validated by a built-in manufacturer 420 trust anchor. 422 Once the top (n-th) voucher is found, then the pinned-certificate- 423 authority is added to the working set of trust anchors. The "pinned- 424 certificate-name" attribute is used along with the trust anchor to 425 validate the certificate chain provided with the (n-1)th voucher. 426 This is repeated (unwinding the recursive processing) until the 427 zeroth voucher has been validated. 429 5. Changes to Registrar Behavior 431 TBD 433 5.1. Discovering The Most Recent Delegated Authority to Use 435 The pledge continues to use its manufacturer issued IDevID when 436 performing BRSKI-style onboarding. The IDevID contains an extension, 437 the MASA URL (see [I-D.ietf-anima-bootstrapping-keyinfra] section 438 2.3.2). The IDevID certificate is not expected to be updated when 439 the device is resold, nor may it be practical for an intermediate 440 owner to be able to replace the IDevID with their own. (Some devices 441 may support having an intermediate owner replace the IDevID, in which 442 case this section does not apply) 444 The Registrar needs to be informed that it should not contact a MASA 445 using the URL in the IDevID, but rather to contact the previous 446 owner's DASA. 448 This can be accomplished by local override, as described in 449 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.4: 451 Registrars MAY include a mechanism to override 452 the MASA URL on a manufacturer-by-manufacturer basis, and within that 453 override it is appropriate to provide alternate anchors. This will 454 typically used by some vendors to establish explicit (or private) 455 trust anchors for validating their MASA that is part of a sales 456 channel integration. 458 The above override needs to be established on a per-device basis. It 459 requires per-device configuration which is very much non-autonomic. 461 There are two other alternatives: 463 1. The Manufacturer could be aware of any Delegation Vouchers that 464 it has issued for a particular device, and when contacted by the 465 Registrar, it could redirect the Registrar to its DASA. And the 466 DASA may redirect the Registrar to its delegated DASA, this 467 process is recursive to the final DASA. 469 2. The Pledge could provide a signed statement from the manufacturer 470 providing the Registrar with a pointer to the DASA. 472 Option 1 requires that the Registrar still contact the MASA, 473 violating most of the goals from Section 1.1. 475 Option 2 requires a signed artifact, and conveniently, the Delegation 476 Voucher is exactly the item needed. The most difficult problem is 477 that the Pledge needs to (a) store one or more Delegation Vouchers in 478 a non-volatile storage that survives factory reset operations, (b) 479 attach these items to the pledge's voucher-request. 481 The extension to the [I-D.ietf-anima-bootstrapping-keyinfra] voucher- 482 request described below provides for a contained for these Delegation 483 Vouchers. 485 6. Applying The Delegation Voucher to Requirements 487 6.1. applicability one 489 TBD 491 6.2. applicability two 493 TBD 495 7. Constraints on Pinning The Delegated Authority 497 TBD 499 8. Privacy Considerations 501 YYY 503 9. Security Considerations 505 9.1. YANG Module Security Considerations 507 As described in the Security Considerations section of [RFC8366] 508 (section 7.4), the YANG module specified in this document defines the 509 schema for data that is subsequently encapsulated by a CMS signed- 510 data content type, as described in Section 5 of [RFC5652]. As such, 511 all of the YANG modeled data is protected from modification. 513 The use of YANG to define data structures, via the 'yang-data' 514 statement, is relatively new and distinct from the traditional use of 515 YANG to define an API accessed by network management protocols such 516 as NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason, these 517 guidelines do not follow template described by Section 3.7 of 518 [RFC8407]. 520 10. IANA Considerations 522 This document requires the following IANA actions: 524 10.1. The IETF XML Registry 526 This document registers a URI in the "IETF XML Registry" [RFC3688]. 527 IANA is asked to register the following: 529 URI: urn:ietf:params:xml:ns:yang:ietf-delegated-voucher 530 Registrant Contact: The ANIMA WG of the IETF. 531 XML: N/A, the requested URI is an XML namespace. 533 10.2. YANG Module Names Registry 535 This document registers a YANG module in the "YANG Module Names" 536 registry [RFC6020]. IANA is asked to register the following: 538 name: ietf-delegated-voucher 539 namespace: urn:ietf:params:xml:ns:yang:ietf-delegated-voucher 540 prefix: NONE 541 reference: THIS DOCUMENT 543 11. Acknowledgements 545 Hello. 547 12. Changelog 549 13. References 551 13.1. Normative References 553 [I-D.ietf-anima-bootstrapping-keyinfra] 554 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 555 and K. Watsen, "Bootstrapping Remote Secure Key 556 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 557 keyinfra-35 (work in progress), February 2020. 559 [I-D.ietf-anima-constrained-voucher] 560 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 561 Voucher Artifacts for Bootstrapping Protocols", draft- 562 ietf-anima-constrained-voucher-07 (work in progress), 563 January 2020. 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, 567 DOI 10.17487/RFC2119, March 1997, 568 . 570 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 571 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 572 May 2017, . 574 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 575 "A Voucher Artifact for Bootstrapping Protocols", 576 RFC 8366, DOI 10.17487/RFC8366, May 2018, 577 . 579 13.2. Informative References 581 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 582 DOI 10.17487/RFC3688, January 2004, 583 . 585 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 586 RFC 5652, DOI 10.17487/RFC5652, September 2009, 587 . 589 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 590 the Network Configuration Protocol (NETCONF)", RFC 6020, 591 DOI 10.17487/RFC6020, October 2010, 592 . 594 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 595 and A. Bierman, Ed., "Network Configuration Protocol 596 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 597 . 599 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 600 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 601 . 603 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 604 Documents Containing YANG Data Models", BCP 216, RFC 8407, 605 DOI 10.17487/RFC8407, October 2018, 606 . 608 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 609 Touch Provisioning (SZTP)", RFC 8572, 610 DOI 10.17487/RFC8572, April 2019, 611 . 613 Appendix A. Extra references 615 RFC Editor, please remove this section. This section lists 616 references in the YANG. [RFC8174], [RFC8040]. 618 Authors' Addresses 620 Michael Richardson 621 Sandelman Software Works 623 Email: mcr+ietf@sandelman.ca 625 Liang Xia (Frank) 626 Huawei 628 Email: frank.xialiang@huawei.com