idnits 2.17.00 (12 Aug 2021) /tmp/idnits5209/draft-ietf-netconf-sztp-csr-13.txt: -(1539): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8572, but the abstract doesn't seem to directly say this. It does mention RFC8572 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 221 has weird spacing: '...ntifier bin...' == Line 224 has weird spacing: '...ntifier ide...' == Line 295 has weird spacing: '...rmation cms...' == Line 314 has weird spacing: '...ntifier bin...' == Line 317 has weird spacing: '...ntifier ide...' == (2 more instances...) -- The document date (31 January 2022) is 109 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 (-22) exists of draft-ietf-netconf-crypto-types-21 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2015' ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-24) exists of draft-ietf-netconf-keystore-23 == Outdated reference: A later version (-17) exists of draft-ietf-netconf-trust-anchors-16 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Updates: 8572 (if approved) R. Housley 5 Intended status: Standards Track Vigil Security, LLC 6 Expires: 4 August 2022 S. Turner 7 sn3rd 8 31 January 2022 10 Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch 11 Provisioning (SZTP) Bootstrapping Request 12 draft-ietf-netconf-sztp-csr-13 14 Abstract 16 This draft extends the input to the "get-bootstrapping-data" RPC 17 defined in RFC 8572 to include an optional certificate signing 18 request (CSR), enabling a bootstrapping device to additionally obtain 19 an identity certificate (e.g., an LDevID from IEEE 802.1AR) as part 20 of the "onboarding information" response provided in the RPC-reply. 22 Editorial Note (To be removed by RFC Editor) 24 This draft contains many placeholder values that need to be replaced 25 with finalized values at the time of publication. This note 26 summarizes all of the substitutions that are needed. No other RFC 27 Editor instructions are specified elsewhere in this document. 29 Artwork in this document contains shorthand references to drafts in 30 progress. Please apply the following replacements: 32 * XXXX --> the assigned numerical RFC value for this draft 34 * AAAA --> the assigned RFC value for I-D.ietf-netconf-crypto-types 36 Artwork in this document contains a placeholder value for the 37 publication date of this draft. Please apply the following 38 replacement: 40 * 2022-01-31 --> the publication date of this draft 42 This document contains references to other drafts in progress, both 43 in the Normative References section, as well as in body text 44 throughout. Please update the following references to reflect their 45 final RFC assignments: 47 * I-D.ietf-netconf-crypto-types 48 * I-D.ietf-netconf-keystore 50 * I-D.ietf-netconf-trust-anchors 52 Status of This Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at https://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on 4 August 2022. 69 Copyright Notice 71 Copyright (c) 2022 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 76 license-info) in effect on the date of publication of this document. 77 Please review these documents carefully, as they describe your rights 78 and restrictions with respect to this document. Code Components 79 extracted from this document must include Revised BSD License text as 80 described in Section 4.e of the Trust Legal Provisions and are 81 provided without warranty as described in the Revised BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 87 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 88 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 89 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 90 2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 91 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 92 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 93 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 94 3. The "ietf-ztp-types" Module . . . . . . . . . . . . . . . . . 17 95 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 17 96 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 97 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 98 4.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 27 99 4.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 27 100 4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 28 101 4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 29 102 4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 29 103 4.1.5. Selecting the Best Origin Authentication Mechanism . 30 104 4.1.6. Clearing the Private Key and Associated 105 Certificate . . . . . . . . . . . . . . . . . . . . . 30 106 4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 30 107 4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 30 108 4.2.2. Verifying Proof of Origin . . . . . . . . . . . . . . 31 109 4.2.3. Supporting SZTP-Clients that don't trust the 110 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 31 111 4.3. Security Considerations for the "ietf-sztp-csr" YANG 112 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31 113 4.4. Security Considerations for the "ietf-ztp-types" YANG 114 Module . . . . . . . . . . . . . . . . . . . . . . . . . 32 115 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 116 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 32 117 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 32 118 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 119 6.1. Normative References . . . . . . . . . . . . . . . . . . 32 120 6.2. Informative References . . . . . . . . . . . . . . . . . 34 121 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36 122 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 36 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 125 1. Introduction 127 1.1. Overview 129 This draft extends the input to the "get-bootstrapping-data" RPC 130 defined in [RFC8572] to include an optional certificate signing 131 request (CSR) [RFC2986], enabling a bootstrapping device to 132 additionally obtain an identity certificate (e.g., an LDevID 133 [Std-802.1AR-2018]) as part of the "onboarding information" response 134 provided in the RPC-reply. 136 The ability to provision an identity certificate that is purpose- 137 built for a production environment during the bootstrapping process 138 removes reliance on the manufacturer CA, and it also enables the 139 bootstrapped device to join the production environment with an 140 appropriate identity and other attributes in its identity certificate 141 (e.g., an LDevID). 143 Two YANG [RFC7950] modules are defined. The "ietf-ztp-types" module 144 defines three YANG groupings for the various messages defined in this 145 document. The "ietf-sztp-csr" module augments two groupings into the 146 "get-bootstrapping-data" RPC and defines a YANG Data Structure 147 [RFC8791] around the third grouping. 149 1.2. Terminology 151 This document uses the following terms from [RFC8572]: 153 * Bootstrap Server 154 * Bootstrapping Data 155 * Conveyed Information 156 * Device 157 * Manufacturer 158 * Onboarding Information 159 * Signed Data 161 This document defines the following new terms: 163 SZTP-client The term "SZTP-client" refers to a "device" that is 164 using a "bootstrap server" as a source of "bootstrapping data". 166 SZTP-server The term "SZTP-server" is an alternative term for 167 "bootstrap server" that is symmetric with the "SZTP-client" term. 169 1.3. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 1.4. Conventions 179 Various examples used in this document use a placeholder value for 180 binary data that has been base64 encoded (e.g., "BASE64VALUE="). 181 This placeholder value is used as real base64 encoded structures are 182 often many lines long and hence distracting to the example being 183 presented. 185 2. The "ietf-sztp-csr" Module 187 The "ietf-sztp-csr" module is a YANG 1.1 [RFC7950] module that 188 augments the "ietf-sztp-bootstrap-server" module defined in [RFC8572] 189 and defines a YANG "structure" that is to be conveyed in the "error- 190 info" node defined in Section 7.1 of [RFC8040]. 192 2.1. Data Model Overview 194 The following tree diagram [RFC8340] illustrates the "ietf-sztp-csr" 195 module. 197 module: ietf-sztp-csr 199 augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: 200 +---w (msg-type)? 201 +--:(csr-support) 202 | +---w csr-support 203 | +---w key-generation! 204 | | +---w supported-algorithms 205 | | +---w algorithm-identifier* binary 206 | +---w csr-generation 207 | +---w supported-formats 208 | +---w format-identifier* identityref 209 +--:(csr) 210 +---w (csr-type) 211 +--:(p10-csr) 212 | +---w p10-csr? ct:csr 213 +--:(cmc-csr) 214 | +---w cmc-csr? binary 215 +--:(cmp-csr) 216 +---w cmp-csr? binary 218 structure csr-request: 219 +-- key-generation! 220 | +-- selected-algorithm 221 | +-- algorithm-identifier binary 222 +-- csr-generation 223 | +-- selected-format 224 | +-- format-identifier identityref 225 +-- cert-req-info? ct:csr-info 227 The augmentation defines two kinds of parameters that an SZTP-client 228 can send to an SZTP-server. The YANG structure defines one 229 collection of parameters that an SZTP-server can send to an SZTP- 230 client. 232 In the order of their intended use: 234 * The "csr-support" node is used by the SZTP-client to signal to the 235 SZTP-server that it supports the ability to generate CSRs. This 236 parameter conveys if the SZTP-client is able to generate a new 237 asymmetric key and, if so, which key algorithms it supports, as 238 well as conveys what kinds of CSR structures the SZTP-client is 239 able to generate. 241 * The "csr-request" structure is used by the SZTP-server to request 242 the SZTP-client to generate a CSR. This structure is used to 243 select the key algorithm the SZTP-client should use to generate a 244 new asymmetric key, if supported, the kind of CSR structure the 245 SZTP-client should generate and, optionally, the content for the 246 CSR itself. 248 * The various "csr" nodes are used by the SZTP-client to communicate 249 a CSR to the SZTP-server. 251 | No data model is defined enabling an SZTP-server to communicate 252 | the signed certificate to the SZTP-client. How to do this is 253 | discussed in Section 2.2. 255 To further illustrate how the augmentation and structure defined by 256 the "ietf-sztp-csr" module are used, below are two additional tree 257 diagrams showing these nodes placed where they are used. 259 The following tree diagram [RFC8340] illustrates SZTP's "get- 260 bootstrapping-data" RPC with the augmentation in place. 262 =============== NOTE: '\' line wrapping per RFC 8792 ================ 264 module: ietf-sztp-bootstrap-server 266 rpcs: 267 +---x get-bootstrapping-data 268 +---w input 269 | +---w signed-data-preferred? empty 270 | +---w hw-model? string 271 | +---w os-name? string 272 | +---w os-version? string 273 | +---w nonce? binary 274 | +---w (sztp-csr:msg-type)? 275 | +--:(sztp-csr:csr-support) 276 | | +---w sztp-csr:csr-support 277 | | +---w sztp-csr:key-generation! 278 | | | +---w sztp-csr:supported-algorithms 279 | | | +---w sztp-csr:algorithm-identifier* bina\ 280 ry 281 | | +---w sztp-csr:csr-generation 282 | | +---w sztp-csr:supported-formats 283 | | +---w sztp-csr:format-identifier* identit\ 284 yref 285 | +--:(sztp-csr:csr) 286 | +---w (sztp-csr:csr-type) 287 | +--:(sztp-csr:p10-csr) 288 | | +---w sztp-csr:p10-csr? ct:csr 289 | +--:(sztp-csr:cmc-csr) 290 | | +---w sztp-csr:cmc-csr? binary 291 | +--:(sztp-csr:cmp-csr) 292 | +---w sztp-csr:cmp-csr? binary 293 +--ro output 294 +--ro reporting-level? enumeration {onboarding-server}? 295 +--ro conveyed-information cms 296 +--ro owner-certificate? cms 297 +--ro ownership-voucher? cms 299 The following tree diagram [RFC8340] illustrates RESTCONF's "errors" 300 RPC-reply message with the "csr-request" structure in place. 302 module: ietf-restconf 303 +--ro errors 304 +--ro error* [] 305 +--ro error-type enumeration 306 +--ro error-tag string 307 +--ro error-app-tag? string 308 +--ro error-path? instance-identifier 309 +--ro error-message? string 310 +--ro error-info 311 +--ro sztp-csr:csr-request 312 +--ro sztp-csr:key-generation! 313 | +--ro sztp-csr:selected-algorithm 314 | +--ro sztp-csr:algorithm-identifier binary 315 +--ro sztp-csr:csr-generation 316 | +--ro sztp-csr:selected-format 317 | +--ro sztp-csr:format-identifier identityref 318 +--ro sztp-csr:cert-req-info? ct:csr-info 320 2.2. Example Usage 322 | The examples below are encoded using JSON, but they could 323 | equally well be encoded using XML, as is supported by SZTP. 325 An SZTP-client implementing this specification would signal to the 326 bootstrap server its willingness to generate a CSR by including the 327 "csr-support" node in its "get-bootstrapping-data" RPC. In the 328 example below, the SZTP-client additionally indicates that it is able 329 to generate keys and provides a list of key algorithms it supports, 330 as well as provide a list of certificate formats it supports. 332 REQUEST 333 =============== NOTE: '\' line wrapping per RFC 8792 ================ 335 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 336 ng-data HTTP/1.1 337 HOST: example.com 338 Content-Type: application/yang-data+json 340 { 341 "ietf-sztp-bootstrap-server:input" : { 342 "hw-model": "model-x", 343 "os-name": "vendor-os", 344 "os-version": "17.3R2.1", 345 "nonce": "extralongbase64encodedvalue=", 346 "ietf-sztp-csr:csr-support": { 347 "key-generation": { 348 "supported-algorithms": { 349 "algorithm-identifier": [ 350 "BASE64VALUE1", 351 "BASE64VALUE2", 352 "BASE64VALUE3" 353 ] 354 } 355 }, 356 "csr-generation": { 357 "supported-formats": { 358 "format-identifier": [ 359 "ietf-ztp-types:p10-csr", 360 "ietf-ztp-types:cmc-csr", 361 "ietf-ztp-types:cmp-csr" 362 ] 363 } 364 } 365 } 366 } 367 } 369 Assuming the SZTP-server wishes to prompt the SZTP-client to provide 370 a CSR, then it would respond with an HTTP 400 Bad Request error code. 371 In the example below, the SZTP-server specifies that it wishes the 372 SZTP-client to generate a key using a specific algorithm and generate 373 a PKCS#10-based CSR containing specific content. 375 RESPONSE 376 HTTP/1.1 400 Bad Request 377 Date: Sat, 31 Oct 2021 17:02:40 GMT 378 Server: example-server 379 Content-Type: application/yang-data+json 381 { 382 "ietf-restconf:errors" : { 383 "error" : [ 384 { 385 "error-type": "application", 386 "error-tag": "missing-attribute", 387 "error-message": "Missing input parameter", 388 "error-info": { 389 "ietf-sztp-csr:csr-request": { 390 "key-generation": { 391 "selected-algorithm": { 392 "algorithm-identifier": "BASE64VALUE=" 393 } 394 }, 395 "csr-generation": { 396 "selected-format": { 397 "format-identifier": "ietf-ztp-types:p10-csr" 398 } 399 }, 400 "cert-req-info": "BASE64VALUE=" 401 } 402 } 403 } 404 ] 405 } 406 } 408 Upon being prompted to provide a CSR, the SZTP-client would POST 409 another "get-bootstrapping-data" request, but this time including one 410 of the "csr" nodes to convey its CSR to the SZTP-server: 412 REQUEST 413 =============== NOTE: '\' line wrapping per RFC 8792 ================ 415 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 416 ng-data HTTP/1.1 417 HOST: example.com 418 Content-Type: application/yang-data+json 420 { 421 "ietf-sztp-bootstrap-server:input" : { 422 "hw-model": "model-x", 423 "os-name": "vendor-os", 424 "os-version": "17.3R2.1", 425 "nonce": "extralongbase64encodedvalue=", 426 "ietf-sztp-csr:p10-csr": "BASE64VALUE=" 427 } 428 } 430 At this point, it is expected that the SZTP-server, perhaps in 431 conjunction with other systems, such as a backend CA or RA, will 432 validate the CSR's origin and proof-of-possession and, assuming the 433 CSR is approved, issue a signed certificate for the bootstrapping 434 device. 436 The SZTP-server responds with "onboarding-information" (encoded 437 inside the "conveyed-information" node, shown below) containing a 438 signed identity certificate for the CSR provided by the SZTP-client: 440 RESPONSE 442 HTTP/1.1 200 OK 443 Date: Sat, 31 Oct 2021 17:02:40 GMT 444 Server: example-server 445 Content-Type: application/yang-data+json 447 { 448 "ietf-sztp-bootstrap-server:output" : { 449 "reporting-level": "verbose", 450 "conveyed-information": "BASE64VALUE=" 451 } 452 } 454 How the signed certificate is conveyed inside the onboarding 455 information is outside the scope of this document. Some 456 implementations may choose to convey it inside a script (e.g., SZTP's 457 "pre-configuration-script"), while other implementations may choose 458 to convey it inside the SZTP "configuration" node. SZTP onboarding 459 information is described in Section 2.2 of [RFC8572]. 461 Below are two examples of conveying the signed certificate inside the 462 "configuration" node. Both examples assume that the SZTP-client 463 understands the "ietf-keystore" module defined in 464 [I-D.ietf-netconf-keystore]. 466 This first example illustrates the case where the signed certificate 467 is for the same asymmetric key used by the SZTP-client's 468 manufacturer-generated identity certificate (e.g., an IDevID, from 469 [Std-802.1AR-2018]). As such, the configuration needs to associate 470 the newly signed certificate with the existing asymmetric key: 472 =============== NOTE: '\' line wrapping per RFC 8792 ================ 474 { 475 "ietf-keystore:keystore": { 476 "asymmetric-keys": { 477 "asymmetric-key": [ 478 { 479 "name": "Manufacturer-Generated Hidden Key", 480 "public-key-format": "ietf-crypto-types:subject-public-key\ 481 -info-format", 482 "public-key": "BASE64VALUE=", 483 "hidden-private-key": [null], 484 "certificates": { 485 "certificate": [ 486 { 487 "name": "Manufacturer-Generated IDevID Cert", 488 "cert-data": "BASE64VALUE=" 489 }, 490 { 491 "name": "Newly-Generated LDevID Cert", 492 "cert-data": "BASE64VALUE=" 493 } 494 ] 495 } 496 } 497 ] 498 } 499 } 500 } 502 This second example illustrates the case where the signed certificate 503 is for a newly generated asymmetric key. As such, the configuration 504 needs to associate the newly signed certificate with the newly 505 generated asymmetric key: 507 =============== NOTE: '\' line wrapping per RFC 8792 ================ 509 { 510 "ietf-keystore:keystore": { 511 "asymmetric-keys": { 512 "asymmetric-key": [ 513 { 514 "name": "Manufacturer-Generated Hidden Key", 515 "public-key-format": "ietf-crypto-types:subject-public-key\ 516 -info-format", 517 "public-key": "BASE64VALUE=", 518 "hidden-private-key": [null], 519 "certificates": { 520 "certificate": [ 521 { 522 "name": "Manufacturer-Generated IDevID Cert", 523 "cert-data": "BASE64VALUE=" 524 } 525 ] 526 } 527 }, 528 { 529 "name": "Newly-Generated Hidden Key", 530 "public-key-format": "ietf-crypto-types:subject-public-key\ 531 -info-format", 532 "public-key": "BASE64VALUE=", 533 "hidden-private-key": [null], 534 "certificates": { 535 "certificate": [ 536 { 537 "name": "Newly-Generated LDevID Cert", 538 "cert-data": "BASE64VALUE=" 539 } 540 ] 541 } 542 } 543 ] 544 } 545 } 546 } 548 In addition to configuring the signed certificate, it is often 549 necessary to also configure the Issuer's signing certificate so that 550 the device (i.e., STZP-client) can authenticate certificates 551 presented by peer devices signed by the same issuer as its own. 552 While outside the scope of this document, one way to do this would be 553 to use the "ietf-truststore" module defined in 554 [I-D.ietf-netconf-trust-anchors]. 556 2.3. YANG Module 558 This module augments an RPC defined in [RFC8572]. The module uses a 559 data types and groupings defined in [RFC8572], [RFC8791], and 560 [I-D.ietf-netconf-crypto-types]. The module also has an informative 561 reference to [Std-802.1AR-2018]. 563 file "ietf-sztp-csr@2022-01-31.yang" 565 module ietf-sztp-csr { 566 yang-version 1.1; 567 namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; 568 prefix sztp-csr; 570 import ietf-sztp-bootstrap-server { 571 prefix sztp-svr; 572 reference 573 "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 574 } 576 import ietf-yang-structure-ext { 577 prefix sx; 578 reference 579 "RFC 8791: YANG Data Structure Extensions"; 580 } 582 import ietf-ztp-types { 583 prefix zt; 584 reference 585 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 586 in a Secure Zero Touch Provisioning (SZTP) 587 Bootstrapping Request"; 588 } 590 organization 591 "IETF NETCONF (Network Configuration) Working Group"; 593 contact 594 "WG Web: https://datatracker.ietf.org/wg/netconf 595 WG List: NETCONF WG list 596 Authors: Kent Watsen 597 Russ Housley 598 Sean Turner "; 600 description 601 "This module augments the 'get-bootstrapping-data' RPC, 602 defined in the 'ietf-sztp-bootstrap-server' module from 603 SZTP (RFC 8572), enabling the SZTP-client to obtain a 604 signed identity certificate (e.g., an LDevID from IEEE 605 802.1AR) as part of the SZTP onboarding information 606 response. 608 Copyright (c) 2022 IETF Trust and the persons identified 609 as authors of the code. All rights reserved. 611 Redistribution and use in source and binary forms, with 612 or without modification, is permitted pursuant to, and 613 subject to the license terms contained in, the Revised 614 BSD License set forth in Section 4.c of the IETF Trust's 615 Legal Provisions Relating to IETF Documents 616 (https://trustee.ietf.org/license-info). 618 This version of this YANG module is part of RFC XXXX 619 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 620 itself for full legal notices. 622 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 623 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 624 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 625 document are to be interpreted as described in BCP 14 626 (RFC 2119) (RFC 8174) when, and only when, they appear 627 in all capitals, as shown here."; 629 revision 2022-01-31 { 630 description 631 "Initial version"; 632 reference 633 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 634 in a Secure Zero Touch Provisioning (SZTP) 635 Bootstrapping Request"; 636 } 638 // Protocol-accessible nodes 640 augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { 641 description 642 "This augmentation adds the 'csr-support' and 'csr' nodes to 643 the SZTP (RFC 8572) 'get-bootstrapping-data' request message, 644 enabling the SZTP-client to obtain an identity certificate 645 (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding 646 information response provided by the SZTP-server. 648 The 'csr-support' node enables the SZTP-client to indicate 649 that it supports generating certificate signing requests 650 (CSRs), and to provide details around the CSRs it is able 651 to generate. 653 The 'csr' node enables the SZTP-client to relay a CSR to 654 the SZTP-server."; 655 reference 656 "IEEE 802.1AR: IEEE Standard for Local and metropolitan 657 area networks - Secure Device Identity 658 RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 659 choice msg-type { 660 description 661 "Messages are mutually exclusive."; 662 case csr-support { 663 description 664 "Indicates how the SZTP-client supports generating CSRs. 666 If present and a SZTP-server wishes to request the 667 SZTP-client generate a CSR, the SZTP-server MUST 668 respond with HTTP code 400 Bad Request with an 669 'ietf-restconf:errors' message having the 'error-tag' 670 value 'missing-attribute' and the 'error-info' node 671 containing the 'csr-request' structure described 672 in this module."; 673 uses zt:csr-support-grouping; 674 } 675 case csr { 676 description 677 "Provides the CSR generated by the SZTP-client. 679 When present, the SZTP-server SHOULD respond with 680 an SZTP onboarding information message containing 681 a signed certificate for the conveyed CSR. The 682 SZTP-server MAY alternatively respond with another 683 HTTP error containing another 'csr-request', in 684 which case the SZTP-client MUST delete any key 685 generated for the previously generated CSR."; 686 uses zt:csr-grouping; 687 } 688 } 689 } 691 sx:structure csr-request { 692 description 693 "A YANG data structure, per RFC 8791, that specifies 694 details for the CSR that the ZTP-client is to generate."; 695 reference 696 "RFC 8791: YANG Data Structure Extensions"; 697 uses zt:csr-request-grouping; 698 } 700 } 701 703 3. The "ietf-ztp-types" Module 705 This section defines a YANG 1.1 [RFC7950] module that defines three 706 YANG groupings, one each for messages sent between a ZTP-client and 707 ZTP-server. This module is defined independently of the "ietf-sztp- 708 csr" module so that it's groupings may be used by bootstrapping 709 protocols other than SZTP [RFC8572]. 711 3.1. Data Model Overview 713 The following tree diagram [RFC8340] illustrates the three groupings 714 defined in the "ietf-ztp-types" module. 716 module: ietf-ztp-types 718 grouping csr-support-grouping 719 +-- csr-support 720 +-- key-generation! 721 | +-- supported-algorithms 722 | +-- algorithm-identifier* binary 723 +-- csr-generation 724 +-- supported-formats 725 +-- format-identifier* identityref 726 grouping csr-request-grouping 727 +-- key-generation! 728 | +-- selected-algorithm 729 | +-- algorithm-identifier binary 730 +-- csr-generation 731 | +-- selected-format 732 | +-- format-identifier identityref 733 +-- cert-req-info? ct:csr-info 734 grouping csr-grouping 735 +-- (csr-type) 736 +--:(p10-csr) 737 | +-- p10-csr? ct:csr 738 +--:(cmc-csr) 739 | +-- cmc-csr? binary 740 +--:(cmp-csr) 741 +-- cmp-csr? binary 743 3.2. YANG Module 745 This module uses a data types and groupings [RFC8791] and 746 [I-D.ietf-netconf-crypto-types]. The module has additional normative 747 references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015], 748 and an informative reference to [Std-802.1AR-2018]. 750 file "ietf-ztp-types@2022-01-31.yang" 752 module ietf-ztp-types { 753 yang-version 1.1; 754 namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types"; 755 prefix zt; 757 import ietf-crypto-types { 758 prefix ct; 759 reference 760 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 761 } 763 organization 764 "IETF NETCONF (Network Configuration) Working Group"; 766 contact 767 "WG Web: https://datatracker.ietf.org/wg/netconf 768 WG List: NETCONF WG list 769 Authors: Kent Watsen 770 Russ Housley 771 Sean Turner "; 773 description 774 "This module defines three groupings that enable 775 bootstrapping devices to 1) indicate if and how they 776 support generating CSRs, 2) obtain a request to 777 generate a CSR, and 3) communicate the requested CSR. 779 Copyright (c) 2022 IETF Trust and the persons identified 780 as authors of the code. All rights reserved. 782 Redistribution and use in source and binary forms, with 783 or without modification, is permitted pursuant to, and 784 subject to the license terms contained in, the Revised 785 BSD License set forth in Section 4.c of the IETF Trust's 786 Legal Provisions Relating to IETF Documents 787 (https://trustee.ietf.org/license-info). 789 This version of this YANG module is part of RFC XXXX 790 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 791 itself for full legal notices. 793 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 794 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 795 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 796 document are to be interpreted as described in BCP 14 797 (RFC 2119) (RFC 8174) when, and only when, they appear 798 in all capitals, as shown here."; 800 revision 2022-01-31 { 801 description 802 "Initial version"; 803 reference 804 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 805 in a Secure Zero Touch Provisioning (SZTP) 806 Bootstrapping Request"; 807 } 809 identity certificate-request-format { 810 description 811 "A base identity for the request formats supported 812 by the ZTP-client. 814 Additional derived identities MAY be defined by 815 future efforts."; 816 } 818 identity p10-csr { 819 base certificate-request-format; 820 description 821 "Indicates that the ZTP-client supports generating 822 requests using the 'CertificationRequest' structure 823 defined in RFC 2986."; 824 reference 825 "RFC 2986: PKCS #10: Certification Request Syntax 826 Specification Version 1.7"; 827 } 829 identity cmp-csr { 830 base certificate-request-format; 831 description 832 "Indicates that the ZTP-client supports generating 833 requests using a profiled version of the PKIMessage 834 that MUST contain a PKIHeader followed by a PKIBody 835 containing only the p10cr structure defined in 836 RFC 4210."; 837 reference 838 "RFC 4210: Internet X.509 Public Key Infrastructure 839 Certificate Management Protocol (CMP)"; 840 } 842 identity cmc-csr { 843 base certificate-request-format; 844 description 845 "Indicates that the ZTP-client supports generating 846 requests using a profiled version of the 'Full 847 PKI Request' structure defined in RFC 5272."; 848 reference 849 "RFC 5272: Certificate Management over CMS (CMC)"; 850 } 852 // Protocol-accessible nodes 854 grouping csr-support-grouping { 855 description 856 "A grouping enabling use by other efforts."; 857 container csr-support { 858 description 859 "Enables a ZTP-client to indicate that it supports 860 generating certificate signing requests (CSRs) and 861 provides details about the CSRs it is able to 862 generate."; 863 container key-generation { 864 presence 865 "Indicates that the ZTP-client is capable of 866 generating a new asymmetric key pair. 868 If this node is not present, the ZTP-server MAY 869 request a CSR using the asymmetric key associated 870 with the device's existing identity certificate 871 (e.g., an IDevID from IEEE 802.1AR)."; 872 description 873 "Specifies details for the ZTP-client's ability to 874 generate a new asymmetric key pair."; 875 container supported-algorithms { 876 description 877 "A list of public key algorithms supported by the 878 ZTP-client for generating a new asymmetric key."; 879 leaf-list algorithm-identifier { 880 type binary; 881 min-elements 1; 882 description 883 "An AlgorithmIdentifier, as defined in RFC 2986, 884 encoded using ASN.1 distinguished encoding rules 885 (DER), as specified in ITU-T X.690."; 886 reference 887 "RFC 2986: PKCS #10: Certification Request Syntax 888 Specification Version 1.7 889 ITU-T X.690: 890 Information technology - ASN.1 encoding rules: 891 Specification of Basic Encoding Rules (BER), 892 Canonical Encoding Rules (CER) and Distinguished 893 Encoding Rules (DER)."; 895 } 896 } 897 } 898 container csr-generation { 899 description 900 "Specifies details for the ZTP-client's ability to 901 generate a certificate signing requests."; 902 container supported-formats { 903 description 904 "A list of certificate request formats supported 905 by the ZTP-client for generating a new key."; 906 leaf-list format-identifier { 907 type identityref { 908 base zt:certificate-request-format; 909 } 910 min-elements 1; 911 description 912 "A certificate request format supported by the 913 ZTP-client."; 914 } 915 } 916 } 917 } 918 } 920 grouping csr-request-grouping { 921 description 922 "A grouping enabling use by other efforts."; 923 container key-generation { 924 presence 925 "Provided by a ZTP-server to indicate that it wishes 926 the ZTP-client to generate a new asymmetric key. 928 This statement is present so the mandatory descendant 929 nodes do not imply that this node must be configured."; 930 description 931 "The key generation parameters selected by the ZTP-server. 933 This leaf MUST only appear if the ZTP-client's 934 'csr-support' included the 'key-generation' node."; 935 container selected-algorithm { 936 description 937 "The key algorithm selected by the ZTP-server. The 938 algorithm MUST be one of the algorithms specified by 939 the 'supported-algorithms' node in the ZTP-client's 940 message containing the 'csr-support' structure."; 941 leaf algorithm-identifier { 942 type binary; 943 mandatory true; 944 description 945 "An AlgorithmIdentifier, as defined in RFC 2986, 946 encoded using ASN.1 distinguished encoding rules 947 (DER), as specified in ITU-T X.690."; 948 reference 949 "RFC 2986: PKCS #10: Certification Request Syntax 950 Specification Version 1.7 951 ITU-T X.690: 952 Information technology - ASN.1 encoding rules: 953 Specification of Basic Encoding Rules (BER), 954 Canonical Encoding Rules (CER) and Distinguished 955 Encoding Rules (DER)."; 956 } 957 } 958 } 959 container csr-generation { 960 description 961 "Specifies details for the CSR that the ZTP-client 962 is to generate."; 963 container selected-format { 964 description 965 "The CSR format selected by the ZTP-server. The 966 format MUST be one of the formats specified by 967 the 'supported-formats' node in the ZTP-client's 968 request message."; 969 leaf format-identifier { 970 type identityref { 971 base zt:certificate-request-format; 972 } 973 mandatory true; 974 description 975 "A certificate request format to be used by the 976 ZTP-client."; 977 } 978 } 979 } 980 leaf cert-req-info { 981 type ct:csr-info; 982 description 983 "A CertificationRequestInfo structure, as defined in 984 RFC 2986, and modeled via a 'typedef' statement by 985 RFC AAAA. 987 Enables the ZTP-server to provide a fully-populated 988 CertificationRequestInfo structure that the ZTP-client 989 only needs to sign in order to generate the complete 990 'CertificationRequest' structure to send to ZTP-server 991 in its next 'get-bootstrapping-data' request message. 993 When provided, the ZTP-client MUST use this structure 994 to generate its CSR; failure to do so will result in a 995 400 Bad Request response containing another 'csr-request' 996 structure. 998 When not provided, the ZTP-client SHOULD generate a CSR 999 using the same structure defined in its existing identity 1000 certificate (e.g., an IDevID from IEEE 802.1AR). 1002 If the 'AlgorithmIdentifier' field contained inside the 1003 certificate 'SubjectPublicKeyInfo' field does not match 1004 the algorithm identified by the 'selected-algorithm' node, 1005 then the client MUST reject the certificate and raise an 1006 error."; 1008 reference 1009 "RFC 2986: 1010 PKCS #10: Certification Request Syntax Specification 1011 RFC AAAA: 1012 YANG Data Types and Groupings for Cryptography"; 1013 } 1014 } 1016 grouping csr-grouping { 1017 description 1018 "Enables a ZTP-client to convey a certificate signing 1019 request, using the encoding format selected by a 1020 ZTP-server's 'csr-request' response to the ZTP-client's 1021 previously sent request containing the 'csr-support' 1022 node."; 1023 choice csr-type { 1024 mandatory true; 1025 description 1026 "A choice amongst certificate signing request formats. 1028 Additional formats MAY be augmented into this 'choice' 1029 statement by future efforts."; 1030 case p10-csr { 1031 leaf p10-csr { 1032 type ct:csr; 1033 description 1034 "A CertificationRequest structure, per RFC 2986. 1035 Encoding details are defined in the 'ct:csr' 1036 typedef defined in RFC AAAA. 1038 A raw P10 does not support origin authentication in 1039 the CSR structure. External origin authentication 1040 may be provided via the ZTP-client's authentication 1041 to the ZTP-server at the transport layer (e.g., TLS)."; 1042 reference 1043 "RFC 2986: PKCS #10: Certification Request Syntax 1044 Specification 1045 RFC AAAA: YANG Data Types and Groupings for 1046 Cryptography"; 1047 } 1048 } 1049 case cmc-csr { 1050 leaf cmc-csr { 1051 type binary; 1052 description 1053 "A profiled version of the 'Full PKI Request' 1054 message defined in RFC 5272, encoded using ASN.1 1055 distinguished encoding rules (DER), as specified 1056 in ITU-T X.690. 1058 For asymmetric key-based origin authentication of a 1059 CSR based on the initial device identity certificate's 1060 private key for the associated identity certificate's 1061 public key, the PKIData contains one reqSequence 1062 element and no cmsSequence or otherMsgSequence 1063 elements. The reqSequence is the TaggedRequest 1064 and it is the tcr CHOICE branch. The tcr is the 1065 TaggedCertificationRequest and it is the bodyPartId 1066 and the certificateRequest elements. The 1067 certificateRequest is signed with the initial device 1068 identity certificate's private key. The initial device 1069 identity certificate and optionally its certificate 1070 chain is included in the SignedData certificates that 1071 encapsulates the PKIData. 1073 For asymmetric key-based origin authentication based on 1074 the initial device identity certificate's private key 1075 that signs the encapsulated CSR signed by the local 1076 device identity certificate's private key, the 1077 PKIData contains one cmsSequence element and no 1078 reqSequence or otherMsgSequence 1079 elements. The cmsSequence is the TaggedContentInfo 1080 and it includes a bodyPartID element and a contentInfo. 1081 The contentInfo is a SignedData encapsulating a PKIData 1082 with one reqSequence element and no cmsSequence or 1083 otherMsgSequence elements. The reqSequence is the 1084 TaggedRequest and it is the tcr CHOICE. The tcr is the 1085 TaggedCertificationRequest and it is the bodyPartId and 1086 the certificateRequest elements. PKIData contains one 1087 cmsSequence element and no controlSequence, reqSequence, 1088 or otherMsgSequence elements. The certificateRequest 1089 is signed with the local device identity certificate's 1090 private key. The initial device identity certificate 1091 and optionally its certificate chain is included in the 1092 SignedData certificates that encapsulates the PKIData. 1094 For shared secret-based origin authentication of a 1095 CSR signed by the local device identity certificate's 1096 private key, the PKIData contains one cmsSequence 1097 element and no reqSequence or otherMsgSequence 1098 elements. The cmsSequence is the TaggedContentInfo 1099 and it includes a bodyPartID element and a contentInfo. 1100 The contentInfo is an AuthenticatedData encapsulating 1101 a PKIData with one reqSequence element and no 1102 cmsSequences or otherMsgSequence elements. The 1103 reqSequence is the TaggedRequest and it is the tcr 1104 CHOICE. The tcr is the TaggedCertificationRequest 1105 and it is the bodyPartId and the certificateRequest 1106 elements. The certificateRequest is signed with the 1107 local device identity certificate's private key. The 1108 initial device identity certificate and optionally its 1109 certificate chain is included in the SignedData 1110 certificates that encapsulates the PKIData."; 1111 reference 1112 "RFC 5272: Certificate Management over CMS (CMC) 1113 ITU-T X.690: 1114 Information technology - ASN.1 encoding rules: 1115 Specification of Basic Encoding Rules (BER), 1116 Canonical Encoding Rules (CER) and Distinguished 1117 Encoding Rules (DER)."; 1118 } 1119 } 1120 case cmp-csr { 1121 leaf cmp-csr { 1122 type binary; 1123 description 1124 "A PKIMessage structure, as defined in RFC 4210, 1125 encoded using ASN.1 distinguished encoding rules 1126 (DER), as specified in ITU-T X.690. 1128 For asymmetric key-based origin authentication of a 1129 CSR based on the initial device identity certificate's 1130 private key for the associated initial device identity 1131 certificate's public key, PKIMessages contains one 1132 PKIMessage with the header and body elements, no 1133 protection element, and SHOULD contain the extraCerts 1134 element. The header element contains the pvno, sender, 1135 and recipient elements. The pvno contains cmp2000, and 1136 the sender contains the subject of the initial device 1137 identity certificate. The body element contains a p10cr 1138 CHOICE of type CertificationRequest. It is signed with 1139 the initial device identity certificate's private key. 1140 The extraCerts element contains the initial device 1141 identity certificate, optionally followed by its 1142 certificate chain excluding the trust anchor. 1144 For asymmetric key-based origin authentication based on 1145 the initial device identity certificate's private key 1146 that signs the encapsulated CSR signed by the local 1147 device identity certificate's private key, PKIMessages 1148 contains one PKIMessage with the header, body, and 1149 protection elements, and SHOULD contain the extraCerts 1150 element. The header element contains the pvno, sender, 1151 recipient, protectionAlg, and optionally senderKID 1152 elements. The pvno contains cmp2000, the sender 1153 contains the subject of the initial device identity 1154 certificate, the protectionAlg contains the 1155 AlgorithmIdentifier of the used signature algorithm, 1156 and the senderKID contains the subject key identifier 1157 of the initial device identity certificate. The 1158 body element contains a p10cr CHOICE of type 1159 CertificationRequest. It is signed with the local device 1160 identity certificate's private key. The protection 1161 element contains the digital signature generated with 1162 the initial device identity certificate's private key. 1163 The extraCerts element contains the initial device 1164 identity certificate, optionally followed by its 1165 certificate chain excluding the trust anchor. 1167 For shared secret-based origin authentication of a 1168 CSR signed by the local device identity certificate's 1169 private key, PKIMessages contains one PKIMessage with 1170 the header, body, and protection element, and no 1171 extraCerts element. The header element contains the 1172 pvno, sender, recipient, protectionAlg, and senderKID 1173 elements. The pvno contains cmp2000, the protectionAlg 1174 contains the AlgorithmIdentifier of the used MAC 1175 algorithm, and the senderKID contains a reference 1176 the recipient can use to identify the shared secret. 1177 The body element contains a p10cr CHOICE of type 1178 CertificationRequest. It is signed with the local 1179 device identity certificate's private key. The 1180 protection element contains the MAC value generated 1181 with the shared secret."; 1182 reference 1183 "RFC 4210: 1184 Internet X.509 Public Key Infrastructure 1185 Certificate Management Protocol (CMP) 1186 ITU-T X.690: 1187 Information technology - ASN.1 encoding rules: 1188 Specification of Basic Encoding Rules (BER), 1189 Canonical Encoding Rules (CER) and Distinguished 1190 Encoding Rules (DER)."; 1191 } 1192 } 1193 } 1194 } 1196 } 1198 1200 4. Security Considerations 1202 This document builds on top of the solution presented in [RFC8572] 1203 and therefore all the Security Considerations discussed in RFC 8572 1204 apply here as well. 1206 For the various CSR formats, when using PKCS#10, the security 1207 considerations in [RFC2986] apply, when using CMP, the security 1208 considerations in [RFC4210] apply and, when using CMC, the security 1209 considerations in [RFC5272] apply. 1211 For the various authentication mechanisms, when using TLS-level 1212 authentication, the security considerations in [RFC8446] apply and, 1213 when using HTTP-level authentication, the security considerations in 1214 [RFC7235] apply. 1216 4.1. SZTP-Client Considerations 1218 4.1.1. Ensuring the Integrity of Asymmetric Private Keys 1220 The private key the SZTP-client uses for the dynamically-generated 1221 identity certificate MUST be protected from inadvertent disclosure in 1222 order to prevent identity fraud. 1224 The security of this private key is essential in order to ensure the 1225 associated identity certificate can be used to authenticate the 1226 device it is issued to. 1228 It is RECOMMENDED that devices are manufactured with an HSM (hardware 1229 security module), such as a TPM (trusted platform module), to 1230 generate and contain the private key within the security perimeter of 1231 the HSM. In such cases, the private key, and its associated 1232 certificates, MAY have long validity periods. 1234 In cases where the SZTP-client does not possess an HSM, or is unable 1235 to use an HSM to protect the private key, it is RECOMMENDED to 1236 periodically reset the private key (and associated identity 1237 certificates) in order to minimize the lifetime of unprotected 1238 private keys. For instance, an NMS controller/orchestrator 1239 application could periodically prompt the SZTP-client to generate a 1240 new private key and provide a certificate signing request (CSR) or, 1241 alternatively, push both the key and an identity certificate to the 1242 SZTP-client using, e.g., a PKCS #12 message [RFC7292]. In another 1243 example, the SZTP-client could be configured to periodically reset 1244 the configuration to its factory default, thus causing removal of the 1245 private key and associated identity certificates and re-execution of 1246 the SZTP protocol. 1248 4.1.2. Reuse of a Manufacturer-generated Private Key 1250 It is RECOMMENDED that a new private key is generated for each CSR 1251 described in this document. 1253 Implementations must randomly generate nonces and private keys. The 1254 use of inadequate pseudo-random number generators (PRNGs) to generate 1255 cryptographic keys can result in little or no security. An attacker 1256 may find it much easier to reproduce the PRNG environment that 1257 produced the keys, searching the resulting small set of 1258 possibilities, rather than brute force searching the whole key space. 1259 As an example of predictable random numbers see CVE-2008-0166 1260 [CVE-2008-0166], and some consequences of low-entropy random numbers 1261 are discussed in Mining Your Ps and Qs [MiningPsQs]. The generation 1262 of quality random numbers is difficult. [ISO.20543-2019], 1263 [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and 1264 others offer valuable guidance in this area. 1266 This private key SHOULD be protected as well as the built-in private 1267 key associated with the SZTP-client's initial device identity 1268 certificate (e.g., the IDevID, from [Std-802.1AR-2018]). 1270 In cases where it is not possible to generate a new private key that 1271 is protected as well as the built-in private key, it is RECOMMENDED 1272 to reuse the built-in private key rather than generate a new private 1273 key that is not as well protected. 1275 4.1.3. Replay Attack Protection 1277 This RFC enables an SZTP-client to announce an ability to generate a 1278 new key to use for its CSR. 1280 When the SZTP-server responds with a request for the SZTP-client to 1281 generate a new key, it is essential that the SZTP-client actually 1282 generates a new key. 1284 Generating a new key each time enables the random bytes used to 1285 create the key to also serve the dual-purpose of acting like a 1286 "nonce" used in other mechanisms to detect replay attacks. 1288 When a fresh public/private key pair is generated for the request, 1289 confirmation to the SZTP-client that the response has not been 1290 replayed is enabled by the SZTP-client's fresh public key appearing 1291 in the signed certificate provided by the SZTP-server. 1293 When a public/private key pair associated with the manufacturer- 1294 generated identity certificate (e.g., IDevID) is used for the 1295 request, there may not be confirmation to the SZTP-client that the 1296 response has not been replayed; however, the worst case result is a 1297 lost certificate that is associated to the private key known only to 1298 the SZTP-client. Protection of the private-key information is vital 1299 to public-key cryptography. Disclosure of the private-key material 1300 to another entity can lead to masquerades. 1302 4.1.4. Connecting to an Untrusted Bootstrap Server 1304 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1305 by blindly authenticating the SZTP-server's TLS end-entity 1306 certificate. 1308 As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- 1309 client MUST assert that the bootstrapping data returned is signed, if 1310 the SZTP-client is to trust it. 1312 However, the HTTP error message used in this document cannot be 1313 signed data, as described in RFC 8572. 1315 Therefore, the solution presented in this document cannot be used 1316 when the SZTP-client connects to an untrusted SZTP-server. 1318 Consistent with the recommendation presented in Section 9.6 of 1319 [RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input 1320 parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass 1321 instead the "signed-data-preferred" input parameter, as discussed in 1322 Appendix B of [RFC8572]. 1324 4.1.5. Selecting the Best Origin Authentication Mechanism 1326 The origin of the CSR must be verified before a certificate is 1327 issued. 1329 When generating a new key, it is important that the SZTP-client be 1330 able to provide additional proof that it was the entity that 1331 generated the key. 1333 The CMP and CMC certificate request formats defined in this document 1334 support origin authentication. A raw PKCS#10 CSR does not support 1335 origin authentication. 1337 The CMP and CMC request formats support origin authentication using 1338 both PKI and shared secret. 1340 Typically, only one possible origin authentication mechanism can 1341 possibly be used but, in the case that the SZTP-client authenticates 1342 itself using both TLS-level (e.g., IDevID) and HTTP-level credentials 1343 (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the 1344 SZTP-client may need to choose between the two options. 1346 In the case that the SZTP-client must choose between an asymmetric 1347 key option versus a shared secret for origin authentication, it is 1348 RECOMMENDED that the SZTP-client choose using the asymmetric key. 1350 4.1.6. Clearing the Private Key and Associated Certificate 1352 Unlike a manufacturer-generated identity certificate (e.g., IDevID), 1353 the deployment-generated identity certificate (e.g., LDevID) and the 1354 associated private key (assuming a new private key was generated for 1355 the purpose), are considered user data and SHOULD be cleared whenever 1356 the SZTP-client is reset to its factory default state, such as by the 1357 "factory-reset" RPC defined in [RFC8808]. 1359 4.2. SZTP-Server Considerations 1361 4.2.1. Verifying Proof of Possession 1363 Regardless if using a new asymmetric key or the bootstrapping 1364 device's manufacturer-generated key (e.g., the IDevID key), the 1365 public key is placed in the CSR and the CSR is signed by that private 1366 key. Proof-of-possession of the private key is verified by ensuring 1367 the signature over the CSR using the public key placed in the CSR. 1369 4.2.2. Verifying Proof of Origin 1371 When the bootstrapping device's manufacturer-generated private key 1372 (e.g., the IDevID key) is reused for the CSR, proof-of-origin is 1373 verified by validating the IDevID-issuer cert and ensuring that the 1374 CSR uses the same key pair. 1376 When the bootstrapping device's manufacturer-generated private key 1377 (e.g., an IDevID key from IEEE 802.1AR) is reused for the CSR, proof- 1378 of-origin is verified by validating the IDevID certification path and 1379 ensuring that the CSR uses the same key pair. 1381 When a fresh asymmetric key is used with the CMP or CMC formats, the 1382 authentication is part of the protocols, which could employ either 1383 the manufacturer-generated private key or a shared secret. In 1384 addition, CMP and CMC support processing by a RA before the request 1385 is passed to the CA, which allows for more robust handling of errors. 1387 4.2.3. Supporting SZTP-Clients that don't trust the SZTP-Server 1389 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1390 by blindly authenticating the SZTP-server's TLS end-entity 1391 certificate. 1393 As is recommended in Section 4.1.4 in this document, in such cases, 1394 SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. 1396 The reciprocal of this statement is that SZTP-servers, wanting to 1397 support SZTP-clients that don't trust them, SHOULD support the 1398 "signed-data-preferred" input parameter, as discussed in Appendix B 1399 of [RFC8572]. 1401 4.3. Security Considerations for the "ietf-sztp-csr" YANG Module 1403 The recommended format for documenting the Security Considerations 1404 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1405 this module only augments two input parameters into the "get- 1406 bootstrapping-data" RPC in [RFC8572], and therefore only needs to 1407 point to the relevant Security Considerations sections in that RFC. 1409 * Security considerations for the "get-bootstrapping-data" RPC are 1410 described in Section 9.16 of [RFC8572]. 1412 * Security considerations for the "input" parameters passed inside 1413 the "get-bootstrapping-data" RPC are described in Section 9.6 of 1414 [RFC8572]. 1416 4.4. Security Considerations for the "ietf-ztp-types" YANG Module 1418 The recommended format for documenting the Security Considerations 1419 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1420 this module does not define any protocol-accessible nodes (it only 1421 defines "identity" and "grouping" statements) and therefore there are 1422 no Security considerations to report. 1424 5. IANA Considerations 1426 5.1. The "IETF XML" Registry 1428 This document registers two URIs in the "ns" subregistry of the IETF 1429 XML Registry [RFC3688] maintained at 1430 https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. 1431 Following the format in [RFC3688], the following registrations are 1432 requested: 1434 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1435 Registrant Contact: The NETCONF WG of the IETF. 1436 XML: N/A, the requested URI is an XML namespace. 1438 URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1439 Registrant Contact: The NETCONF WG of the IETF. 1440 XML: N/A, the requested URI is an XML namespace. 1442 5.2. The "YANG Module Names" Registry 1444 This document registers two YANG modules in the YANG Module Names 1445 registry [RFC6020] maintained at https://www.iana.org/assignments/ 1446 yang-parameters/yang-parameters.xhtml. Following the format defined 1447 in [RFC6020], the below registrations are requested: 1449 name: ietf-sztp-csr 1450 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1451 prefix: sztp-csr 1452 reference: RFC XXXX 1454 name: ietf-ztp-types 1455 namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1456 prefix: ztp-types 1457 reference: RFC XXXX 1459 6. References 1461 6.1. Normative References 1463 [I-D.ietf-netconf-crypto-types] 1464 Watsen, K., "YANG Data Types and Groupings for 1465 Cryptography", Work in Progress, Internet-Draft, draft- 1466 ietf-netconf-crypto-types-21, 14 September 2021, 1467 . 1470 [ITU.X690.2015] 1471 International Telecommunication Union, "Information 1472 Technology - ASN.1 encoding rules: Specification of Basic 1473 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1474 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1475 X.690, ISO/IEC 8825-1, August 2015, 1476 . 1478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1479 Requirement Levels", BCP 14, RFC 2119, 1480 DOI 10.17487/RFC2119, March 1997, 1481 . 1483 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1484 Request Syntax Specification Version 1.7", RFC 2986, 1485 DOI 10.17487/RFC2986, November 2000, 1486 . 1488 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1489 DOI 10.17487/RFC3688, January 2004, 1490 . 1492 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1493 "Internet X.509 Public Key Infrastructure Certificate 1494 Management Protocol (CMP)", RFC 4210, 1495 DOI 10.17487/RFC4210, September 2005, 1496 . 1498 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1499 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 1500 . 1502 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1503 the Network Configuration Protocol (NETCONF)", RFC 6020, 1504 DOI 10.17487/RFC6020, October 2010, 1505 . 1507 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1508 Protocol (HTTP/1.1): Authentication", RFC 7235, 1509 DOI 10.17487/RFC7235, June 2014, 1510 . 1512 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1513 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1514 . 1516 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1517 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1518 . 1520 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1521 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1522 May 2017, . 1524 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1525 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1526 . 1528 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1529 Touch Provisioning (SZTP)", RFC 8572, 1530 DOI 10.17487/RFC8572, April 2019, 1531 . 1533 [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data 1534 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1535 June 2020, . 1537 6.2. Informative References 1539 [AIS31] Bundesamt für Sicherheit in der Informationstechnik (BSI), 1540 Killmann, W., and W. Schindler, "A proposal for: 1541 Functionality classes for random number generators, 1542 version 2.0", 18 September 2011, 1543 . 1547 [CVE-2008-0166] 1548 National Institute of Science and Technology (NIST), 1549 "National Vulnerability Database - CVE-2008-0166", 13 May 1550 2008, . 1552 [I-D.ietf-netconf-keystore] 1553 Watsen, K., "A YANG Data Model for a Keystore", Work in 1554 Progress, Internet-Draft, draft-ietf-netconf-keystore-23, 1555 14 December 2021, . 1558 [I-D.ietf-netconf-trust-anchors] 1559 Watsen, K., "A YANG Data Model for a Truststore", Work in 1560 Progress, Internet-Draft, draft-ietf-netconf-trust- 1561 anchors-16, 14 December 2021, 1562 . 1565 [ISO.20543-2019] 1566 International Organization for Standardization (ISO), 1567 "Information technology -- Security techniques -- Test and 1568 analysis methods for random bit generators within ISO/IEC 1569 19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019, 1570 October 2019. 1572 [MiningPsQs] 1573 Security'12: Proceedings of the 21st USENIX conference on 1574 Security symposium, Heninger, N., Durumeric, Z., Wustrow, 1575 E., and J. A. Halderman, "Mining Your Ps and Qs: Detection 1576 of Widespread Weak Keys in Network Devices", August 2012, 1577 . 1580 [NIST.SP.800-90Ar1] 1581 Barker, Elaine B. and John M. Kelsey, "Recommendation for 1582 Random Number Generation Using Deterministic Random Bit 1583 Generators", DOI 10.6028/NIST.SP.800-90Ar1, NIST NIST SP 1584 800-90Ar1, June 2015, 1585 . 1588 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1589 "Randomness Requirements for Security", BCP 106, RFC 4086, 1590 DOI 10.17487/RFC4086, June 2005, 1591 . 1593 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., 1594 and M. Scott, "PKCS #12: Personal Information Exchange 1595 Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, 1596 . 1598 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1599 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1600 . 1602 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1603 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1604 DOI 10.17487/RFC8407, October 2018, 1605 . 1607 [RFC8808] Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for 1608 Factory Default Settings", RFC 8808, DOI 10.17487/RFC8808, 1609 August 2020, . 1611 [Std-802.1AR-2018] 1612 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 1613 metropolitan area networks - Secure Device Identity", 14 1614 June 2018, 1615 . 1617 Acknowledgements 1619 The authors would like to thank for following for lively discussions 1620 on list and in the halls (ordered by first name): Benjamin Kaduk, 1621 David von Oheimb, Dan Romascanu, Eric Vyncke, Hendrik Brockhaus, Guy 1622 Fedorkow, Joe Clarke, Meral Shirazipour, Murray Kucherawy, Rich Salz, 1623 Rob Wilton, Roman Danyliw, Qin Wu, Yaron Sheffer, and Zaheduzzaman 1624 Sarkar. 1626 Contributors 1628 Special thanks go to David von Oheimb and Hendrik Brockhaus for 1629 helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes. 1631 Authors' Addresses 1633 Kent Watsen 1634 Watsen Networks 1636 Email: kent+ietf@watsen.net 1638 Russ Housley 1639 Vigil Security, LLC 1641 Email: housley@vigilsec.com 1643 Sean Turner 1644 sn3rd 1646 Email: sean@sn3rd.com