idnits 2.17.1 draft-ietf-netconf-sztp-csr-14.txt: -(1541): 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: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (2 March 2022) is 779 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 (-34) 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 ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-23 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-16 Summary: 2 errors (**), 0 flaws (~~), 11 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: 3 September 2022 S. Turner 7 sn3rd 8 2 March 2022 10 Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch 11 Provisioning (SZTP) Bootstrapping Request 12 draft-ietf-netconf-sztp-csr-14 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-03-02 --> 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 3 September 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-03-02.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-03-02 { 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-03-02.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-03-02 { 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 ir, cr, kur, or p10cr structure 836 defined in 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 an ir, 1138 cr, kur, or p10cr CHOICE of type CertificationRequest. 1139 It is signed with the initial device identity 1140 certificate's private key. The extraCerts element 1141 contains the initial device identity certificate, 1142 optionally followed by its certificate chain excluding 1143 the trust anchor. 1145 For asymmetric key-based origin authentication based 1146 on the initial device identity certificate's private 1147 key that signs the encapsulated CSR signed by the local 1148 device identity certificate's private key, PKIMessages 1149 contains one PKIMessage with the header, body, and 1150 protection elements, and SHOULD contain the extraCerts 1151 element. The header element contains the pvno, sender, 1152 recipient, protectionAlg, and optionally senderKID 1153 elements. The pvno contains cmp2000, the sender 1154 contains the subject of the initial device identity 1155 certificate, the protectionAlg contains the 1156 AlgorithmIdentifier of the used signature algorithm, 1157 and the senderKID contains the subject key identifier 1158 of the initial device identity certificate. The body 1159 element contains an ir, cr, kur, or p10cr CHOICE of 1160 type CertificationRequest. It is signed with the local 1161 device identity certificate's private key. The 1162 protection element contains the digital signature 1163 generated with the initial device identity 1164 certificate's private key. The extraCerts element 1165 contains the initial device identity certificate, 1166 optionally followed by its certificate chain excluding 1167 the trust anchor. 1169 For shared secret-based origin authentication of a 1170 CSR signed by the local device identity certificate's 1171 private key, PKIMessages contains one PKIMessage with 1172 the header, body, and protection element, and no 1173 extraCerts element. The header element contains the 1174 pvno, sender, recipient, protectionAlg, and senderKID 1175 elements. The pvno contains cmp2000, the protectionAlg 1176 contains the AlgorithmIdentifier of the used MAC 1177 algorithm, and the senderKID contains a reference the 1178 recipient can use to identify the shared secret. The 1179 body element contains an ir, cr, kur, or p10cr CHOICE 1180 of type CertificationRequest. It is signed with the 1181 local device identity certificate's private key. The 1182 protection element contains the MAC value generated 1183 with the shared secret."; 1184 reference 1185 "RFC 4210: 1186 Internet X.509 Public Key Infrastructure 1187 Certificate Management Protocol (CMP) 1188 ITU-T X.690: 1189 Information technology - ASN.1 encoding rules: 1190 Specification of Basic Encoding Rules (BER), 1191 Canonical Encoding Rules (CER) and Distinguished 1192 Encoding Rules (DER)."; 1193 } 1194 } 1195 } 1196 } 1198 } 1200 1202 4. Security Considerations 1204 This document builds on top of the solution presented in [RFC8572] 1205 and therefore all the Security Considerations discussed in RFC 8572 1206 apply here as well. 1208 For the various CSR formats, when using PKCS#10, the security 1209 considerations in [RFC2986] apply, when using CMP, the security 1210 considerations in [RFC4210] apply and, when using CMC, the security 1211 considerations in [RFC5272] apply. 1213 For the various authentication mechanisms, when using TLS-level 1214 authentication, the security considerations in [RFC8446] apply and, 1215 when using HTTP-level authentication, the security considerations in 1216 [RFC7235] apply. 1218 4.1. SZTP-Client Considerations 1220 4.1.1. Ensuring the Integrity of Asymmetric Private Keys 1222 The private key the SZTP-client uses for the dynamically-generated 1223 identity certificate MUST be protected from inadvertent disclosure in 1224 order to prevent identity fraud. 1226 The security of this private key is essential in order to ensure the 1227 associated identity certificate can be used to authenticate the 1228 device it is issued to. 1230 It is RECOMMENDED that devices are manufactured with an HSM (hardware 1231 security module), such as a TPM (trusted platform module), to 1232 generate and contain the private key within the security perimeter of 1233 the HSM. In such cases, the private key, and its associated 1234 certificates, MAY have long validity periods. 1236 In cases where the SZTP-client does not possess an HSM, or is unable 1237 to use an HSM to protect the private key, it is RECOMMENDED to 1238 periodically reset the private key (and associated identity 1239 certificates) in order to minimize the lifetime of unprotected 1240 private keys. For instance, an NMS controller/orchestrator 1241 application could periodically prompt the SZTP-client to generate a 1242 new private key and provide a certificate signing request (CSR) or, 1243 alternatively, push both the key and an identity certificate to the 1244 SZTP-client using, e.g., a PKCS #12 message [RFC7292]. In another 1245 example, the SZTP-client could be configured to periodically reset 1246 the configuration to its factory default, thus causing removal of the 1247 private key and associated identity certificates and re-execution of 1248 the SZTP protocol. 1250 4.1.2. Reuse of a Manufacturer-generated Private Key 1252 It is RECOMMENDED that a new private key is generated for each CSR 1253 described in this document. 1255 Implementations must randomly generate nonces and private keys. The 1256 use of inadequate pseudo-random number generators (PRNGs) to generate 1257 cryptographic keys can result in little or no security. An attacker 1258 may find it much easier to reproduce the PRNG environment that 1259 produced the keys, searching the resulting small set of 1260 possibilities, rather than brute force searching the whole key space. 1261 As an example of predictable random numbers see CVE-2008-0166 1262 [CVE-2008-0166], and some consequences of low-entropy random numbers 1263 are discussed in Mining Your Ps and Qs [MiningPsQs]. The generation 1264 of quality random numbers is difficult. [ISO.20543-2019], 1265 [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and 1266 others offer valuable guidance in this area. 1268 This private key SHOULD be protected as well as the built-in private 1269 key associated with the SZTP-client's initial device identity 1270 certificate (e.g., the IDevID, from [Std-802.1AR-2018]). 1272 In cases where it is not possible to generate a new private key that 1273 is protected as well as the built-in private key, it is RECOMMENDED 1274 to reuse the built-in private key rather than generate a new private 1275 key that is not as well protected. 1277 4.1.3. Replay Attack Protection 1279 This RFC enables an SZTP-client to announce an ability to generate a 1280 new key to use for its CSR. 1282 When the SZTP-server responds with a request for the SZTP-client to 1283 generate a new key, it is essential that the SZTP-client actually 1284 generates a new key. 1286 Generating a new key each time enables the random bytes used to 1287 create the key to also serve the dual-purpose of acting like a 1288 "nonce" used in other mechanisms to detect replay attacks. 1290 When a fresh public/private key pair is generated for the request, 1291 confirmation to the SZTP-client that the response has not been 1292 replayed is enabled by the SZTP-client's fresh public key appearing 1293 in the signed certificate provided by the SZTP-server. 1295 When a public/private key pair associated with the manufacturer- 1296 generated identity certificate (e.g., IDevID) is used for the 1297 request, there may not be confirmation to the SZTP-client that the 1298 response has not been replayed; however, the worst case result is a 1299 lost certificate that is associated to the private key known only to 1300 the SZTP-client. Protection of the private-key information is vital 1301 to public-key cryptography. Disclosure of the private-key material 1302 to another entity can lead to masquerades. 1304 4.1.4. Connecting to an Untrusted Bootstrap Server 1306 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1307 by blindly authenticating the SZTP-server's TLS end-entity 1308 certificate. 1310 As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- 1311 client MUST assert that the bootstrapping data returned is signed, if 1312 the SZTP-client is to trust it. 1314 However, the HTTP error message used in this document cannot be 1315 signed data, as described in RFC 8572. 1317 Therefore, the solution presented in this document cannot be used 1318 when the SZTP-client connects to an untrusted SZTP-server. 1320 Consistent with the recommendation presented in Section 9.6 of 1321 [RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input 1322 parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass 1323 instead the "signed-data-preferred" input parameter, as discussed in 1324 Appendix B of [RFC8572]. 1326 4.1.5. Selecting the Best Origin Authentication Mechanism 1328 The origin of the CSR must be verified before a certificate is 1329 issued. 1331 When generating a new key, it is important that the SZTP-client be 1332 able to provide additional proof that it was the entity that 1333 generated the key. 1335 The CMP and CMC certificate request formats defined in this document 1336 support origin authentication. A raw PKCS#10 CSR does not support 1337 origin authentication. 1339 The CMP and CMC request formats support origin authentication using 1340 both PKI and shared secret. 1342 Typically, only one possible origin authentication mechanism can 1343 possibly be used but, in the case that the SZTP-client authenticates 1344 itself using both TLS-level (e.g., IDevID) and HTTP-level credentials 1345 (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the 1346 SZTP-client may need to choose between the two options. 1348 In the case that the SZTP-client must choose between an asymmetric 1349 key option versus a shared secret for origin authentication, it is 1350 RECOMMENDED that the SZTP-client choose using the asymmetric key. 1352 4.1.6. Clearing the Private Key and Associated Certificate 1354 Unlike a manufacturer-generated identity certificate (e.g., IDevID), 1355 the deployment-generated identity certificate (e.g., LDevID) and the 1356 associated private key (assuming a new private key was generated for 1357 the purpose), are considered user data and SHOULD be cleared whenever 1358 the SZTP-client is reset to its factory default state, such as by the 1359 "factory-reset" RPC defined in [RFC8808]. 1361 4.2. SZTP-Server Considerations 1363 4.2.1. Verifying Proof of Possession 1365 Regardless if using a new asymmetric key or the bootstrapping 1366 device's manufacturer-generated key (e.g., the IDevID key), the 1367 public key is placed in the CSR and the CSR is signed by that private 1368 key. Proof-of-possession of the private key is verified by ensuring 1369 the signature over the CSR using the public key placed in the CSR. 1371 4.2.2. Verifying Proof of Origin 1373 When the bootstrapping device's manufacturer-generated private key 1374 (e.g., the IDevID key) is reused for the CSR, proof-of-origin is 1375 verified by validating the IDevID-issuer cert and ensuring that the 1376 CSR uses the same key pair. 1378 When the bootstrapping device's manufacturer-generated private key 1379 (e.g., an IDevID key from IEEE 802.1AR) is reused for the CSR, proof- 1380 of-origin is verified by validating the IDevID certification path and 1381 ensuring that the CSR uses the same key pair. 1383 When a fresh asymmetric key is used with the CMP or CMC formats, the 1384 authentication is part of the protocols, which could employ either 1385 the manufacturer-generated private key or a shared secret. In 1386 addition, CMP and CMC support processing by a RA before the request 1387 is passed to the CA, which allows for more robust handling of errors. 1389 4.2.3. Supporting SZTP-Clients that don't trust the SZTP-Server 1391 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1392 by blindly authenticating the SZTP-server's TLS end-entity 1393 certificate. 1395 As is recommended in Section 4.1.4 in this document, in such cases, 1396 SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. 1398 The reciprocal of this statement is that SZTP-servers, wanting to 1399 support SZTP-clients that don't trust them, SHOULD support the 1400 "signed-data-preferred" input parameter, as discussed in Appendix B 1401 of [RFC8572]. 1403 4.3. Security Considerations for the "ietf-sztp-csr" YANG Module 1405 The recommended format for documenting the Security Considerations 1406 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1407 this module only augments two input parameters into the "get- 1408 bootstrapping-data" RPC in [RFC8572], and therefore only needs to 1409 point to the relevant Security Considerations sections in that RFC. 1411 * Security considerations for the "get-bootstrapping-data" RPC are 1412 described in Section 9.16 of [RFC8572]. 1414 * Security considerations for the "input" parameters passed inside 1415 the "get-bootstrapping-data" RPC are described in Section 9.6 of 1416 [RFC8572]. 1418 4.4. Security Considerations for the "ietf-ztp-types" YANG Module 1420 The recommended format for documenting the Security Considerations 1421 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1422 this module does not define any protocol-accessible nodes (it only 1423 defines "identity" and "grouping" statements) and therefore there are 1424 no Security considerations to report. 1426 5. IANA Considerations 1428 5.1. The "IETF XML" Registry 1430 This document registers two URIs in the "ns" subregistry of the IETF 1431 XML Registry [RFC3688] maintained at 1432 https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. 1433 Following the format in [RFC3688], the following registrations are 1434 requested: 1436 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1437 Registrant Contact: The NETCONF WG of the IETF. 1438 XML: N/A, the requested URI is an XML namespace. 1440 URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1441 Registrant Contact: The NETCONF WG of the IETF. 1442 XML: N/A, the requested URI is an XML namespace. 1444 5.2. The "YANG Module Names" Registry 1446 This document registers two YANG modules in the YANG Module Names 1447 registry [RFC6020] maintained at https://www.iana.org/assignments/ 1448 yang-parameters/yang-parameters.xhtml. Following the format defined 1449 in [RFC6020], the below registrations are requested: 1451 name: ietf-sztp-csr 1452 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1453 prefix: sztp-csr 1454 reference: RFC XXXX 1456 name: ietf-ztp-types 1457 namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1458 prefix: ztp-types 1459 reference: RFC XXXX 1461 6. References 1463 6.1. Normative References 1465 [I-D.ietf-netconf-crypto-types] 1466 Watsen, K., "YANG Data Types and Groupings for 1467 Cryptography", Work in Progress, Internet-Draft, draft- 1468 ietf-netconf-crypto-types-21, 14 September 2021, 1469 . 1472 [ITU.X690.2015] 1473 International Telecommunication Union, "Information 1474 Technology - ASN.1 encoding rules: Specification of Basic 1475 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1476 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1477 X.690, ISO/IEC 8825-1, August 2015, 1478 . 1480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1481 Requirement Levels", BCP 14, RFC 2119, 1482 DOI 10.17487/RFC2119, March 1997, 1483 . 1485 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1486 Request Syntax Specification Version 1.7", RFC 2986, 1487 DOI 10.17487/RFC2986, November 2000, 1488 . 1490 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1491 DOI 10.17487/RFC3688, January 2004, 1492 . 1494 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1495 "Internet X.509 Public Key Infrastructure Certificate 1496 Management Protocol (CMP)", RFC 4210, 1497 DOI 10.17487/RFC4210, September 2005, 1498 . 1500 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1501 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 1502 . 1504 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1505 the Network Configuration Protocol (NETCONF)", RFC 6020, 1506 DOI 10.17487/RFC6020, October 2010, 1507 . 1509 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1510 Protocol (HTTP/1.1): Authentication", RFC 7235, 1511 DOI 10.17487/RFC7235, June 2014, 1512 . 1514 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1515 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1516 . 1518 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1519 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1520 . 1522 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1523 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1524 May 2017, . 1526 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1527 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1528 . 1530 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1531 Touch Provisioning (SZTP)", RFC 8572, 1532 DOI 10.17487/RFC8572, April 2019, 1533 . 1535 [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data 1536 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1537 June 2020, . 1539 6.2. Informative References 1541 [AIS31] Bundesamt für Sicherheit in der Informationstechnik (BSI), 1542 Killmann, W., and W. Schindler, "A proposal for: 1543 Functionality classes for random number generators, 1544 version 2.0", 18 September 2011, 1545 . 1549 [CVE-2008-0166] 1550 National Institute of Science and Technology (NIST), 1551 "National Vulnerability Database - CVE-2008-0166", 13 May 1552 2008, . 1554 [I-D.ietf-netconf-keystore] 1555 Watsen, K., "A YANG Data Model for a Keystore", Work in 1556 Progress, Internet-Draft, draft-ietf-netconf-keystore-23, 1557 14 December 2021, . 1560 [I-D.ietf-netconf-trust-anchors] 1561 Watsen, K., "A YANG Data Model for a Truststore", Work in 1562 Progress, Internet-Draft, draft-ietf-netconf-trust- 1563 anchors-16, 14 December 2021, 1564 . 1567 [ISO.20543-2019] 1568 International Organization for Standardization (ISO), 1569 "Information technology -- Security techniques -- Test and 1570 analysis methods for random bit generators within ISO/IEC 1571 19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019, 1572 October 2019. 1574 [MiningPsQs] 1575 Security'12: Proceedings of the 21st USENIX conference on 1576 Security symposium, Heninger, N., Durumeric, Z., Wustrow, 1577 E., and J. A. Halderman, "Mining Your Ps and Qs: Detection 1578 of Widespread Weak Keys in Network Devices", August 2012, 1579 . 1582 [NIST.SP.800-90Ar1] 1583 Barker, Elaine B. and John M. Kelsey, "Recommendation for 1584 Random Number Generation Using Deterministic Random Bit 1585 Generators", DOI 10.6028/NIST.SP.800-90Ar1, NIST NIST SP 1586 800-90Ar1, June 2015, 1587 . 1590 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1591 "Randomness Requirements for Security", BCP 106, RFC 4086, 1592 DOI 10.17487/RFC4086, June 2005, 1593 . 1595 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., 1596 and M. Scott, "PKCS #12: Personal Information Exchange 1597 Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, 1598 . 1600 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1601 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1602 . 1604 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1605 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1606 DOI 10.17487/RFC8407, October 2018, 1607 . 1609 [RFC8808] Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for 1610 Factory Default Settings", RFC 8808, DOI 10.17487/RFC8808, 1611 August 2020, . 1613 [Std-802.1AR-2018] 1614 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 1615 metropolitan area networks - Secure Device Identity", 14 1616 June 2018, 1617 . 1619 Acknowledgements 1621 The authors would like to thank for following for lively discussions 1622 on list and in the halls (ordered by first name): Benjamin Kaduk, 1623 David von Oheimb, Dan Romascanu, Eric Vyncke, Hendrik Brockhaus, Guy 1624 Fedorkow, Joe Clarke, Meral Shirazipour, Murray Kucherawy, Rich Salz, 1625 Rob Wilton, Roman Danyliw, Qin Wu, Yaron Sheffer, and Zaheduzzaman 1626 Sarkar. 1628 Contributors 1630 Special thanks go to David von Oheimb and Hendrik Brockhaus for 1631 helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes. 1633 Authors' Addresses 1635 Kent Watsen 1636 Watsen Networks 1637 Email: kent+ietf@watsen.net 1639 Russ Housley 1640 Vigil Security, LLC 1641 Email: housley@vigilsec.com 1643 Sean Turner 1644 sn3rd 1645 Email: sean@sn3rd.com