idnits 2.17.1 draft-ietf-anima-voucher-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 7, 2017) is 2508 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) ** Downref: Normative reference to an Informational RFC: RFC 2315 -- No information found for draft-bjorklund-netmod-yang-tree-diagrams - is the name correct? == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-06 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-13 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: December 9, 2017 Sandelman Software 6 M. Pritikin 7 Cisco Systems 8 T. Eckert 9 Huawei 10 June 7, 2017 12 Voucher Profile for Bootstrapping Protocols 13 draft-ietf-anima-voucher-03 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 The voucher artifact is a YANG-defined JSON document that has been 22 signed using a PKCS#7 structure. The voucher artifact is generated 23 by the pledge's manufacture or delegate (i.e. the MASA). 25 This document only defines the voucher artifact, leaving it to other 26 documents to describe specialized protocols for accessing it. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 9, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 65 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 66 5. Voucher . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 7 68 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 8 70 6. Design Considerations . . . . . . . . . . . . . . . . . . . . 13 71 6.1. Renewals instead of Revocations . . . . . . . . . . . . . 13 72 6.2. Voucher Per Pledge . . . . . . . . . . . . . . . . . . . 14 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 7.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 14 75 7.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 14 76 7.3. Test Domain Certificate Validity when Signing . . . . . . 15 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 15 79 8.2. The YANG Module Names Registry . . . . . . . . . . . . . 15 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 9.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 This document defines a strategy to securely assign a pledge to an 89 owner, using an artifact signed, directly or indirectly, by the 90 pledge's manufacturer or delegate (i.e. the MASA). This artifact is 91 known as the voucher. 93 The voucher artifact is a JSON document, conforming to a data model 94 described by YANG [RFC7950], that has been signed using a PKCS#7 95 structure. 97 A voucher may be useful in several contexts, but the driving 98 motivation herein is to support secure bootstrapping mechanisms. 99 Assigning ownership is important to bootstrapping mechanisms so that 100 the pledge can authenticate the network that's trying to take control 101 of it. 103 The lifetimes of vouchers may vary. In some bootstrapping protocols 104 the vouchers may be ephemeral, whereas in others the vouchers may be 105 potentially long-lived. In order to support the second category of 106 vouchers, this document recommends using short-life vouchers with 107 programatic renewal, enabling the MASA to communicate the ongoing 108 validity of vouchers. 110 This document only defines the voucher artifact, leaving it to other 111 documents to describe specialized protocols for accessing it. Some 112 bootstrapping protocols using the voucher artifact defined in this 113 draft include: [I-D.ietf-netconf-zerotouch], 114 [I-D.ietf-6tisch-dtsecurity-secure-join], and 115 [I-D.ietf-anima-bootstrapping-keyinfra]). 117 2. Terminology 119 Imprint: The process where a device obtains the cryptographic key 120 material to identify and trust future interactions with a network. 121 This term is taken from Konrad Lorenz's work in biology with new 122 ducklings: "during a critical period, the duckling would assume 123 that anything that looks like a mother duck is in fact their 124 mother." An equivalent for a device is to obtain the fingerprint 125 of the network's root certification authority certificate. A 126 device that imprints on an attacker suffers a similar fate to a 127 duckling that imprints on a hungry wolf. Securely imprinting is a 128 primary focus of this document.[imprinting]. The analogy to 129 Lorenz's work was first noted in [Stajano99theresurrecting]. 131 Domain: The set of entities or infrastructure under common 132 administrative control. The goal of the bootstrapping protocol is 133 to enable a Pledge to discover and join a Domain. 135 Join Registrar (and Coordinator): A representative of the domain 136 that is configured, perhaps autonomically, to decide whether a new 137 device is allowed to join the domain. The administrator of the 138 domain interfaces with a Join Registrar (and Coordinator) to 139 control this process. i Typically a Join Registrar is "inside" its 140 domain. For simplicity this document often refers to this as just 141 "Registrar". 143 MASA: The Manufacturer Authorized Signing Authority (MASA) service 144 that signs vouchers. In some bootstrapping protocols, the MASA 145 may have Internet presence and be integral to the bootstrapping 146 process, whereas in other protocols the MASA may be an offline 147 service that has no active role in the bootstrapping process. 149 Pledge: The prospective device attempting to find and securely join 150 a domain. When shipped it only trusts authorized representatives 151 of the manufacturer. 153 Registrar See Join Registrar 155 TOFU: Trust on First Use. This is where a Pledge device makes no 156 security decisions but rather simply trusts the first Domain 157 entity it is contacted by. Used similarly to [RFC7435]. This is 158 also known as the "resurrecting duckling" model. 160 Voucher: A signed statement from the MASA service that indicates to 161 a Pledge the cryptographic identity of the Domain it should trust. 163 3. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the 167 sections below are to be interpreted as described in RFC 2119 168 [RFC2119]. 170 4. Survey of Voucher Types 172 A voucher is a cryptographically protected statement to the Pledge 173 device authorizing a zero-touch "imprint" on the Join Registrar of 174 the domain. The specific information a voucher provides is 175 influenced by the bootstrapping use case. 177 The voucher can impart the following information to the Join 178 Registrar and Pledge: 180 Assertion Basis: Indicates the method that protects the imprint 181 (this is distinct from the voucher signature that protects the 182 voucher itself). This might include manufacturer asserted 183 ownership verification, assured logging operations or reliance on 184 Pledge endpoint behavior such as secure root of trust of 185 measurement. The Join Registrar might use this information. Only 186 some methods are normatively defined in this document. Other 187 methods are left for future work. 189 Authentication of Join Registrar: Indicates how the Pledge can 190 authenticate the Join Registrar. This might include an indication 191 of the private PKIX trust anchor used by the Registrar, or an 192 indication of a public PKIX trust anchor and additional CN-ID or 193 DNS-ID information to complete authentication. Symmetric key or 194 other methods are left for future work. 196 Anti-Replay Protections: Time or nonce based information to 197 constrain the voucher to time periods or bootstrap attempts. 199 A number of bootstrapping scenarios can be met using differing 200 combinations of this information. All scenarios address the primary 201 threat of a Man-in-The-Middle Registrar gaining control over the 202 Pledge device. The following combinations are "types" of vouchers: 204 |Assertion |Registrar ID | Validity | 205 Voucher |Log-|Veri- |Trust |CN-ID or| RTC | Nonce | 206 Name | ged| fied |Anchor |DNS-ID | | | 207 ---------------------------------------------------------| 208 Audit | X | | X | | | X | 209 -------------|----|-------|-------|--------|-----|-------| 210 Nonceless | X | | X | | X | | 211 Audit | | | | | | | 212 -------------|----|-------|-------|--------|-----|-------| 213 Owner Audit | X | X | X | | X | X | 214 -------------|----|-------|-------|--------|-----|-------| 215 Owner ID | | X | X | X | X | | 216 -------------|----|-------|----------------|-----|-------| 217 Bearer | X | | wildcard | optional | 218 out-of-scope | | | | | 219 -------------|----|-------|----------------|-------------| 221 NOTE: All voucher types include a 'Pledge ID serial number' 222 (Not shown for space reasons) 224 Audit Voucher: An Audit Voucher is named after the logging assertion 225 mechanisms that the Registrar then "audits" to enforce local 226 policy. The Registrar mitigates a MiTM Registrar by auditing that 227 an unknown MiTM registrar does not appear in the log entries. 228 This does not direct prevent the MiTM but provides a response 229 mechanism that ensures the MiTM is unsuccessful. This advantage 230 is that actual ownership knowledge is not required on the MASA 231 service. 233 Nonceless Audit Voucher: An Audit Voucher without a validity period 234 statement. Fundamentally the same as an Audit Voucher except that 235 it can be issued in advance to support network partitions or to 236 provide a permanent voucher for remote deployments. 238 Ownership Audit Voucher: An Audit Voucher where the MASA service has 239 verified the Registrar as the authorized owner. The MASA service 240 mitigates a MiTM Registrar by refusing to generate Audit Voucher's 241 for unauthorized Registrars. The Registrar uses audit techniques 242 to supplement the MASA. This provides an ideal sharing of policy 243 decisions and enforcement between the vendor and the owner. 245 Ownership ID Voucher: An Ownership ID Voucher is named after 246 inclusion of the Pledge's CN-ID or DNS-ID within the voucher. The 247 MASA service mitigates a MiTM Registrar by identifying the 248 specific Registrar (via WebPKI) authorized to own the Pledge. 250 Bearer Voucher: A Bearer Voucher is named after the inclusion of a 251 Registrar ID wildcard. Because the Registrar identity is not 252 indicated this voucher type must be treated as a secret and 253 protected from exposure as any 'bearer' of the voucher can claim 254 the Pledge device. Publishing a nonceless bearer voucher 255 effectively turns the specified Pledge into a "TOFU" device with 256 minimal mitigation against MiTM Registrars. Bearer vouchers are 257 out-of-scope. 259 5. Voucher 261 The voucher's purpose is to securely assign a pledge to an owner. 262 The voucher informs the pledge which entity it should consider to be 263 its owner. 265 The voucher is signed a PKCS#7 SignedData structure, as specified by 266 Section 9.1 of [RFC2315], encoded using ASN.1 distinguished encoding 267 rules (DER), as specified in ITU-T X.690. 269 The PKCS#7 structure MUST contain JSON-encoded content conforming to 270 the YANG module specified in Section 5.3. 272 The PKCS#7 structure MUST also contain a 'signerInfo' structure, as 273 described in Section 9.1 of [RFC2315], containing the signature 274 generated over the content using the MASA's private key. 276 The PKCS#7 structure SHOULD also contain all of the certificates 277 leading up to and including the MASA's trust anchor certificate known 278 to the pledges. 280 The PKCS#7 structure MAY also contain revocation objects for any 281 intermediate CAs between the voucher-issuer and the trust anchor 282 known to the pledge. 284 5.1. Tree Diagram 286 The following tree diagram [I-D.bjorklund-netmod-yang-tree-diagrams] 287 illustrates a high-level view of a voucher document. Each field in 288 the voucher is fully described by the YANG module provided in 289 Section 5.3. Please review this YANG module for a detailed 290 description of the voucher format. 292 module: ietf-voucher 293 +--ro voucher 294 +--ro created-on yang:date-and-time 295 +--ro expires-on? yang:date-and-time 296 +--ro assertion enumeration 297 +--ro serial-number string 298 +--ro idevid-issuer? binary 299 +--ro pinned-domain-cert* binary 300 +--ro domain-cert-revocation-checks? boolean 301 +--ro nonce? binary 302 +--ro last-renewal-date? yang:date-and-time 304 5.2. Examples 306 This section provides a couple Voucher examples for illustration 307 purposes. 309 The following example illustrates an ephemeral voucher (uses a nonce) 310 encoded in JSON. As is expected with a dynamically-generated 311 voucher, only a single pledge (device-identifier) is specified. The 312 MASA generated this voucher using the 'logged' assertion type, 313 knowing that it would be suitable for the pledge making the request. 315 { 316 "ietf-voucher:voucher": { 317 "created-on": "2016-10-07T19:31:42Z", 318 "assertion": "logged", 319 "serial-number": "JADA123456789", 320 "serial-number-issuer": "some binary identifier", 321 "domain-cert-trusted-ca": "base64-encoded X.509 DER", 322 "domain-cert-identifier": { 323 "subject": "base64-encoded Subject DER" 324 }, 325 "nonce": "base64-encoded octet string" 326 } 327 } 329 The following illustrates a long-lived voucher (no nonce), encoded in 330 XML. This particular voucher applies to more than one pledge 331 (unique-id), which might relate to, for instance, they were all 332 issued as part of the same purchase order. This voucher includes 333 both a trust anchor certificate (trusted-ca-certificate) as well as 334 some additional information (cn-id and dns-id) that can be used to 335 identify a specific domain certificate issued, perhaps indirectly, by 336 the trust anchor CA. 338 { 339 "ietf-voucher:voucher": { 340 "created-on": "2016-10-07T19:31:42Z", 341 "expires-on": "2016-10-21T19:31:42Z", 342 "assertion": "verified", 343 "serial-number": "JADA123456789", 344 "serial-number-issuer": "some binary identifier", 345 "domain-cert-trusted-ca": "base64-encoded X.509 DER", 346 "domain-cert-identifier": { 347 "subject": "base64-encoded Subject DER" 348 }, 349 "assert-revocations-on-PKIX-certs": "false", 350 "last-renewal-date": "2017-10-07T19:31:42Z" 351 } 352 } 354 5.3. YANG Module 356 file "ietf-voucher@2017-06-07.yang" 358 module ietf-voucher { 359 yang-version 1.1; 361 namespace 362 "urn:ietf:params:xml:ns:yang:ietf-voucher"; 363 prefix "vch"; 365 import ietf-yang-types { 366 prefix yang; 367 reference "RFC 6991: Common YANG Data Types"; 368 } 370 import ietf-restconf { 371 prefix rc; 372 description 373 "This import statement is only present to access 374 the yang-data extension defined in RFC 8040."; 375 reference "RFC 8040: RESTCONF Protocol"; 376 } 378 organization 379 "IETF ANIMA Working Group"; 381 contact 382 "WG Web: 383 WG List: 384 Author: Kent Watsen 385 386 Author: Max Pritikin 387 388 Author: Michael Richardson 389 "; 391 description 392 "This module defines the format for a voucher, which is produced by 393 a pledge's manufacturer or delegate (MASA) to securely assign one 394 or more pledges to an 'owner', so that the pledges may establish a 395 secure connection to the owner's network infrastructure. 397 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 398 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 399 the module text are to be interpreted as described in RFC 2119."; 401 revision "2017-06-07" { 402 description 403 "Initial version"; 404 reference 405 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 406 } 408 rc:yang-data voucher-artifact { 409 uses voucher-grouping; 410 } 412 grouping voucher-grouping { 413 description 414 "Grouping only exists for pyang tree output..."; 416 container voucher { 417 config false; 418 description 419 "A voucher that can be used to assign one or more 420 pledges to an owner."; 422 leaf created-on { 423 type yang:date-and-time; 424 mandatory true; 425 description 426 "A value indicating the date this voucher was created. This 427 node is optional because its primary purpose is for human 428 consumption. However, when present, pledges that have 429 reliable clocks SHOULD ensure that this created-on value 430 is not greater than the current time."; 431 } 433 leaf expires-on { 434 type yang:date-and-time; 435 must "not(../nonce)"; 436 description 437 "A value indicating when this voucher expires. The node is 438 optional as not all pledges support expirations, such as 439 pledges lacking a reliable clock. 441 If this field exists, then the the pledges MUST ensure that 442 the expires-on time has not yet passed. A pledge without 443 an accurate clock cannot meet this requirement. 445 The expires-on value MUST NOT exceed the expiration date 446 of any of the listed 'pinned-domain-cert' certificates."; 448 } 450 leaf assertion { 451 type enumeration { 452 enum verified { 453 description 454 "Indicates that the ownership has been positively 455 verified by the MASA (e.g., through sales channel 456 integration)."; 457 } 458 enum logged { 459 description 460 "Indicates that this ownership assignment has been 461 logged into a database maintained by the MASA, after 462 first verifying that there has not been a previous 463 claim in the database for the same pledge (voucher 464 transparency)."; 465 } 466 } 467 mandatory true; 468 description 469 "The assertion is a statement from the MASA regarding how 470 the owner was verified. This statement enables pledges 471 to support more detailed policy checks. Pledges MUST 472 ensure that the assertion provided is acceptable before 473 processing the voucher."; 474 } 475 leaf serial-number { 476 type string; 477 mandatory true; 478 description 479 "The serial number of the hardware. When processing a 480 voucher, a pledge MUST ensure that its serial number 481 matches this value. If no match occurs, then the 482 pledge MUST NOT process this voucher."; 483 } 485 leaf idevid-issuer { 486 type binary; 487 description 488 "The RFC5280 4.2.1.1 Authority Key Identifier OCTET STRING 489 from the pledge's IDevID certificate. Optional since some 490 serial-numbers are already unique within the scope of a 491 MASA. Inclusion of the statistically unique key identifier 492 ensures statistically unique identification of the hardware. 493 When processing a voucher, a pledge MUST ensure that its 494 IDevID Authority Key Identifier matches this value. If no 495 match occurs, then the pledge MUST NOT process this voucher. 497 When issuing a voucher, the MASA MUST ensure that this field 498 is populated for serial numbers that are not otherwise unique 499 within the scope of the MASA."; 500 } 502 leaf-list pinned-domain-cert { 503 type binary; 504 min-elements 1; 505 description 506 "An X.509 v3 certificate structure as specified by RFC 5280, 507 Section 4 encoded using the ASN.1 distinguished encoding 508 rules (DER), as specified in ITU-T X.690. 510 This certificate is used by a pledge to trust a public key 511 infrastructure, in order to verify a domain certificate 512 supplied to the pledge separately by the bootstrapping 513 protocol. The domain certificate MUST have this certificate 514 somewhere in its chain of certificates. This certificate 515 MAY be an end-entity certificate, including a self-signed 516 entity."; 517 reference 518 "RFC 5280: 519 Internet X.509 Public Key Infrastructure Certificate 520 and Certificate Revocation List (CRL) Profile. 521 ITU-T X.690: 522 Information technology - ASN.1 encoding rules: 524 Specification of Basic Encoding Rules (BER), 525 Canonical Encoding Rules (CER) and Distinguished 526 Encoding Rules (DER)."; 527 } 529 leaf domain-cert-revocation-checks { 530 type boolean; 531 must "../expires-on"; 532 description 533 "A processing instruction to the pledge that it MUST verify 534 the revocation status for the domain certificate. This 535 instruction is only available for vouchers that expire. If 536 this field is not set, then normal PKIX behaviour applies 537 to validation of the domain certificate."; 538 } 540 leaf nonce { 541 type binary { 542 length "8..32"; 543 } 544 must "not(../expires-on)"; 545 description 546 "A value that can be used by a pledge in some bootstrapping 547 protocols to enable anti-replay protection. This node is 548 optional because it is not used by all bootstrapping 549 protocols. 551 When present, the pledge MUST compare the provided nonce 552 value with another value that the pledge randomly generated 553 and sent to a bootstrap server in an earlier bootstrapping 554 message. If the values do not match, then the pledge MUST 555 NOT process this voucher."; 556 } 558 leaf last-renewal-date { 559 type yang:date-and-time; 560 must "../expires-on"; 561 description 562 "The date that the MASA projects to be the last date it 563 will renew a voucher on. This field is merely informative, it 564 is not processed by pledges. 566 Circumstances may occur after a voucher is generated that 567 may alter a voucher's validity period. For instance, a 568 vendor may associate validity periods with support contracts, 569 which may be terminated or extended over time."; 570 } 572 } // end voucher 573 } // end voucher-grouping 574 } 576 578 6. Design Considerations 580 6.1. Renewals instead of Revocations 582 The lifetimes of vouchers may vary. In some bootstrapping protocols, 583 the vouchers may be created and consumed immediately whereas, in 584 other bootstrapping solutions, there may be a significant delay 585 between when a voucher is created and when it is consumed. In cases 586 when there is a delay, there is a need for the pledge to ensure that 587 the assertions made when the voucher was created are still valid when 588 it is consumed. 590 A revocation artifact is generally used to verify the continued 591 validity of an assertion such as a PKIX certificate, web token, or a 592 "voucher". With this approach, a potentially long-lived assertion is 593 paired with a reasonably fresh revocation status check to ensure that 594 the assertion is still valid. However, this approach increases 595 solution complexity, as it introduces the need for additional 596 protocols and code paths to distribute and process the revocations. 598 Addressing the short-comings of revocations, this document recommends 599 instead the use of lightweight renewals of short-lived non-revocable 600 vouchers. That is, rather than issue a long-lived voucher, the 601 expectation is for the MASA to instead issue a short-lived voucher 602 along with a promise (reflected in the 'last-renewal-date' field) to 603 re-issue the voucher again when needed. Importantly, while issuing 604 the initial voucher may incur heavyweight verification checks (are 605 you who you say you are? does the pledge actually belong to you?), 606 re-issuing the voucher should be a lightweight process, as it 607 ostensibly only updates the voucher's validatity period. With this 608 approach, there is only the one artifact, and only one code path is 609 needed to process it, without any possibility for a pledge to choose 610 to skip the revocation status check because, for instance, the OCSP 611 Responder is not reachable. 613 While this document recommends issuing short-lived vouchers, the 614 voucher artifact does not restrict the ability to create a long-lived 615 vouchers, if required, however no revocation method is described. 617 Note that a voucher may be signed by a chain of intermediate CAs 618 leading up to the trust anchor certificate known by the pledge. Even 619 though the voucher itself is not revocable, it may still be revoked, 620 per se, if one of the intermediate CA certificates is revoked. 622 6.2. Voucher Per Pledge 624 The solution described herein originally enabled a single voucher to 625 apply to many pledges, using lists of regular expressions to 626 represent ranges of serial numbers. However, it was determined that 627 blocking the renewal of a voucher that applied to many devices would 628 be excessive when only the ownership for a single pledge needed to be 629 blocked. Thus, the voucher format now only supports a single serial- 630 number to be listed. 632 7. Security Considerations 634 7.1. Clock Sensitivity 636 An attacker could use an expired voucher to gain control over a 637 device that has no understand of time. 639 To defend against this there are three things: devices are required 640 to verify that the expires-on field has not yet passed. Devices 641 without access to time can use nonces to get ephermal vouchers. 642 Thirdly, vouchers without expiration times may be used, which will 643 appear in the audit log, informing the security decision. 645 This document defines artifacts containing time values for voucher 646 expirations, which require an accurate clock in order to be processed 647 correctly. Vendors planning on issuing vouchers with expiration 648 values must ensure devices have an accurate clock when shipped from 649 manufacturing facilities, and take steps to prevent clock tampering. 650 If it is not possible to ensure clock accuracy then vouchers with 651 expirations should not be issued. 653 7.2. Protect Voucher PKI in HSM 655 A voucher is signed by a CA, that may itself be signed by a chain of 656 CAs leading to a trust anchor known to a pledge. Revocation checking 657 of the intermediate certificates may be difficult in some scenarios. 658 The voucher format supports the existing PKIX revocation information 659 distribution within the limits of the current PKI technology (a PKCS7 660 structure can contain revocation objects as well), but pledges MAY 661 accept vouchers without checking X.509 certificate revocation (when 662 'domain-cert-revocation-checks' is false). Without revocation 663 checking, a compromized MASA keychain could be used to issue vouchers 664 ad infinitum without recourse. For this reason, MASA implementations 665 wanting to support such deployments SHOULD ensure that all the CA 666 private keys used for signing the vouchers are protected by hardware 667 security modules (HSMs). 669 7.3. Test Domain Certificate Validity when Signing 671 If a domain certificate is compromised, then any outstanding vouchers 672 for that domain could be used by the attacker. The domain 673 administrator is clearly expected to initiate revocation of any 674 domain identity certificates (as is normal in PKI solutions). 676 Similarly they are expected to contact the MASA to indicate that an 677 outstanding (presumably short lifetime) voucher should be blocked 678 from automated renewal. Protocols for voucher distribution are 679 RECOMMENDED to check for revocation of any domain identity 680 certificates before automated renewal of vouchers. 682 8. IANA Considerations 684 8.1. The IETF XML Registry 686 This document registers a URIs in the IETF XML registry [RFC3688]. 687 Following the format in [RFC3688], the following registration is 688 requested: 690 URI: urn:ietf:params:xml:ns:yang:ietf-voucher 691 Registrant Contact: The ANIMA WG of the IETF. 692 XML: N/A, the requested URI is an XML namespace. 694 8.2. The YANG Module Names Registry 696 This document registers a YANG module in the YANG Module Names 697 registry [RFC6020]. Following the format defined in [RFC6020], the 698 the following registration is requested: 700 name: ietf-voucher 701 namespace: urn:ietf:params:xml:ns:yang:ietf-voucher 702 prefix: vch 703 reference: RFC XXXX 705 9. References 707 9.1. Normative References 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, 711 DOI 10.17487/RFC2119, March 1997, 712 . 714 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 715 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 716 . 718 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 719 the Network Configuration Protocol (NETCONF)", RFC 6020, 720 DOI 10.17487/RFC6020, October 2010, 721 . 723 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 724 RFC 7950, DOI 10.17487/RFC7950, August 2016, 725 . 727 9.2. Informative References 729 [I-D.bjorklund-netmod-yang-tree-diagrams] 730 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", 2017. 732 [I-D.ietf-6tisch-dtsecurity-secure-join] 733 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 734 6tisch-dtsecurity-secure-join-01 (work in progress), 735 February 2017. 737 [I-D.ietf-anima-bootstrapping-keyinfra] 738 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 739 S., and K. Watsen, "Bootstrapping Remote Secure Key 740 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 741 keyinfra-06 (work in progress), May 2017. 743 [I-D.ietf-netconf-zerotouch] 744 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 745 for NETCONF or RESTCONF based Management", draft-ietf- 746 netconf-zerotouch-13 (work in progress), March 2017. 748 [imprinting] 749 Wikipedia, "Wikipedia article: Imprinting", July 2015, 750 . 752 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 753 DOI 10.17487/RFC3688, January 2004, 754 . 756 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 757 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 758 December 2014, . 760 [Stajano99theresurrecting] 761 Stajano, F. and R. Anderson, "The resurrecting duckling: 762 security issues for ad-hoc wireless networks", 1999, 763 . 766 Appendix A. Acknowledgements 768 The authors would like to thank for following for lively discussions 769 on list and in the halls (ordered by last name): 771 Authors' Addresses 773 Kent Watsen 774 Juniper Networks 776 EMail: kwatsen@juniper.net 778 Michael C. Richardson 779 Sandelman Software 781 EMail: mcr+ietf@sandelman.ca 782 URI: http://www.sandelman.ca/ 784 Max Pritikin 785 Cisco Systems 787 EMail: pritikin@cisco.com 789 Toerless Eckert 790 Futurewei Technologies Inc. 791 2330 Central Expy 792 Santa Clara 95050 793 USA 795 EMail: tte+ietf@cs.fau.de