idnits 2.17.00 (12 Aug 2021) /tmp/idnits9058/draft-ietf-netconf-sztp-csr-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance 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 223 has weird spacing: '...ntifier bin...' == Line 226 has weird spacing: '...ntifier ide...' == Line 316 has weird spacing: '...rmation cms...' == Line 335 has weird spacing: '...ntifier bin...' == Line 338 has weird spacing: '...ntifier ide...' == (2 more instances...) -- The document date (8 November 2021) is 193 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-22 == Outdated reference: A later version (-17) exists of draft-ietf-netconf-trust-anchors-15 == Outdated reference: draft-ietf-netmod-factory-default has been published as RFC 8808 Summary: 1 error (**), 0 flaws (~~), 12 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: 12 May 2022 S. Turner 7 sn3rd 8 8 November 2021 10 Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch 11 Provisioning (SZTP) Bootstrapping Request 12 draft-ietf-netconf-sztp-csr-11 14 Abstract 16 This draft extends the "get-bootstrapping-data" RPC defined in RFC 17 8572 to include an optional certificate signing request (CSR), 18 enabling a bootstrapping device to additionally obtain an identity 19 certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the 20 "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 * 2021-11-08 --> 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 * I-D.ietf-netmod-factory-default 54 Status of This Memo 56 This Internet-Draft is submitted in full conformance with the 57 provisions of BCP 78 and BCP 79. 59 Internet-Drafts are working documents of the Internet Engineering 60 Task Force (IETF). Note that other groups may also distribute 61 working documents as Internet-Drafts. The list of current Internet- 62 Drafts is at https://datatracker.ietf.org/drafts/current/. 64 Internet-Drafts are draft documents valid for a maximum of six months 65 and may be updated, replaced, or obsoleted by other documents at any 66 time. It is inappropriate to use Internet-Drafts as reference 67 material or to cite them other than as "work in progress." 69 This Internet-Draft will expire on 12 May 2022. 71 Copyright Notice 73 Copyright (c) 2021 IETF Trust and the persons identified as the 74 document authors. All rights reserved. 76 This document is subject to BCP 78 and the IETF Trust's Legal 77 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 78 license-info) in effect on the date of publication of this document. 79 Please review these documents carefully, as they describe your rights 80 and restrictions with respect to this document. Code Components 81 extracted from this document must include Simplified BSD License text 82 as described in Section 4.e of the Trust Legal Provisions and are 83 provided without warranty as described in the Simplified BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 88 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 89 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 90 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 91 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 92 2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 93 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 94 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 95 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 97 3. The "ietf-ztp-types" Module . . . . . . . . . . . . . . . . . 17 98 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 17 99 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18 100 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 101 4.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 27 102 4.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 27 103 4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 27 104 4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 28 105 4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 28 106 4.1.5. Selecting the Best Origin Authentication Mechanism . 29 107 4.1.6. Clearing the Private Key and Associated 108 Certificate . . . . . . . . . . . . . . . . . . . . . 29 109 4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 29 110 4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 30 111 4.2.2. Verifying Proof of Origin . . . . . . . . . . . . . . 30 112 4.2.3. Supporting SZTP-Clients that don't trust the 113 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 30 114 4.3. Security Considerations for the "ietf-sztp-csr" YANG 115 Module . . . . . . . . . . . . . . . . . . . . . . . . . 30 116 4.4. Security Considerations for the "ietf-ztp-types" YANG 117 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31 118 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 119 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 31 120 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 31 121 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 122 6.1. Normative References . . . . . . . . . . . . . . . . . . 32 123 6.2. Informative References . . . . . . . . . . . . . . . . . 33 124 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 125 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 128 1. Introduction 130 1.1. Overview 132 This draft extends the "get-bootstrapping-data" RPC defined in 133 [RFC8572] to include an optional certificate signing request (CSR) 134 [RFC2986], enabling a bootstrapping device to additionally obtain an 135 identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of 136 the "onboarding information" response provided in the RPC-reply. 138 The ability to provision an identity certificate that is purpose- 139 built for a production environment during the bootstrapping process 140 removes reliance on the manufacturer CA, and it also enables the 141 bootstraped device to join the production environment with an 142 appropriate identity and other attributes in its LDevID certificate. 144 Two YANG [RFC7950] modules are defined. The "ietf-ztp-types" module 145 defines three YANG groupings for the various messages defined in this 146 document. The "ietf-sztp-csr" module augments two groupings into the 147 "get-bootstrapping-data" RPC and defines a YANG Data Structure 148 [RFC8791] around the third grouping. 150 1.2. Terminology 152 This document uses the following terms from [RFC8572]: 154 * Bootstrap Server 155 * Bootstrapping Data 156 * Conveyed Information 157 * Device 158 * Manufacturer 159 * Onboarding Information 160 * Signed Data 162 This document defines the following new terms: 164 SZTP-client The term "SZTP-client" refers to a "device" that is 165 using a "bootstrap server" as a source of "bootstrapping data". 167 SZTP-server The term "SZTP-server" is an alternative term for 168 "bootstrap server" that is symmetric with the "SZTP-client" term. 170 1.3. Requirements Language 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 1.4. Conventions 180 Various examples used in this document use a placeholder value for 181 binary data that has been base64 encoded (e.g., "BASE64VALUE="). 182 This placeholder value is used as real base64 encoded structures are 183 often many lines long and hence distracting to the example being 184 presented. 186 2. The "ietf-sztp-csr" Module 188 The "ietf-sztp-csr" module is a YANG 1.1 [RFC7950] module that 189 augments the "ietf-sztp-bootstrap-server" module defined in [RFC8572] 190 and defines a YANG "structure" that is to be conveyed in the "error- 191 info" node defined in Section 7.1 of [RFC8040]. 193 2.1. Data Model Overview 195 The following tree diagram [RFC8340] illustrates the "ietf-sztp-csr" 196 module. 198 module: ietf-sztp-csr 200 augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: 201 +---w (msg-type)? 202 +--:(csr-support) 203 | +---w csr-support 204 | +---w key-generation! 205 | | +---w supported-algorithms 206 | | +---w algorithm-identifier* binary 207 | +---w csr-generation 208 | +---w supported-formats 209 | +---w format-identifier* identityref 210 +--:(csr) 211 +---w (csr-type) 212 +--:(p10-csr) 213 | +---w p10-csr? ct:csr 214 +--:(cmc-csr) 215 | +---w cmc-csr? binary 216 +--:(cmp-csr) 217 +---w cmp-csr? binary 218 module: ietf-sztp-csr 220 structure: csr-request 221 +--ro key-generation! 222 | +--ro selected-algorithm 223 | +--ro algorithm-identifier binary 224 +--ro csr-generation 225 | +--ro selected-format 226 | +--ro format-identifier identityref 227 +--ro cert-req-info? ct:csr-info 229 augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: 230 +---w (msg-type)? 231 +--:(csr-support) 232 | +---w csr-support 233 | +---w key-generation! 234 | | +---w supported-algorithms 235 | | +---w algorithm-identifier* binary 236 | +---w csr-generation 237 | +---w supported-formats 238 | +---w format-identifier* identityref 239 +--:(csr) 240 +---w (csr-type) 241 +--:(p10-csr) 242 | +---w p10-csr? ct:csr 243 +--:(cmc-csr) 244 | +---w cmc-csr? binary 245 +--:(cmp-csr) 246 +---w cmp-csr? binary 248 The augmentation defines two kinds of parameters that an SZTP-client 249 can send to an SZTP-server. The YANG structure defines one 250 collection of parameters that an SZTP-server can send to an SZTP- 251 client. 253 In the order of their intended use: 255 * The "csr-support" node is used by the SZTP-client to signal to the 256 SZTP-server that it supports the ability the generate CSRs. This 257 parameter conveys if the SZTP-client is able to generate an new 258 asymmetric key and, if so, which key algorithms it supports, as 259 well as conveys what kinds of CSR structures the SZTP-client is 260 able to generate. 262 * The "csr-request" structure is used by the SZTP-server to request 263 the SZTP-client to generate a CSR. This structure is used to 264 select the key algorithm the SZTP-client should use to generate a 265 new asymmetric key, if supported, the kind of CSR structure the 266 SZTP-client should generate and, optionally, the content for the 267 CSR itself. 269 * The various "csr" nodes are used by the SZTP-client to communicate 270 a CSR to the SZTP-server. 272 | No data model is defined enabling an SZTP-server to communicate 273 | the signed certificate to the SZTP-client. How to do this is 274 | discussed in Section 2.2. 276 To further illustrate how the augmentation and structure defined by 277 the "ietf-sztp-csr" module are used, below are two additional tree 278 diagrams showing these nodes placed where they are used. 280 The following tree diagram [RFC8340] illustrates SZTP's "get- 281 bootstrapping-data" RPC with the augmentation in place. 283 =============== NOTE: '\' line wrapping per RFC 8792 ================ 285 module: ietf-sztp-bootstrap-server 287 rpcs: 288 +---x get-bootstrapping-data 289 +---w input 290 | +---w signed-data-preferred? empty 291 | +---w hw-model? string 292 | +---w os-name? string 293 | +---w os-version? string 294 | +---w nonce? binary 295 | +---w (sztp-csr:msg-type)? 296 | +--:(sztp-csr:csr-support) 297 | | +---w sztp-csr:csr-support 298 | | +---w sztp-csr:key-generation! 299 | | | +---w sztp-csr:supported-algorithms 300 | | | +---w sztp-csr:algorithm-identifier* bina\ 301 ry 302 | | +---w sztp-csr:csr-generation 303 | | +---w sztp-csr:supported-formats 304 | | +---w sztp-csr:format-identifier* identit\ 305 yref 306 | +--:(sztp-csr:csr) 307 | +---w (sztp-csr:csr-type) 308 | +--:(sztp-csr:p10-csr) 309 | | +---w sztp-csr:p10-csr? ct:csr 310 | +--:(sztp-csr:cmc-csr) 311 | | +---w sztp-csr:cmc-csr? binary 312 | +--:(sztp-csr:cmp-csr) 313 | +---w sztp-csr:cmp-csr? binary 314 +--ro output 315 +--ro reporting-level? enumeration {onboarding-server}? 316 +--ro conveyed-information cms 317 +--ro owner-certificate? cms 318 +--ro ownership-voucher? cms 320 The following tree diagram [RFC8340] illustrates RESTCONF's "errors" 321 RPC-reply message with the "csr-request" structure in place. 323 module: ietf-restconf 324 +--ro errors 325 +--ro error* [] 326 +--ro error-type enumeration 327 +--ro error-tag string 328 +--ro error-app-tag? string 329 +--ro error-path? instance-identifier 330 +--ro error-message? string 331 +--ro error-info 332 +--ro csr-request 333 +--ro key-generation! 334 | +--ro selected-algorithm 335 | +--ro algorithm-identifier binary 336 +--ro csr-generation 337 | +--ro selected-format 338 | +--ro format-identifier identityref 339 +--ro cert-req-info? ct:csr-info 341 2.2. Example Usage 343 | The examples below are encoded using JSON, but they could 344 | equally well be encoded using XML, as is supported by SZTP. 346 An SZTP-client implementing this specification would signal to the 347 bootstrap server its willingness to generate a CSR by including the 348 "csr-support" node in its "get-bootstrapping-data" RPC, as 349 illustrated below. 351 REQUEST 352 =============== NOTE: '\' line wrapping per RFC 8792 ================ 354 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 355 ng-data HTTP/1.1 356 HOST: example.com 357 Content-Type: application/yang.data+json 359 { 360 "ietf-sztp-bootstrap-server:input" : { 361 "hw-model": "model-x", 362 "os-name": "vendor-os", 363 "os-version": "17.3R2.1", 364 "nonce": "extralongbase64encodedvalue=", 365 "ietf-sztp-csr:csr-support": { 366 "key-generation": { 367 "supported-algorithms": { 368 "algorithm-identifier": [ 369 "BASE64VALUE1", 370 "BASE64VALUE2", 371 "BASE64VALUE3" 372 ] 373 } 374 }, 375 "csr-generation": { 376 "supported-formats": { 377 "format-identifier": [ 378 "ietf-ztp-types:p10-csr", 379 "ietf-ztp-types:cmc-csr", 380 "ietf-ztp-types:cmp-csr" 381 ] 382 } 383 } 384 } 385 } 386 } 388 Assuming the SZTP-server wishes to prompt the SZTP-client to provide 389 a CSR, then it would respond with an HTTP 400 Bad Request error code: 391 RESPONSE 392 HTTP/1.1 400 Bad Request 393 Date: Sat, 31 Oct 2015 17:02:40 GMT 394 Server: example-server 395 Content-Type: application/yang.data+json 397 { 398 "ietf-restconf:errors" : { 399 "error" : [ 400 { 401 "error-type": "application", 402 "error-tag": "missing-attribute", 403 "error-message": "Missing input parameter", 404 "error-info": { 405 "ietf-sztp-csr:csr-request": { 406 "key-generation": { 407 "selected-algorithm": { 408 "algorithm-identifier": "BASE64VALUE=" 409 } 410 }, 411 "csr-generation": { 412 "selected-format": { 413 "format-identifier": "ietf-ztp-types:p10-csr" 414 } 415 }, 416 "cert-req-info": "BASE64VALUE=" 417 } 418 } 419 } 420 ] 421 } 422 } 424 Upon being prompted to provide a CSR, the SZTP-client would POST 425 another "get-bootstrapping-data" request, but this time including one 426 of the "csr" nodes to convey its CSR to the SZTP-server: 428 REQUEST 429 =============== NOTE: '\' line wrapping per RFC 8792 ================ 431 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 432 ng-data HTTP/1.1 433 HOST: example.com 434 Content-Type: application/yang.data+json 436 { 437 "ietf-sztp-bootstrap-server:input" : { 438 "hw-model": "model-x", 439 "os-name": "vendor-os", 440 "os-version": "17.3R2.1", 441 "nonce": "extralongbase64encodedvalue=", 442 "ietf-sztp-csr:p10-csr": "BASE64VALUE=" 443 } 444 } 446 At this point, it is expected that the SZTP-server, perhaps in 447 conjunction with other systems, such as a backend CA or RA, will 448 validate the CSR's origin and proof-of-possession and, assuming the 449 CSR is approved, issue a signed certificate for the bootstrapping 450 device. 452 The SZTP-server responds with "onboarding-information" (encoded 453 inside the "conveyed-information" node, shown below) containing a 454 signed identity certificate for the CSR provided by the SZTP-client: 456 RESPONSE 458 HTTP/1.1 200 OK 459 Date: Sat, 31 Oct 2015 17:02:40 GMT 460 Server: example-server 461 Content-Type: application/yang.data+json 463 { 464 "ietf-sztp-bootstrap-server:output" : { 465 "reporting-level": "verbose", 466 "conveyed-information": "BASE64VALUE=" 467 } 468 } 470 How the signed certificate is conveyed inside the onboarding 471 information is outside the scope of this document. Some 472 implementations may choose to convey it inside a script (e.g., SZTP's 473 "pre-configuration-script"), while other implementations may choose 474 to convey it inside the SZTP "configuration" node. SZTP onboarding 475 information is described in Section 2.2 of [RFC8572]. 477 Following are two examples of conveying the signed certificate inside 478 the "configuration" node. Both examples assume that the SZTP-client 479 understands the "ietf-keystore" module defined in 480 [I-D.ietf-netconf-keystore]. 482 This first example illustrates the case where the signed certificate 483 is for the same asymmetric key used by the SZTP-client's 484 manufacturer-generated identity certificate (e.g., an IDevID, from 485 [Std-802.1AR-2018]). As such, the configuration needs to associate 486 the newly signed certificate with the existing asymmetric key: 488 =============== NOTE: '\' line wrapping per RFC 8792 ================ 490 { 491 "ietf-keystore:keystore": { 492 "asymmetric-keys": { 493 "asymmetric-key": [ 494 { 495 "name": "Manufacturer-Generated Hidden Key", 496 "public-key-format": "ietf-crypto-types:subject-public-key\ 497 -info-format", 498 "public-key": "BASE64VALUE=", 499 "hidden-private-key": [null], 500 "certificates": { 501 "certificate": [ 502 { 503 "name": "Manufacturer-Generated IDevID Cert", 504 "cert-data": "BASE64VALUE=" 505 }, 506 { 507 "name": "Newly-Generated LDevID Cert", 508 "cert-data": "BASE64VALUE=" 509 } 510 ] 511 } 512 } 513 ] 514 } 515 } 516 } 518 This second example illustrates the case where the signed certificate 519 is for a newly generated asymmetric key. As such, the configuration 520 needs to associate the newly signed certificate with the newly 521 generated asymmetric key: 523 =============== NOTE: '\' line wrapping per RFC 8792 ================ 525 { 526 "ietf-keystore:keystore": { 527 "asymmetric-keys": { 528 "asymmetric-key": [ 529 { 530 "name": "Manufacturer-Generated Hidden Key", 531 "public-key-format": "ietf-crypto-types:subject-public-key\ 532 -info-format", 533 "public-key": "BASE64VALUE=", 534 "hidden-private-key": [null], 535 "certificates": { 536 "certificate": [ 537 { 538 "name": "Manufacturer-Generated IDevID Cert", 539 "cert-data": "BASE64VALUE=" 540 } 541 ] 542 } 543 }, 544 { 545 "name": "Newly-Generated Hidden Key", 546 "public-key-format": "ietf-crypto-types:subject-public-key\ 547 -info-format", 548 "public-key": "BASE64VALUE=", 549 "hidden-private-key": [null], 550 "certificates": { 551 "certificate": [ 552 { 553 "name": "Newly-Generated LDevID Cert", 554 "cert-data": "BASE64VALUE=" 555 } 556 ] 557 } 558 } 559 ] 560 } 561 } 562 } 564 In addition to configuring the signed certificate, it is often 565 necessary to also configure the Issuer's signing certificate so that 566 the device (i.e., STZP-client) can authenticate certificates 567 presented by peer devices signed by the same issuer as its own. 568 While outside the scope of this document, one way to do this would be 569 to use the "ietf-truststore" module defined in 570 [I-D.ietf-netconf-trust-anchors]. 572 2.3. YANG Module 574 This module augments an RPC defined in [RFC8572]. The module uses a 575 data types and groupings defined in [RFC8572], [RFC8791], and 576 [I-D.ietf-netconf-crypto-types]. The module has additional normative 577 references to [RFC2986], [RFC5272], [RFC4210], and [ITU.X690.2015], 578 and an informative reference to [Std-802.1AR-2018]. 580 file "ietf-sztp-csr@2021-11-08.yang" 582 module ietf-sztp-csr { 583 yang-version 1.1; 584 namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; 585 prefix sztp-csr; 587 import ietf-sztp-bootstrap-server { 588 prefix sztp-svr; 589 reference 590 "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 591 } 593 import ietf-yang-structure-ext { 594 prefix sx; 595 reference 596 "RFC 8791: YANG Data Structure Extensions"; 597 } 599 import ietf-ztp-types { 600 prefix zt; 601 reference 602 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 603 in a Secure Zero Touch Provisioning (SZTP) 604 Bootstrapping Request"; 605 } 607 organization 608 "IETF NETCONF (Network Configuration) Working Group"; 610 contact 611 "WG Web: http://tools.ietf.org/wg/netconf 612 WG List: 613 Authors: Kent Watsen 614 Russ Housley 615 Sean Turner "; 617 description 618 "This module augments the 'get-bootstrapping-data' RPC, 619 defined in the 'ietf-sztp-bootstrap-server' module from 620 SZTP (RFC 8572), enabling the SZTP-client to obtain a 621 signed identity certificate (e.g., an LDevID from IEEE 622 802.1AR) as part of the SZTP onboarding information 623 response. 625 Copyright (c) 2021 IETF Trust and the persons identified 626 as authors of the code. All rights reserved. 628 Redistribution and use in source and binary forms, with 629 or without modification, is permitted pursuant to, and 630 subject to the license terms contained in, the Simplified 631 BSD License set forth in Section 4.c of the IETF Trust's 632 Legal Provisions Relating to IETF Documents 633 (https://trustee.ietf.org/license-info). 635 This version of this YANG module is part of RFC XXXX 636 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 637 itself for full legal notices. 639 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 640 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 641 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 642 document are to be interpreted as described in BCP 14 643 (RFC 2119) (RFC 8174) when, and only when, they appear 644 in all capitals, as shown here."; 646 revision 2021-11-08 { 647 description 648 "Initial version"; 649 reference 650 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 651 in a Secure Zero Touch Provisioning (SZTP) 652 Bootstrapping Request"; 653 } 655 // Protocol-accessible nodes 657 augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { 658 description 659 "This augmentation adds the 'csr-support' and 'csr' nodes to 660 the SZTP (RFC 8572) 'get-bootstrapping-data' request message, 661 enabling the SZTP-client to obtain an identity certificate 662 (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding 663 information response provided by the SZTP-server. 665 The 'csr-support' node enables the SZTP-client to indicate 666 that it supports generating certificate signing requests 667 (CSRs), and to provide details around the CSRs it is able 668 to generate. 670 The 'csr' node enables the SZTP-client to relay a CSR to 671 the SZTP-server."; 672 reference 673 "IEEE 802.1AR: IEEE Standard for Local and metropolitan 674 area networks - Secure Device Identity 675 RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 676 choice msg-type { 677 description 678 "Messages are mutually exclusive."; 679 case csr-support { 680 description 681 "Indicates how the SZTP-client supports generating CSRs. 683 If present and a SZTP-server wishes to request the 684 SZTP-client generate a CSR, the SZTP-server MUST 685 respond with HTTP code 400 Bad Request with an 686 'ietf-restconf:errors' message having the 'error-tag' 687 value 'missing-attribute' and the 'error-info' node 688 containing the 'csr-request' structure described 689 in this module."; 690 uses zt:csr-support-grouping; 691 } 692 case csr { 693 description 694 "Provides the CSR generated by the SZTP-client. 696 When present, the SZTP-server SHOULD respond with 697 an SZTP onboarding information message containing 698 a signed certificate for the conveyed CSR. The 699 SZTP-server MAY alternatively respond with another 700 HTTP error containing another 'csr-request', in 701 which case the SZTP-client MUST invalidate the 702 previously generated CSR."; 703 uses zt:csr-grouping; 704 } 705 } 706 } 708 sx:structure csr-request { 709 description 710 "A YANG data structure, per RFC 8791, that specifies 711 details for the CSR that the ZTP-client is to generate."; 712 reference 713 "RFC 8791: YANG Data Structure Extensions"; 714 uses zt:csr-request-grouping; 715 } 717 } 719 721 3. The "ietf-ztp-types" Module 723 This section defines a YANG 1.1 [RFC7950] module that defines three 724 YANG groupings, one each for messages sent between a ZTP-client and 725 ZTP-server. This module is defines independently of the "ietf-sztp- 726 csr" module so that it's groupings may be used by bootstrapping 727 protocols other than SZTP [RFC8572]. 729 3.1. Data Model Overview 731 The following tree diagram [RFC8340] illustrates the three groupings 732 defined in the "ietf-ztp-types" module. 734 module: ietf-ztp-types 736 grouping csr-support-grouping 737 +-- csr-support 738 +-- key-generation! 739 | +-- supported-algorithms 740 | +-- algorithm-identifier* binary 741 +-- csr-generation 742 +-- supported-formats 743 +-- format-identifier* identityref 744 grouping csr-request-grouping 745 +-- key-generation! 746 | +-- selected-algorithm 747 | +-- algorithm-identifier binary 748 +-- csr-generation 749 | +-- selected-format 750 | +-- format-identifier identityref 751 +-- cert-req-info? ct:csr-info 752 grouping csr-grouping 753 +-- (csr-type) 754 +--:(p10-csr) 755 | +-- p10-csr? ct:csr 756 +--:(cmc-csr) 757 | +-- cmc-csr? binary 758 +--:(cmp-csr) 759 +-- cmp-csr? binary 761 3.2. YANG Module 763 This module uses a data types and groupings [RFC8791] and 764 [I-D.ietf-netconf-crypto-types]. The module has additional normative 765 references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015], 766 and an informative reference to [Std-802.1AR-2018]. 768 file "ietf-ztp-types@2021-11-08.yang" 770 module ietf-ztp-types { 771 yang-version 1.1; 772 namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types"; 773 prefix zt; 775 import ietf-crypto-types { 776 prefix ct; 777 reference 778 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 779 } 781 organization 782 "IETF NETCONF (Network Configuration) Working Group"; 784 contact 785 "WG Web: http://tools.ietf.org/wg/netconf 786 WG List: 787 Authors: Kent Watsen 788 Russ Housley 789 Sean Turner "; 791 description 792 "This module defines three groupings that enable 793 bootstrapping devices to 1) indicate if and how they 794 support generating CSRs, 2) obtain a request to 795 generate a CSR, and 3) communicate the requested CSR. 797 The terms 'IDevID' and 'LDevID' are used herein to 798 mean 'initial device identifier' and 'local device 799 identifer'. These terms are defined consistent with 800 the IEEE 802.1AR specification, though there is no 801 requirement that a ZTP-client's identity certificate 802 conform to IEEE 802.1AR. 804 Copyright (c) 2021 IETF Trust and the persons identified 805 as authors of the code. All rights reserved. 807 Redistribution and use in source and binary forms, with 808 or without modification, is permitted pursuant to, and 809 subject to the license terms contained in, the Simplified 810 BSD License set forth in Section 4.c of the IETF Trust's 811 Legal Provisions Relating to IETF Documents 812 (https://trustee.ietf.org/license-info). 814 This version of this YANG module is part of RFC XXXX 815 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 816 itself for full legal notices. 818 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 819 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 820 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 821 document are to be interpreted as described in BCP 14 822 (RFC 2119) (RFC 8174) when, and only when, they appear 823 in all capitals, as shown here."; 825 revision 2021-11-08 { 826 description 827 "Initial version"; 828 reference 829 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 830 in a Secure Zero Touch Provisioning (SZTP) 831 Bootstrapping Request"; 832 } 834 identity certificate-request-format { 835 description 836 "A base identity for the request formats supported 837 by the ZTP-client. 839 Additional derived identities MAY be defined by 840 future efforts."; 841 } 843 identity p10-csr { 844 base certificate-request-format; 845 description 846 "Indicates that the ZTP-client supports generating 847 requests using the 'CertificationRequest' structure 848 defined in RFC 2986."; 849 reference 850 "RFC 2986: PKCS #10: Certification Request Syntax 851 Specification Version 1.7"; 852 } 854 identity cmp-csr { 855 base certificate-request-format; 856 description 857 "Indicates that the ZTP-client supports generating 858 requests using a constrained version of the PKIMessage 859 containing a p10cr structure defined in RFC 4210."; 860 reference 861 "RFC 4210: Internet X.509 Public Key Infrastructure 862 Certificate Management Protocol (CMP)"; 863 } 865 identity cmc-csr { 866 base certificate-request-format; 867 description 868 "Indicates that the ZTP-client supports generating 869 requests using a constrained version of the 'Full 870 PKI Request' structure defined in RFC 5272."; 871 reference 872 "RFC 5272: Certificate Management over CMS (CMC)"; 873 } 875 // Protocol-accessible nodes 877 grouping csr-support-grouping { 878 description 879 "A grouping enabling use by other efforts."; 880 container csr-support { 881 description 882 "Enables a ZTP-client to indicate that it supports 883 generating certificate signing requests (CSRs) and 884 provides details about the CSRs it is able to 885 generate."; 886 container key-generation { 887 presence 888 "Indicates that the ZTP-client is capable of 889 generating a new asymmetric key pair. 891 If this node is not present, the ZTP-server MAY 892 request a CSR using the asymmetric key associated 893 with the device's existing identity certificate 894 (e.g., an IDevID from IEEE 802.1AR)."; 895 description 896 "Specifies details for the ZTP-client's ability to 897 generate a new asymmetric key pair."; 898 container supported-algorithms { 899 description 900 "A list of public key algorithms supported by the 901 ZTP-client for generating a new asymmetric key."; 902 leaf-list algorithm-identifier { 903 type binary; 904 min-elements 1; 905 description 906 "An AlgorithmIdentifier, as defined in RFC 2986, 907 encoded using ASN.1 distinguished encoding rules 908 (DER), as specified in ITU-T X.690."; 909 reference 910 "RFC 2986: PKCS #10: Certification Request Syntax 911 Specification Version 1.7 912 ITU-T X.690: 913 Information technology - ASN.1 encoding rules: 914 Specification of Basic Encoding Rules (BER), 915 Canonical Encoding Rules (CER) and Distinguished 916 Encoding Rules (DER)."; 917 } 918 } 919 } 920 container csr-generation { 921 description 922 "Specifies details for the ZTP-client's ability to 923 generate a certificate signing requests."; 924 container supported-formats { 925 description 926 "A list of certificate request formats supported 927 by the ZTP-client for generating a new key."; 928 leaf-list format-identifier { 929 type identityref { 930 base zt:certificate-request-format; 931 } 932 min-elements 1; 933 description 934 "A certificate request format supported by the 935 ZTP-client."; 936 } 937 } 938 } 939 } 940 } 942 grouping csr-request-grouping { 943 description 944 "A grouping enabling use by other efforts."; 945 container key-generation { 946 presence 947 "Provided by a ZTP-server to indicate that it wishes 948 the ZTP-client to generate a new asymmetric key. 950 This statement is present so the mandatory descendant 951 nodes do not imply that this node must be configured."; 952 description 953 "The key generation parameters selected by the ZTP-server. 955 This leaf MUST only appear if the ZTP-client's 956 'csr-support' included the 'key-generation' node."; 957 container selected-algorithm { 958 description 959 "The key algorithm selected by the ZTP-server. The 960 algorithm MUST be one of the algorithms specified by 961 the 'supported-algorithms' node in the ZTP-client's 962 message containing the 'csr-support' structure."; 963 leaf algorithm-identifier { 964 type binary; 965 mandatory true; 966 description 967 "An AlgorithmIdentifier, as defined in RFC 2986, 968 encoded using ASN.1 distinguished encoding rules 969 (DER), as specified in ITU-T X.690."; 970 reference 971 "RFC 2986: PKCS #10: Certification Request Syntax 972 Specification Version 1.7 973 ITU-T X.690: 974 Information technology - ASN.1 encoding rules: 975 Specification of Basic Encoding Rules (BER), 976 Canonical Encoding Rules (CER) and Distinguished 977 Encoding Rules (DER)."; 978 } 979 } 980 } 981 container csr-generation { 982 description 983 "Specifies details for the CSR that the ZTP-client 984 is to generate."; 985 container selected-format { 986 description 987 "The CSR format selected by the ZTP-server. The 988 format MUST be one of the formats specified by 989 the 'supported-formats' node in the ZTP-client's 990 request message."; 991 leaf format-identifier { 992 type identityref { 993 base zt:certificate-request-format; 994 } 995 mandatory true; 996 description 997 "A certificate request format to be used by the 998 ZTP-client."; 999 } 1000 } 1002 } 1003 leaf cert-req-info { 1004 type ct:csr-info; 1005 description 1006 "A CertificationRequestInfo structure, as defined in 1007 RFC 2986, and modeled via a 'typedef' statement by 1008 RFC AAAA. 1010 Enables the ZTP-server to provide a fully-populated 1011 CertificationRequestInfo structure that the ZTP-client 1012 only needs to sign in order to generate the complete 1013 'CertificationRequest' structure to send to ZTP-server 1014 in its next 'get-bootstrapping-data' request message. 1016 When provided, the ZTP-client SHOULD use this 1017 structure to generate its CSR; failure to do so MAY 1018 result in a 400 Bad Request response containing 1019 another 'csr-request' structure. 1021 When not provided, the ZTP-client SHOULD generate a 1022 CSR using the same structure defined in its existing 1023 identity certificate (e.g., IDevID). 1025 It is an error if the 'AlgorithmIdentifier' field 1026 contained inside the 'SubjectPublicKeyInfo' field 1027 does not match the algorithm identified by the 1028 'selected-algorithm' node."; 1029 reference 1030 "RFC 2986: 1031 PKCS #10: Certification Request Syntax Specification 1032 RFC AAAA: 1033 YANG Data Types and Groupings for Cryptography"; 1034 } 1035 } 1037 grouping csr-grouping { 1038 description 1039 "Enables a ZTP-client to convey a certificate signing 1040 request, using the encoding format selected by a 1041 ZTP-server's 'csr-request' response to the ZTP-client's 1042 previously sent 'get-bootstrapping-data' request 1043 containing the 'csr-support' node."; 1044 choice csr-type { 1045 mandatory true; 1046 description 1047 "A choice amongst certificate signing request formats. 1049 Additional formats MAY be augmented into this 'choice' 1050 statement by future efforts."; 1051 case p10-csr { 1052 leaf p10-csr { 1053 type ct:csr; 1054 description 1055 "A CertificationRequest structure, per RFC 2986."; 1056 reference 1057 "RFC 2986: PKCS #10: Certification 1058 Request Syntax Specification"; 1059 } 1060 } 1061 case cmc-csr { 1062 leaf cmc-csr { 1063 type binary; 1064 description 1065 "A constrained version of the 'Full PKI Request' 1066 message defined in RFC 5272, encoded using ASN.1 1067 distinguished encoding rules (DER), as specified 1068 in ITU-T X.690. 1070 For asymmetric key-based origin authentication of 1071 a CSR based on the IDevID's private key for the 1072 associated IDevID's public key, the PKIData 1073 contains one reqSequence element and no cmsSequence 1074 or otherMsgSequence elements. The reqSequence is 1075 the TaggedRequest and it is the tcr CHOICE. The 1076 tcr is the TaggedCertificationRequest and it a 1077 bodyPartId and the certificateRequest elements. 1078 The certificateRequest is signed with the IDevID's 1079 private key. The IDevID certificate and optionally 1080 its certificate chain is included in the SignedData 1081 certificates that encapsulates the PKIData. 1083 For asymmetric key-based origin authentication 1084 based on the IDevID's private key that signs the 1085 encapsulated CSR signed by the LDevID's private key, 1086 the PKIData contains one cmsSequence element and no 1087 otherMsgSequence element. The cmsSequence is the 1088 TaggedContentInfo and it includes a bodyPartID 1089 element and a contentInfo. The contentInfo is 1090 a SignedData encapsulating a PKIData with one 1091 reqSequence element and no cmsSequence or 1092 otherMsgSequence elements. The reqSequence is 1093 the TaggedRequest and it is the tcr CHOICE. The 1094 tcr is the TaggedCertificationRequest and it a 1095 bodyPartId and the certificateRequest elements. 1096 The certificateRequest is signed with the LDevID's 1097 private key. The IDevID certificate and optionally 1098 its certificate chain is included in the SignedData 1099 certificates that encapsulates the PKIData. 1101 For shared secret-based origin authentication of a 1102 CSR signed by the LDevID's private key, the PKIData 1103 contains one cmsSequence element and no reqSequence 1104 or otherMsgSequence elements. The cmsSequence is 1105 the TaggedContentInfo and it includes a bodyPartID 1106 element and a contentInfo. The contentInfo is an 1107 AuthenticatedData encapsulating a PKIData with one 1108 reqSequence element and no cmsSequences or 1109 otherMsgSequence elements. The reqSequence is the 1110 TaggedRequest and it is the tcr CHOICE. The tcr is 1111 the TaggedCertificationRequest and it a bodyPartId 1112 and the certificateRequest elements. The 1113 certificateRequest is signed with the LDevID's 1114 private key. The IDevID certificate and optionally 1115 its certificate chain is included in the SignedData 1116 certificates that encapsulates the PKIData."; 1117 reference 1118 "RFC 5272: Certificate Management over CMS (CMC) 1119 ITU-T X.690: 1120 Information technology - ASN.1 encoding rules: 1121 Specification of Basic Encoding Rules (BER), 1122 Canonical Encoding Rules (CER) and Distinguished 1123 Encoding Rules (DER)."; 1124 } 1125 } 1126 case cmp-csr { 1127 leaf cmp-csr { 1128 type binary; 1129 description 1130 "A PKIMessage structure, as defined in RFC 4210, 1131 encoded using ASN.1 distinguished encoding rules 1132 (DER), as specified in ITU-T X.690. 1134 For asymmetric key-based origin authentication of 1135 a CSR based on the IDevID's private key for the 1136 associated IDevID's public key, PKIMessages 1137 contains one PKIMessage with the header and body 1138 elements, no protection element, and should contain 1139 the extraCerts element. The header element contains 1140 the pvno, sender, and recipient elements. The pvno 1141 contains cmp2000, and the sender contains the 1142 subject of the IDevID certificate. The body element 1143 contains a p10cr CHOICE of type CertificationRequet. 1144 It is signed with the IDevID's private key. The 1145 extraCerts element contains the IDevID certificate, 1146 optionally followed by its certificate chain 1147 excluding the trust anchor. 1149 For asymmetric key-based origin authentication 1150 based on the IDevID's private key that signs the 1151 encapsulated CSR signed by the LDevID's private 1152 key, PKIMessages contains one PKIMessage with the 1153 header, body, and protection elements, and should 1154 contain the extraCerts element. The header element 1155 contains the pvno, sender, recipient, protectionAlg, 1156 and optionally senderKID elements. The pvno contains 1157 cmp2000, the sender contains the subject of the 1158 IDevID certificate, the protectionAlg contains the 1159 AlgorithmIdentifier of the used signature algorithm, 1160 and the senderKID contains the subject key 1161 identifier of the IDevID certificate. The body 1162 element contains a p10cr CHOICE of type 1163 CertificationRequet. It is signed with the LDevID's 1164 private key. The protection element contains the 1165 digital signature generated with the IDevID's 1166 private key. The extraCerts element contains the 1167 IDevID certificate, optionally followed by its 1168 certificate chain excluding the trust anchor. 1170 For shared secret-based origin authentication of a 1171 CSR signed by the LDevID's private key, PKIMessages 1172 contains one PKIMessage with the header, body, and 1173 protection element, and no extraCerts element. The 1174 header element contains the pvno, sender, recipient, 1175 protectionAlg, and senderKID elements. The pvno 1176 contains cmp2000, the protectionAlg contains the 1177 AlgorithmIdentifier of the used MAC algorithm, and 1178 the senderKID contains a reference the recipient 1179 can use to identify the shared secret. The body 1180 element contains a p10cr CHOICE of type 1181 CertificationRequet. It is signed with the LDevID's 1182 private key. The protection element contains the 1183 MAC value generated 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 } 1195 } 1196 } 1197 } 1199 } 1201 1203 4. Security Considerations 1205 This document builds on top of the solution presented in [RFC8572] 1206 and therefore all the Security Considerations discussed in RFC 8572 1207 apply here as well. 1209 4.1. SZTP-Client Considerations 1211 4.1.1. Ensuring the Integrity of Asymmetric Private Keys 1213 The private key the SZTP-client uses for the dynamically-generated 1214 identity certificate MUST be protected from inadvertent disclosure in 1215 order to prevent identity fraud. 1217 The security of this private key is essential in order to ensure the 1218 associated identity certificate can be used as a root of trust. 1220 It is RECOMMENDED that devices are manufactured with an HSM (hardware 1221 security module), such as a TPM (trusted platform module), to 1222 generate and forever contain the private key within the security 1223 perimeter of the HSM. In such cases, the private key, and its 1224 associated certificates, MAY have long validity periods. 1226 In cases where the SZTP-client does not possess an HSM, or otherwise 1227 is unable to use an HSM for the private key, it is RECOMMENDED to 1228 regenerate the private key (and associated identity certificates) 1229 periodically. Details for how to generate a new private key and 1230 associate a new identity certificate are outside the scope of this 1231 document. 1233 4.1.2. Reuse of a Manufacturer-generated Private Key 1235 It is RECOMMENDED that a new private key is generated for each CSR 1236 described in this document. 1238 This private key SHOULD be protected as well as the built-in private 1239 key associated with the SZTP-client's initial device identity 1240 certificate (e.g., the IDevID, from [Std-802.1AR-2018]). 1242 In cases where it is not possible to generate a new private key that 1243 is protected as well as the built-in private key, it is RECOMMENDED 1244 to reuse the built-in private key rather than generate a new private 1245 key that is not as well protected. 1247 4.1.3. Replay Attack Protection 1249 This RFC enables an SZTP-client to announce an ability to generate a 1250 new key to use for its CSR. 1252 When the SZTP-server responds with a request for the SZTP-client to 1253 generate a new key, it is essential that the SZTP-client actually 1254 generates a new key. 1256 Generating a new key each time enables the random bytes used to 1257 create the key to also serve the dual-purpose of acting like a 1258 "nonce" used in other mechanisms to detect replay attacks. 1260 When a fresh public/private key pair is generated for the request, 1261 confirmation to the SZTP-client that the response has not been 1262 replayed is enabled by the SZTP-client's fresh public key appearing 1263 in the signed certificate provided by the SZTP-server. 1265 When a public/private key pair associated with the manufacturer- 1266 generated identity certificate (e.g., IDevID) is used for the 1267 request, there may not be confirmation to the SZTP-client that the 1268 response has not been replayed; however, the worst case result is a 1269 lost certificate that is associated to the private key known only to 1270 the SZTP-client. 1272 4.1.4. Connecting to an Untrusted Bootstrap Server 1274 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1275 by blindly authenticating the SZTP-server's TLS end-entity 1276 certificate. 1278 As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- 1279 client MUST assert that the bootstrapping data returned is signed, if 1280 the SZTP-client is to trust it. 1282 However, the HTTP error message used in this document cannot be 1283 signed data, as described in RFC 8572. 1285 Therefore, the solution presented in this document cannot be used 1286 when the SZTP-client connects to an untrusted SZTP-server. 1288 Consistent with the recommendation presented in Section 9.6 of 1289 [RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input 1290 parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass 1291 instead the "signed-data-preferred" input parameter, as discussed in 1292 Appendix B of [RFC8572]. 1294 4.1.5. Selecting the Best Origin Authentication Mechanism 1296 The origin of the CSR must be verified before a certificate is 1297 issued. 1299 When generating a new key, it is important that the SZTP-client be 1300 able to provide additional proof that it was the entity that 1301 generated the key. 1303 The CMP and CMC certificate request formats defined in this document 1304 support origin authentication. A raw PKCS#10 does not support origin 1305 authentication. 1307 The CMP and CMC request formats support origin authentication using 1308 both PKI and shared secret. 1310 Typically, only one possible origin authentication mechanism can 1311 possibly be used but, in the case that the SZTP-client authenticates 1312 itself using both TLS-level (e.g., IDevID) and HTTP-level credentials 1313 (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the 1314 SZTP-client may need to choose between the two options. 1316 In the case that the SZTP-client must choose between an asymmetric 1317 key option versus a shared secret for origin authentication, it is 1318 RECOMMENDED that the SZTP-client choose using the asymmetric key. 1320 4.1.6. Clearing the Private Key and Associated Certificate 1322 Unlike a manufacturer-generated identity certificate (e.g., IDevID), 1323 the deployment-generated identity certificate (e.g., LDevID) and the 1324 associated private key (assuming a new private key was generated for 1325 the purpose), are considered user data and SHOULD be cleared whenever 1326 the SZTP-client is reset to its factory default state, such as by the 1327 "factory-reset" RPC defined in [I-D.ietf-netmod-factory-default]. 1329 4.2. SZTP-Server Considerations 1330 4.2.1. Verifying Proof of Possession 1332 Regardless if using a new asymmetric key or the bootstrapping 1333 device's manufacturer-generated key (e.g., the IDevID key), the 1334 public key is placed in the CSR and the CSR is signed by that private 1335 key. Proof-of-possession of the private key is verified by ensuring 1336 the signature over the CSR using the public key placed in the CSR. 1338 4.2.2. Verifying Proof of Origin 1340 When the bootstrapping device's manufacturer-generated private key 1341 (e.g., the IDevID key) is reused for the CSR, proof-of-origin is 1342 verified by validating the IDevID-issuer cert and ensuring that the 1343 CSR uses the same key pair. 1345 When a new asymmetric key is used, with the CMP or CMC formats, the 1346 parent ASN.1 structure of the CSR provides origin authentication 1347 using either the manufacturer-generated private key or a shared 1348 secret. In this way the proof-of-possession of the CSR is directly 1349 linked to the proof-or-origin provided by the parent ASN.1 structure. 1351 4.2.3. Supporting SZTP-Clients that don't trust the SZTP-Server 1353 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1354 by blindly authenticating the SZTP-server's TLS end-entity 1355 certificate. 1357 As is recommended in Section 4.1.4 in this document, in such cases, 1358 SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. 1360 The reciprocal of this statement is that SZTP-servers, wanting to 1361 support SZTP-clients that don't trust them, SHOULD support the 1362 "signed-data-preferred" input parameter, as discussed in Appendix B 1363 of [RFC8572]. 1365 4.3. Security Considerations for the "ietf-sztp-csr" YANG Module 1367 The recommended format for documenting the Security Considerations 1368 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1369 this module only augments two input parameters into the "get- 1370 bootstrapping-data" RPC in [RFC8572], and therefore only needs to 1371 point to the relevant Security Considerations sections in that RFC. 1373 * Security considerations for the "get-bootstrapping-data" RPC are 1374 described in Section 9.16 of [RFC8572]. 1376 * Security considerations for the "input" parameters passed inside 1377 the "get-bootstrapping-data" RPC are described in Section 9.6 of 1378 [RFC8572]. 1380 4.4. Security Considerations for the "ietf-ztp-types" YANG Module 1382 The recommended format for documenting the Security Considerations 1383 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1384 this module does not define any protocol-accessible nodes (it only 1385 defines "identity" and "grouping" statements) and therefore there are 1386 no Security considerations to report. 1388 5. IANA Considerations 1390 5.1. The "IETF XML" Registry 1392 This document registers two URIs in the "ns" subregistry of the IETF 1393 XML Registry [RFC3688] maintained at 1394 https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. 1395 Following the format in [RFC3688], the following registrations are 1396 requested: 1398 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1399 Registrant Contact: The NETCONF WG of the IETF. 1400 XML: N/A, the requested URI is an XML namespace. 1402 URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1403 Registrant Contact: The NETCONF WG of the IETF. 1404 XML: N/A, the requested URI is an XML namespace. 1406 5.2. The "YANG Module Names" Registry 1408 This document registers two YANG modules in the YANG Module Names 1409 registry [RFC6020] maintained at https://www.iana.org/assignments/ 1410 yang-parameters/yang-parameters.xhtml. Following the format defined 1411 in [RFC6020], the below registrations are requested: 1413 name: ietf-sztp-csr 1414 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1415 prefix: sztp-csr 1416 reference: RFC XXXX 1418 name: ietf-ztp-types 1419 namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types 1420 prefix: ztp-types 1421 reference: RFC XXXX 1423 6. References 1424 6.1. Normative References 1426 [I-D.ietf-netconf-crypto-types] 1427 Watsen, K., "YANG Data Types and Groupings for 1428 Cryptography", Work in Progress, Internet-Draft, draft- 1429 ietf-netconf-crypto-types-21, 14 September 2021, 1430 . 1433 [ITU.X690.2015] 1434 International Telecommunication Union, "Information 1435 Technology - ASN.1 encoding rules: Specification of Basic 1436 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1437 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1438 X.690, ISO/IEC 8825-1, August 2015, 1439 . 1441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1442 Requirement Levels", BCP 14, RFC 2119, 1443 DOI 10.17487/RFC2119, March 1997, 1444 . 1446 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1447 Request Syntax Specification Version 1.7", RFC 2986, 1448 DOI 10.17487/RFC2986, November 2000, 1449 . 1451 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1452 DOI 10.17487/RFC3688, January 2004, 1453 . 1455 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1456 "Internet X.509 Public Key Infrastructure Certificate 1457 Management Protocol (CMP)", RFC 4210, 1458 DOI 10.17487/RFC4210, September 2005, 1459 . 1461 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1462 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 1463 . 1465 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1466 the Network Configuration Protocol (NETCONF)", RFC 6020, 1467 DOI 10.17487/RFC6020, October 2010, 1468 . 1470 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1471 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1472 . 1474 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1475 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1476 . 1478 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1479 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1480 May 2017, . 1482 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1483 Touch Provisioning (SZTP)", RFC 8572, 1484 DOI 10.17487/RFC8572, April 2019, 1485 . 1487 [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data 1488 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1489 June 2020, . 1491 6.2. Informative References 1493 [I-D.ietf-netconf-keystore] 1494 Watsen, K., "A YANG Data Model for a Keystore", Work in 1495 Progress, Internet-Draft, draft-ietf-netconf-keystore-22, 1496 18 May 2021, . 1499 [I-D.ietf-netconf-trust-anchors] 1500 Watsen, K., "A YANG Data Model for a Truststore", Work in 1501 Progress, Internet-Draft, draft-ietf-netconf-trust- 1502 anchors-15, 18 May 2021, 1503 . 1506 [I-D.ietf-netmod-factory-default] 1507 Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for 1508 Factory Default Settings", Work in Progress, Internet- 1509 Draft, draft-ietf-netmod-factory-default-15, 25 April 1510 2020, . 1513 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1514 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1515 . 1517 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1518 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1519 DOI 10.17487/RFC8407, October 2018, 1520 . 1522 [Std-802.1AR-2018] 1523 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 1524 metropolitan area networks - Secure Device Identity", 14 1525 June 2018, . 1528 Acknowledgements 1530 The authors would like to thank for following for lively discussions 1531 on list and in the halls (ordered by first name): David von Oheimb, 1532 Hendrik Brockhaus, Guy Fedorkow, Joe Clarke, Rich Salz, Rob Wilton, 1533 and Qin Wu. 1535 Contributors 1537 Special thanks goes to David von Oheimb and Hendrik Brockhaus for 1538 helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes. 1540 Authors' Addresses 1542 Kent Watsen 1543 Watsen Networks 1545 Email: kent+ietf@watsen.net 1547 Russ Housley 1548 Vigil Security, LLC 1550 Email: housley@vigilsec.com 1552 Sean Turner 1553 sn3rd 1555 Email: sean@sn3rd.com