idnits 2.17.1 draft-ietf-anima-voucher-06.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2017) is 2374 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) == Missing Reference: 'ThisRFC' is mentioned on line 786, but not defined ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-08 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-19 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track M. Richardson 5 Expires: April 28, 2018 Sandelman Software 6 M. Pritikin 7 Cisco Systems 8 T. Eckert 9 Huawei 10 October 25, 2017 12 Voucher Profile for Bootstrapping Protocols 13 draft-ietf-anima-voucher-06 15 Abstract 17 This document defines a strategy to securely assign a pledge to an 18 owner, using an artifact signed, directly or indirectly, by the 19 pledge's manufacturer. This artifact is known as a "voucher". 21 This document defines one artifact format to be a YANG-defined JSON 22 document that has been signed using a CMS structure. Other YANG- 23 derived formats are possible. The voucher artifact is normally 24 generated by the pledge's manufacturer or delegate (i.e. the 25 Manufacturer Authorized Signing Authority). 27 This document only defines the voucher artifact, leaving it to other 28 documents to describe specialized protocols for accessing it. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 28, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 67 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 68 5. Voucher artifact . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 70 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.4. CMS format voucher artifact . . . . . . . . . . . . . . . 13 73 6. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Renewals instead of Revocations . . . . . . . . . . . . . 14 75 6.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 15 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 7.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 15 78 7.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16 79 7.3. Test Domain Certificate Validity when Signing . . . . . . 16 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16 82 8.2. The YANG Module Names Registry . . . . . . . . . . . . . 17 83 8.3. The SMI Security for S/MIME CMS Content Type Registry . 17 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 9.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 This document defines a strategy to securely assign a candidate 93 device (pledge) to an owner, using an artifact signed, directly or 94 indirectly, by the pledge's manufacturer or delegate, i.e. the 95 Manufacturer Authorized Signing Authority (MASA). This artifact is 96 known as the voucher. 98 The voucher artifact is a JSON [RFC7159] document, conforming to a 99 data model described by YANG [RFC7950], encoded using the rules 100 defined in [RFC7159], and signed using (by default) a CMS structure 101 [RFC5652]. 103 A voucher may be useful in several contexts, but the driving 104 motivation herein is to support secure bootstrapping mechanisms. 105 Assigning ownership is important to bootstrapping mechanisms so that 106 the pledge can authenticate the network that's trying to take control 107 of it. 109 The lifetimes of vouchers may vary. In some bootstrapping protocols 110 the vouchers may include a nonce restricting them to a single use, 111 whereas in others the vouchers may have an indicated lifetime. In 112 order to support long lifetimes this document recommends using short 113 lifetimes with programmatic renewal, see Section 6.1. 115 This document only defines the voucher artifact, leaving it to other 116 documents to describe specialized protocols for accessing it. Some 117 bootstrapping protocols using the voucher artifact defined in this 118 draft include: [I-D.ietf-netconf-zerotouch], 119 [I-D.ietf-6tisch-dtsecurity-secure-join], and 120 [I-D.ietf-anima-bootstrapping-keyinfra]). 122 2. Terminology 124 This document uses the following terms (sorted by name): 126 Artifact: The term "artifact" is used throughout to represent the 127 voucher as instantiated in the form of a signed structure. 129 Imprint: The process where a device obtains the cryptographic key 130 material to identify and trust future interactions with a network. 131 This term is taken from Konrad Lorenz's work in biology with new 132 ducklings: "during a critical period, the duckling would assume 133 that anything that looks like a mother duck is in fact their 134 mother." An equivalent for a device is to obtain the fingerprint 135 of the network's root certification authority certificate. A 136 device that imprints on an attacker suffers a similar fate to a 137 duckling that imprints on a hungry wolf. Securely imprinting is a 138 primary focus of this document [imprinting]. The analogy to 139 Lorenz's work was first noted in [Stajano99theresurrecting]. 141 Domain: The set of entities or infrastructure under common 142 administrative control. The goal of the bootstrapping protocol is 143 to enable a Pledge to discover and join a domain. 145 Join Registrar (and Coordinator): A representative of the domain 146 that is configured, perhaps autonomically, to decide whether a new 147 device is allowed to join the domain. The administrator of the 148 domain interfaces with a Join Registrar (and Coordinator) to 149 control this process. Typically a Join Registrar is "inside" its 150 domain. For simplicity this document often refers to this as just 151 "Registrar". 153 MASA: The Manufacturer Authorized Signing Authority (MASA) service 154 that signs vouchers. In some bootstrapping protocols, the MASA 155 may have Internet presence and be integral to the bootstrapping 156 process, whereas in other protocols the MASA may be an offline 157 service that has no active role in the bootstrapping process. The 158 MAS concept is explained in more detail in 159 [I-D.ietf-anima-bootstrapping-keyinfra] 161 Pledge: The prospective device attempting to find and securely join 162 a domain. When shipped it only trusts authorized representatives 163 of the manufacturer. 165 Registrar See Join Registrar 167 TOFU: Trust on First Use. This is where a Pledge device makes no 168 security decisions but rather simply trusts the first domain 169 entity it is contacted by. Used similarly to [RFC7435]. This is 170 also known as the "resurrecting duckling" model. 172 Voucher: A signed statement from the MASA service that indicates to 173 a Pledge the cryptographic identity of the domain it should trust. 175 3. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in BCP 180 14 [RFC2119] [RFC8174] when, and only when, they appear in all 181 capitals, as shown here. 183 4. Survey of Voucher Types 185 A voucher is a cryptographically protected statement to the Pledge 186 device authorizing a zero-touch "imprint" on the Join Registrar of 187 the domain. The specific information a voucher provides is 188 influenced by the bootstrapping use case. 190 The voucher can impart the following information to the Join 191 Registrar and Pledge: 193 Assertion Basis: Indicates the method that protects the imprint 194 (this is distinct from the voucher signature that protects the 195 voucher itself). This might include manufacturer asserted 196 ownership verification, assured logging operations or reliance on 197 Pledge endpoint behavior such as secure root of trust of 198 measurement. The Join Registrar might use this information. Only 199 some methods are normatively defined in this document. Other 200 methods are left for future work. 202 Authentication of Join Registrar: Indicates how the Pledge can 203 authenticate the Join Registrar. This might include an indication 204 of the private PKIX (Public Key Infrastructure using X.509) trust 205 anchor used by the Registrar, or an indication of a public PKIX 206 trust anchor and additional CN-ID or DNS-ID information to 207 complete authentication. Symmetric key or other methods are left 208 for future work. 210 Anti-Replay Protections: Time or nonce based information to 211 constrain the voucher to time periods or bootstrap attempts. 213 A number of bootstrapping scenarios can be met using differing 214 combinations of this information. All scenarios address the primary 215 threat of a Man-in-The-Middle (MiTM) Registrar gaining control over 216 the Pledge device. The following combinations are "types" of 217 vouchers: 219 |Assertion |Registrar ID | Validity | 220 Voucher |Log-|Veri- |Trust |CN-ID or| RTC | Nonce | 221 Type | ged| fied |Anchor |DNS-ID | | | 222 ---------------------------------------------------------| 223 Audit | X | | X | | | X | 224 -------------|----|-------|-------|--------|-----|-------| 225 Nonceless | X | | X | | X | | 226 Audit | | | | | | | 227 -------------|----|-------|-------|--------|-----|-------| 228 Owner Audit | X | X | X | | X | X | 229 -------------|----|-------|-------|--------|-----|-------| 230 Owner ID | | X | X | X | X | | 231 -------------|----|-------|----------------|-----|-------| 232 Bearer | X | | wildcard | optional | 233 out-of-scope | | | | | 234 -------------|----|-------|----------------|-------------| 236 NOTE: All voucher types include a 'Pledge ID serial number' 237 (Not shown for space reasons) 239 Audit Voucher: An Audit Voucher is named after the logging assertion 240 mechanisms that the Registrar then "audits" to enforce local 241 policy. The Registrar mitigates a MiTM Registrar by auditing that 242 an unknown MiTM registrar does not appear in the log entries. 243 This does not directly prevent the MiTM but provides a response 244 mechanism that ensures the MiTM is unsuccessful. This advantage 245 is that actual ownership knowledge is not required on the MASA 246 service. 248 Nonceless Audit Voucher: An Audit Voucher without a validity period 249 statement. Fundamentally the same as an Audit Voucher except that 250 it can be issued in advance to support network partitions or to 251 provide a permanent voucher for remote deployments. 253 Ownership Audit Voucher: An Audit Voucher where the MASA service has 254 verified the Registrar as the authorized owner. The MASA service 255 mitigates a MiTM Registrar by refusing to generate Audit Vouchers 256 for unauthorized Registrars. The Registrar uses audit techniques 257 to supplement the MASA. This provides a ideal sharing of policy 258 decisions and enforcement between the vendor and the owner. 260 Ownership ID Voucher: An Ownership ID Voucher is named after 261 inclusion of the Pledge's CN-ID or DNS-ID within the voucher. The 262 MASA service mitigates a MiTM Registrar by identifying the 263 specific Registrar (via WebPKI) authorized to own the Pledge. 265 Bearer Voucher: A Bearer Voucher is named after the inclusion of a 266 Registrar ID wildcard. Because the Registrar identity is not 267 indicated this voucher type must be treated as a secret and 268 protected from exposure as any 'bearer' of the voucher can claim 269 the Pledge device. Publishing a nonceless bearer voucher 270 effectively turns the specified Pledge into a "TOFU" device with 271 minimal mitigation against MiTM Registrars. Bearer vouchers are 272 out-of-scope. 274 5. Voucher artifact 276 The voucher's primary purpose is to securely assign a pledge to an 277 owner. The voucher informs the pledge which entity it should 278 consider to be its owner. 280 This document defines a voucher that is a JSON encoded instance of 281 the YANG module defined in Section 5.3 that has been, by default, 282 CMS-signed. 284 This format is described here as a practical basis for some uses 285 (such as in NETCONF), but more to make it clear what vouchers look 286 like in practice. This description also serves to validate the YANG 287 model. 289 Future work is expected to define new mappings of the voucher to CBOR 290 (from JSON), and to change the signature container from CMS to JOSE 291 or COSE. XML or ASN.1 formats are also conceivable. 293 The method of signaling alternative signature methods is out-of-scope 294 for this document. Documents that leverage vouchers can provide this 295 signaling. The signaling could be in the form of a MIME Content- 296 Type, an HTTP Accept: header, or more mundane methods like use of a 297 filename extension when a voucher is transfered on a USB key. 299 5.1. Tree Diagram 301 The following tree diagram illustrates a high-level view of a voucher 302 document. The notation used in this diagram is described in 303 [I-D.ietf-netmod-yang-tree-diagrams]). Each node in the diagram is 304 fully described by the YANG module in Section 5.3. Please review the 305 YANG module for a detailed description of the voucher format. 307 module: ietf-voucher 309 yang-data voucher-artifact: 310 +---- voucher 311 +---- created-on yang:date-and-time 312 +---- expires-on? yang:date-and-time 313 +---- assertion enumeration 314 +---- serial-number string 315 +---- idevid-issuer? binary 316 +---- pinned-domain-cert binary 317 +---- domain-cert-revocation-checks? boolean 318 +---- nonce? binary 319 +---- last-renewal-date? yang:date-and-time 321 5.2. Examples 323 This section provides voucher examples for illustration purposes. 324 That these examples conform to the encoding rules defined in 325 [RFC7159]. 327 The following example illustrates an ephemeral voucher (uses a 328 nonce). The MASA generated this voucher using the 'logged' assertion 329 type, knowing that it would be suitable for the pledge making the 330 request. 332 { 333 "ietf-voucher:voucher": { 334 "created-on": "2016-10-07T19:31:42Z", 335 "assertion": "logged", 336 "serial-number": "JADA123456789", 337 "idevid-issuer": "base64encodedvalue==", 338 "pinned-domain-cert": "base64encodedvalue==", 339 "nonce": "base64encodedvalue==" 340 } 341 } 343 The following example illustrates a non-ephemeral voucher (no nonce). 344 While the voucher itself expires after two weeks, it presumably can 345 be renewed for up to a year later. The MASA generated this voucher 346 using the 'verified' assertion type, which should satisfy all 347 pledges. 349 { 350 "ietf-voucher:voucher": { 351 "created-on": "2016-10-07T19:31:42Z", 352 "expires-on": "2016-10-21T19:31:42Z", 353 "assertion": "verified", 354 "serial-number": "JADA123456789", 355 "idevid-issuer": "base64encodedvalue==", 356 "pinned-domain-cert": "base64encodedvalue==", 357 "domain-cert-revocation-checks": "true", 358 "last-renewal-date": "2017-10-07T19:31:42Z" 359 } 360 } 362 5.3. YANG Module 364 Following is a YANG [RFC7950] module formally describing the 365 voucher's JSON document structure. 367 file "ietf-voucher@2017-10-25.yang" 368 module ietf-voucher { 369 yang-version 1.1; 371 namespace 372 "urn:ietf:params:xml:ns:yang:ietf-voucher"; 373 prefix "vch"; 375 import ietf-yang-types { 376 prefix yang; 377 reference "RFC 6991: Common YANG Data Types"; 378 } 379 import ietf-restconf { 380 prefix rc; 381 description 382 "This import statement is only present to access 383 the yang-data extension defined in RFC 8040."; 384 reference "RFC 8040: RESTCONF Protocol"; 385 } 387 organization 388 "IETF ANIMA Working Group"; 390 contact 391 "WG Web: 392 WG List: 393 Author: Kent Watsen 394 395 Author: Max Pritikin 396 397 Author: Michael Richardson 398 399 Author: Toerless Eckert 400 "; 402 description 403 "This module defines the format for a voucher, which is produced by 404 a pledge's manufacturer or delegate (MASA) to securely assign a 405 pledge to an 'owner', so that the pledge may establish a secure 406 connection to the owner's network infrastructure. 408 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 409 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 410 the module text are to be interpreted as described in RFC 2119. 412 Copyright (c) 2017 IETF Trust and the persons identified as 413 authors of the code. All rights reserved. 415 Redistribution and use in source and binary forms, with or without 416 modification, is permitted pursuant to, and subject to the license 417 terms contained in, the Simplified BSD License set forth in Section 418 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 419 (http://trustee.ietf.org/license-info). 421 This version of this YANG module is part of RFC XXXX; see the RFC 422 itself for full legal notices."; 424 revision "2017-10-25" { 425 description 426 "Initial version"; 428 reference 429 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 430 } 432 // Top-level statement 433 rc:yang-data voucher-artifact { 434 uses voucher-artifact-grouping; 435 } 437 // Grouping defined for future augmentations 438 grouping voucher-artifact-grouping { 439 description 440 "Grouping to allow reuse/extensions in future work."; 442 container voucher { 443 description 444 "A voucher assigns a pledge to an owner (pinned-domain-cert)."; 446 leaf created-on { 447 type yang:date-and-time; 448 mandatory true; 449 description 450 "A value indicating the date this voucher was created. This 451 node is primarily for human consumption and auditing. Future 452 work MAY create verification requirements based on this 453 node."; 454 } 456 leaf expires-on { 457 type yang:date-and-time; 458 must "not(../nonce)"; 459 description 460 "A value indicating when this voucher expires. The node is 461 optional as not all pledges support expirations, such as 462 pledges lacking a reliable clock. 464 If this field exists, then the the pledges MUST ensure that 465 the expires-on time has not yet passed. A pledge without 466 an accurate clock cannot meet this requirement. 468 The expires-on value MUST NOT exceed the expiration date 469 of any of the listed 'pinned-domain-cert' certificates."; 471 } 473 leaf assertion { 474 type enumeration { 475 enum verified { 476 description 477 "Indicates that the ownership has been positively 478 verified by the MASA (e.g., through sales channel 479 integration)."; 480 } 481 enum logged { 482 description 483 "Indicates that this ownership assignment has been 484 logged into a database maintained by the MASA, after 485 first verifying that there has not been a previous 486 claim in the database for the same pledge (voucher 487 transparency)."; 488 } 489 enum proximity { 490 description 491 "Indicates that this assertion is made based on 492 the proximity of the signer as determined by 493 local network information. This is useful for 494 a pledge device to indicate it 'sees' a specific 495 registrar on a TLS connection, or for a registrar 496 to indicate it 'sees' a pledge."; 497 } 498 } 499 mandatory true; 500 description 501 "The assertion is a statement from the MASA regarding how 502 the owner was verified. This statement enables pledges 503 to support more detailed policy checks. Pledges MUST 504 ensure that the assertion provided is acceptable before 505 processing the voucher."; 506 } 508 leaf serial-number { 509 type string; 510 mandatory true; 511 description 512 "The serial number of the hardware. When processing a 513 voucher, a pledge MUST ensure that its serial number 514 matches this value. If no match occurs, then the 515 pledge MUST NOT process this voucher."; 516 } 518 leaf idevid-issuer { 519 type binary; 520 description 521 "The RFC5280 4.2.1.1 Authority Key Identifier OCTET STRING 522 from the pledge's IDevID certificate. Optional since some 523 serial-numbers are already unique within the scope of a 524 MASA. Inclusion of the statistically unique key identifier 525 ensures statistically unique identification of the hardware. 526 When processing a voucher, a pledge MUST ensure that its 527 IDevID Authority Key Identifier matches this value. If no 528 match occurs, then the pledge MUST NOT process this voucher. 530 When issuing a voucher, the MASA MUST ensure that this field 531 is populated for serial numbers that are not otherwise unique 532 within the scope of the MASA."; 533 } 535 leaf pinned-domain-cert { 536 type binary; 537 mandatory true; 538 description 539 "An X.509 v3 certificate structure as specified by RFC 5280, 540 Section 4 encoded using the ASN.1 distinguished encoding 541 rules (DER), as specified in ITU-T X.690. 543 This certificate is used by a pledge to trust a public key 544 infrastructure, in order to verify a domain certificate 545 supplied to the pledge separately by the bootstrapping 546 protocol. The domain certificate MUST have this certificate 547 somewhere in its chain of certificates. This certificate 548 MAY be an end-entity certificate, including a self-signed 549 entity."; 550 reference 551 "RFC 5280: 552 Internet X.509 Public Key Infrastructure Certificate 553 and Certificate Revocation List (CRL) Profile. 554 ITU-T X.690: 555 Information technology - ASN.1 encoding rules: 556 Specification of Basic Encoding Rules (BER), 557 Canonical Encoding Rules (CER) and Distinguished 558 Encoding Rules (DER)."; 559 } 561 leaf domain-cert-revocation-checks { 562 type boolean; 563 must "../expires-on"; 564 description 565 "A processing instruction to the pledge that it MUST verify 566 the revocation status for the domain certificate. This 567 instruction is only available for vouchers that expire. If 568 this field is not set, then normal PKIX behaviour applies 569 to validation of the domain certificate."; 570 } 571 leaf nonce { 572 type binary { 573 length "8..32"; 574 } 575 must "not(../expires-on)"; 576 description 577 "A value that can be used by a pledge in some bootstrapping 578 protocols to enable anti-replay protection. This node is 579 optional because it is not used by all bootstrapping 580 protocols. 582 When present, the pledge MUST compare the provided nonce 583 value with another value that the pledge randomly generated 584 and sent to a bootstrap server in an earlier bootstrapping 585 message. If the values do not match, then the pledge MUST 586 NOT process this voucher."; 587 } 589 leaf last-renewal-date { 590 type yang:date-and-time; 591 must "../expires-on"; 592 description 593 "The date that the MASA projects to be the last date it 594 will renew a voucher on. This field is merely informative, it 595 is not processed by pledges. 597 Circumstances may occur after a voucher is generated that 598 may alter a voucher's validity period. For instance, a 599 vendor may associate validity periods with support contracts, 600 which may be terminated or extended over time."; 601 } 603 } // end voucher 604 } // end voucher-grouping 605 } 607 609 5.4. CMS format voucher artifact 611 The IETF evolution of PKCS#7 is CMS [RFC5652]. A CMS signed voucher, 612 the default type, contains a ContentInfo structure with the voucher 613 content. An eContentType of TBD1 indicates the content is a JSON- 614 encoded voucher. 616 The signing structure is a CMS SignedData structure, as specified by 617 Section 5.1 of [RFC5652], encoded using ASN.1 distinguished encoding 618 rules (DER), as specified in ITU-T X.690. 620 The CMS structure MUST contain a 'signerInfo' structure, as described 621 in Section 5.1 of [RFC5652], containing the signature generated over 622 the content using a private key trusted by the recipient. Normally 623 the recipient is the pledge and the signer is the MASA. A possible 624 other use could be as a "signed voucher request" format originating 625 from pledge or registrar toward the MASA. Within this document the 626 signer is assumed to be the MASA. 628 Note that Section 5.1 of [RFC5652] includes a discussion about how to 629 validate a CMS object which is really a PKCS7 object (cmsVersion=1). 630 Intermediate systems (such the BRSKI Registrar) which might need to 631 evaluate the voucher in flight MUST be prepared for such an older 632 format. No signaling is necessary, as the Manufacturer knows the 633 capabilities of the pledge, and will use an appropriate format 634 voucher for each pledge. 636 The CMS structure SHOULD also contain all the certificates leading up 637 to and including the signer's trust anchor certificate known to the 638 recipient. The inclusion of the trust anchor is unusual in many 639 applications, but without it third parties can not accurately audit 640 the transaction. 642 The CMS structure MAY also contain revocation objects for any 643 intermediate certificate authorities (CAs) between the voucher-issuer 644 and the trust anchor known to the recipient. However, the use of 645 CRLs and other validity mechanisms is discouraged, as the pledge is 646 unlikely to be able to perform online checks, and is unlikely to have 647 a trusted clock source. As described below, the use of short-lived 648 vouchers and/or pledge provided nonce provides a freshness guarantee. 650 6. Design Considerations 652 6.1. Renewals instead of Revocations 654 The lifetimes of vouchers may vary. In some bootstrapping protocols, 655 the vouchers may be created and consumed immediately whereas, in 656 other bootstrapping solutions, there may be a significant time delay 657 between when a voucher is created and when it is consumed. In cases 658 when there is a time delay, there is a need for the pledge to ensure 659 that the assertions made when the voucher was created are still 660 valid. 662 A revocation artifact is generally used to verify the continued 663 validity of an assertion such as a PKIX certificate, web token, or a 664 "voucher". With this approach, a potentially long-lived assertion is 665 paired with a reasonably fresh revocation status check to ensure that 666 the assertion is still valid. However, this approach increases 667 solution complexity, as it introduces the need for additional 668 protocols and code paths to distribute and process the revocations. 670 Addressing the short-comings of revocations, this document recommends 671 instead the use of lightweight renewals of short-lived non-revocable 672 vouchers. That is, rather than issue a long-lived voucher, where the 673 'expires-on' leaf is set to some distant date, the expectation is for 674 the MASA to instead issue a short-lived voucher, where the 'expires- 675 on' leaf is set to a relatively near date, along with a promise 676 (reflected in the 'last-renewal-date' field) to re-issue the voucher 677 again when needed. Importantly, while issuing the initial voucher 678 may incur heavyweight verification checks (are you who you say you 679 are? does the pledge actually belong to you?), re-issuing the 680 voucher should be a lightweight process, as it ostensibly only 681 updates the voucher's validity period. With this approach, there is 682 only the one artifact, and only one code path is needed to process 683 it, without any possibility for a pledge to choose to skip the 684 revocation status check because, for instance, the OCSP Responder is 685 not reachable. 687 While this document recommends issuing short-lived vouchers, the 688 voucher artifact does not restrict the ability to create a long-lived 689 vouchers, if required, however no revocation method is described. 691 Note that a voucher may be signed by a chain of intermediate CAs 692 leading up to the trust anchor certificate known by the pledge. Even 693 though the voucher itself is not revocable, it may still be revoked, 694 per se, if one of the intermediate CA certificates is revoked. 696 6.2. Voucher Per Pledge 698 The solution described herein originally enabled a single voucher to 699 apply to many pledges, using lists of regular expressions to 700 represent ranges of serial numbers. However, it was determined that 701 blocking the renewal of a voucher that applied to many devices would 702 be excessive when only the ownership for a single pledge needed to be 703 blocked. Thus, the voucher format now only supports a single serial- 704 number to be listed. 706 7. Security Considerations 708 7.1. Clock Sensitivity 710 An attacker could use an expired voucher to gain control over a 711 device that has no understand of time. 713 To defend against this there are three things: devices are required 714 to verify that the expires-on field has not yet passed. Devices 715 without access to time can use nonces to get ephemeral vouchers. 716 Thirdly, vouchers without expiration times may be used, which will 717 appear in the audit log, informing the security decision. 719 This document defines a voucher format that contains time values for 720 expirations, which require an accurate clock in order to be processed 721 correctly. Vendors planning on issuing vouchers with expiration 722 values must ensure devices have an accurate clock when shipped from 723 manufacturing facilities, and take steps to prevent clock tampering. 724 If it is not possible to ensure clock accuracy then vouchers with 725 expirations should not be issued. 727 7.2. Protect Voucher PKI in HSM 729 A voucher is signed by a CA, that may itself be signed by a chain of 730 CAs leading to a trust anchor known to a pledge. Revocation checking 731 of the intermediate certificates may be difficult in some scenarios. 732 The voucher format supports the existing PKIX revocation information 733 distribution within the limits of the current PKI technology (a PKCS7 734 structure can contain revocation objects as well), but pledges MAY 735 accept vouchers without checking X.509 certificate revocation (when 736 'domain-cert-revocation-checks' is false). Without revocation 737 checking, a compromised MASA keychain could be used to issue vouchers 738 ad infinitum without recourse. For this reason, MASA implementations 739 wanting to support such deployments SHOULD ensure that all the CA 740 private keys used for signing the vouchers are protected by hardware 741 security modules (HSMs). 743 7.3. Test Domain Certificate Validity when Signing 745 If a domain certificate is compromised, then any outstanding vouchers 746 for that domain could be used by the attacker. The domain 747 administrator is clearly expected to initiate revocation of any 748 domain identity certificates (as is normal in PKI solutions). 750 Similarly they are expected to contact the MASA to indicate that an 751 outstanding (presumably short lifetime) voucher should be blocked 752 from automated renewal. Protocols for voucher distribution are 753 RECOMMENDED to check for revocation of any domain identity 754 certificates before automated renewal of vouchers. 756 8. IANA Considerations 758 8.1. The IETF XML Registry 760 This document registers a URIs in the IETF XML registry [RFC3688]. 761 Following the format in [RFC3688], the following registration is 762 requested: 764 URI: urn:ietf:params:xml:ns:yang:ietf-voucher 765 Registrant Contact: The ANIMA WG of the IETF. 766 XML: N/A, the requested URI is an XML namespace. 768 8.2. The YANG Module Names Registry 770 This document registers a YANG module in the YANG Module Names 771 registry [RFC6020]. Following the format defined in [RFC6020], the 772 the following registration is requested: 774 name: ietf-voucher 775 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher 776 prefix: vch 777 reference: RFC XXXX 779 8.3. The SMI Security for S/MIME CMS Content Type Registry 781 This document registers an OID in the "SMI Security for S/MIME CMS 782 Content Type" registry (1.2.840.113549.1.9.16.1), with the value: 784 Decimal Description References 785 ------- -------------------------------------- ---------- 786 TBD1 id-ct-animaJSONVoucher [ThisRFC] 788 9. References 790 9.1. Normative References 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, March 1997. 795 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 796 RFC 5652, September 2009. 798 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 799 the Network Configuration Protocol (NETCONF)", RFC 6020, 800 DOI 10.17487/RFC6020, October 2010, . 803 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 804 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 805 2014, . 807 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 808 RFC 7950, DOI 10.17487/RFC7950, August 2016, 809 . 811 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 812 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 813 May 2017, . 815 9.2. Informative References 817 [I-D.ietf-6tisch-dtsecurity-secure-join] 818 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 819 6tisch-dtsecurity-secure-join-01 (work in progress), 820 February 2017. 822 [I-D.ietf-anima-bootstrapping-keyinfra] 823 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 824 S., and K. Watsen, "Bootstrapping Remote Secure Key 825 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 826 keyinfra-08 (work in progress), October 2017. 828 [I-D.ietf-netconf-zerotouch] 829 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 830 Provisioning for NETCONF or RESTCONF based Management", 831 draft-ietf-netconf-zerotouch-19 (work in progress), 832 October 2017. 834 [I-D.ietf-netmod-yang-tree-diagrams] 835 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 836 ietf-netmod-yang-tree-diagrams-02 (work in progress), 837 October 2017. 839 [imprinting] 840 Wikipedia, , "Wikipedia article: Imprinting", July 2015, 841 . 843 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 844 January 2004. 846 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 847 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 848 December 2014, . 850 [Stajano99theresurrecting] 851 Stajano, F. and R. Anderson, "The resurrecting duckling: 852 security issues for ad-hoc wireless networks", 1999, 853 . 856 Appendix A. Acknowledgements 858 The authors would like to thank for following for lively discussions 859 on list and in the halls (ordered by last name): William Atwood, 860 Toerless Eckert, Sheng Jiang. 862 Russ Housley provided the upgrade from PKCS7 to CMS(RFC5652), along 863 with the detailed CMS structure diagram. 865 Authors' Addresses 867 Kent Watsen 868 Juniper Networks 870 EMail: kwatsen@juniper.net 872 Michael C. Richardson 873 Sandelman Software 875 EMail: mcr+ietf@sandelman.ca 876 URI: http://www.sandelman.ca/ 878 Max Pritikin 879 Cisco Systems 881 EMail: pritikin@cisco.com 883 Toerless Eckert 884 Futurewei Technologies Inc. 885 2330 Central Expy 886 Santa Clara 95050 887 USA 889 EMail: tte+ietf@cs.fau.de