idnits 2.17.00 (12 Aug 2021) /tmp/idnits12664/draft-ietf-netconf-sztp-csr-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 215 has weird spacing: '...ntifier bin...' == Line 218 has weird spacing: '...ntifier ide...' == Line 255 has weird spacing: '...rmation cms...' == Line 274 has weird spacing: '...ntifier bin...' == Line 277 has weird spacing: '...ntifier ide...' -- The document date (15 June 2021) is 339 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-19 -- 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-21 == Outdated reference: A later version (-17) exists of draft-ietf-netconf-trust-anchors-14 == Outdated reference: draft-ietf-netmod-factory-default has been published as RFC 8808 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Updates: 8572 (if approved) R. Housley 5 Intended status: Standards Track Vigil Security, LLC 6 Expires: 17 December 2021 S. Turner 7 sn3rd 8 15 June 2021 10 Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch 11 Provisioning (SZTP) Bootstrapping Request 12 draft-ietf-netconf-sztp-csr-03 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- 35 types 37 Artwork in this document contains a placeholder value for the 38 publication date of this draft. Please apply the following 39 replacement: 41 * "2021-06-15" --> the publication date of this draft 43 This document contains references to other drafts in progress, both 44 in the Normative References section, as well as in body text 45 throughout. Please update the following references to reflect their 46 final RFC assignments: 48 * I-D.ietf-netconf-crypto-types 49 * I-D.ietf-netconf-keystore 51 * I-D.ietf-netconf-trust-anchors 53 * I-D.ietf-netmod-factory-default 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at https://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on 17 December 2021. 72 Copyright Notice 74 Copyright (c) 2021 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 79 license-info) in effect on the date of publication of this document. 80 Please review these documents carefully, as they describe your rights 81 and restrictions with respect to this document. Code Components 82 extracted from this document must include Simplified BSD License text 83 as described in Section 4.e of the Trust Legal Provisions and are 84 provided without warranty as described in the Simplified BSD License. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 89 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 90 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 91 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 92 2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 93 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 4 94 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 7 95 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13 96 3. Security Considerations . . . . . . . . . . . . . . . . . . . 23 97 3.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 23 98 3.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 23 99 3.1.2. Reuse of a Manufacturer-generated Private Key . . . . 23 100 3.1.3. Replay Attack Protection . . . . . . . . . . . . . . 23 101 3.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 24 102 3.1.5. Selecting the Best Origin Authentication Mechanism . 24 103 3.1.6. Clearing the Private Key and Associated 104 Certificate . . . . . . . . . . . . . . . . . . . . . 25 105 3.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 25 106 3.2.1. Conveying Proof of Possession to a CA . . . . . . . . 25 107 3.2.2. Supporting SZTP-Clients that don't trust the 108 SZTP-Server . . . . . . . . . . . . . . . . . . . . . 25 109 3.2.3. YANG Module Considerations . . . . . . . . . . . . . 26 110 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 111 4.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 26 112 4.2. The "YANG Module Names" Registry . . . . . . . . . . . . 26 113 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 114 5.1. Normative References . . . . . . . . . . . . . . . . . . 26 115 5.2. Informative References . . . . . . . . . . . . . . . . . 27 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 118 1. Introduction 120 1.1. Overview 122 This draft extends the "get-bootstrapping-data" RPC defined in 123 [RFC8572] to include an optional certificate signing request (CSR) 124 [RFC2986], enabling a bootstrapping device to additionally obtain an 125 identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of 126 the "onboarding information" response provided in the RPC-reply. 128 1.2. Terminology 130 This document uses the following terms from [RFC8572]: 132 * Bootstrap Server 133 * Bootstrapping Data 134 * Conveyed Information 135 * Device 136 * Manufacturer 137 * Onboarding Information 138 * Signed Data 140 This document defines the following new terms: 142 SZTP-client The term "SZTP-client" refers to a "device" that is 143 using a "bootstrap server" as a source of "bootstrapping data". 145 SZTP-server The term "SZTP-server" is an alternative term for 146 "bootstrap server" that is symmetric with the "SZTP-client" term. 148 1.3. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 2. The "ietf-sztp-csr" Module 158 This section defines a YANG 1.1 [RFC7950] module that augments the 159 "ietf-sztp-bootstrap-server" module defined in [RFC8572] and defines 160 a YANG "structure". 162 The augmentation adds two nodes ("csr-support" and "csr") to the 163 "input" parameter of the "get-bootstrapping-data" RPC defined in 164 [RFC8572]. 166 The YANG structure, "request-info", defines data returned in the 167 "error-info" node defined in Section 7.1 of [RFC8040]. 169 2.1. Data Model Overview 171 The following tree diagram [RFC8340] illustrates the "ietf-sztp-csr" 172 module. The diagram shows the definition of an augmentation adding 173 descendent nodes "csr-support" and "csr" and the definition of a 174 structure called "request-info". 176 In the order of their intended use: 178 * The "csr-support" node is used by the SZTP-client to signal to the 179 SZTP-server that it supports the ability the generate CSRs, per 180 this specification. The "csr-support" parameter carries details 181 regarding the SZTP-client's ability to generate CSRs. 183 * The "request-info" structure is used by the SZTP-server to signal 184 back to the SZTP-client its desire to sign a CSR. The "request- 185 info" structure additionally communicates details about the CSR 186 the SZTP-client is to generate. 188 * The "csr" node is used by the SZTP-client to communicate its CSR 189 to the SZTP-server. Not shown is how the SZTP-server communicates 190 the signed certificate to the SZTP-client; how to do this is 191 discussed later in this document. 193 module: ietf-sztp-csr 195 augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: 196 +---w csr-support! 197 | +---w key-generation! 198 | | +---w supported-algorithms 199 | | +---w algorithm-identifier* binary 200 | +---w csr-generation 201 | +---w supported-formats 202 | +---w format-identifier* identityref 203 +---w csr! 204 +---w (request-type) 205 +--:(p10) 206 | +---w p10? ct:csr 207 +--:(cmc) 208 | +---w cmc? binary 209 +--:(cmp) 210 +---w cmp? binary 212 structure: request-info 213 +--ro key-generation! 214 | +--ro selected-algorithm 215 | +--ro algorithm-identifier binary 216 +--ro csr-generation 217 | +--ro selected-format 218 | +--ro format-identifier identityref 219 +--ro cert-req-info? ietf-crypto-types:csr-info 221 To further illustrate how the augmentation and structure defined by 222 the "ietf-sztp-csr" module are used, below are two additional tree 223 diagrams showing these nodes placed where they are used. 225 The following tree diagram [RFC8340] illustrates SZTP's "get- 226 bootstrapping-data" RPC with the augmentation in place. 228 module: ietf-sztp-bootstrap-server 230 rpcs: 231 +---x get-bootstrapping-data 232 +---w input 233 | +---w signed-data-preferred? empty 234 | +---w hw-model? string 235 | +---w os-name? string 236 | +---w os-version? string 237 | +---w nonce? binary 238 | +---w sztp-csr:csr-support! 239 | | +---w sztp-csr:key-generation! 240 | | | +---w sztp-csr:supported-algorithms 241 | | | +---w sztp-csr:algorithm-identifier* binary 242 | | +---w sztp-csr:csr-generation 243 | | +---w sztp-csr:supported-formats 244 | | +---w sztp-csr:format-identifier* identityref 245 | +---w sztp-csr:csr! 246 | +---w (sztp-csr:request-type) 247 | +--:(sztp-csr:p10) 248 | | +---w sztp-csr:p10? ct:csr 249 | +--:(sztp-csr:cmc) 250 | | +---w sztp-csr:cmc? binary 251 | +--:(sztp-csr:cmp) 252 | +---w sztp-csr:cmp? binary 253 +--ro output 254 +--ro reporting-level? enumeration {onboarding-server}? 255 +--ro conveyed-information cms 256 +--ro owner-certificate? cms 257 +--ro ownership-voucher? cms 259 The following tree diagram [RFC8340] illustrates RESTCONF's "errors" 260 RPC-reply message with the "request-info" structure in place. 262 module: ietf-restconf 263 +--ro errors 264 +--ro error* [] 265 +--ro error-type enumeration 266 +--ro error-tag string 267 +--ro error-app-tag? string 268 +--ro error-path? instance-identifier 269 +--ro error-message? string 270 +--ro error-info 271 +--ro request-info 272 +--ro key-generation! 273 | +--ro selected-algorithm 274 | +--ro algorithm-identifier binary 275 +--ro csr-generation 276 | +--ro selected-format 277 | +--ro format-identifier identityref 278 +--ro cert-req-info? ct:csr-info 280 2.2. Example Usage 282 | The examples below are encoded using JSON, but they could 283 | equally well be encoded using XML, as is supported by SZTP. 285 An SZTP-client implementing this specification would signal to the 286 bootstrap server its willingness to generate a CSR by including the 287 "csr-support" node in its "get-bootstrapping-data" RPC, as 288 illustrated below. 290 REQUEST 291 =============== NOTE: '\' line wrapping per RFC 8792 ================ 293 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 294 ng-data HTTP/1.1 295 HOST: example.com 296 Content-Type: application/yang.data+json 298 { 299 "ietf-sztp-bootstrap-server:input" : { 300 "hw-model": "model-x", 301 "os-name": "vendor-os", 302 "os-version": "17.3R2.1", 303 "nonce": "extralongbase64encodedvalue=", 304 "ietf-sztp-csr:csr-support": { 305 "key-generation": { 306 "supported-algorithms": { 307 "algorithm-identifier": [ 308 "base64encodedvalue1=", 309 "base64encodedvalue2=", 310 "base64encodedvalue3=" 311 ] 312 } 313 }, 314 "csr-generation": { 315 "supported-formats": { 316 "format-identifier": [ 317 "ietf-sztp-csr:p10", 318 "ietf-sztp-csr:cmc", 319 "ietf-sztp-csr:cmp" 320 ] 321 } 322 } 323 } 324 } 325 } 327 Assuming the SZTP-server wishes to prompt the SZTP-client to provide 328 a CSR, then it would respond with an HTTP 400 (Bad Request) error 329 code: 331 RESPONSE 332 HTTP/1.1 400 Bad Request 333 Date: Sat, 31 Oct 2015 17:02:40 GMT 334 Server: example-server 335 Content-Type: application/yang.data+json 337 { 338 "ietf-restconf:errors" : { 339 "error" : [ 340 { 341 "error-type": "application", 342 "error-tag": "missing-attribute", 343 "error-message": "Missing input parameter", 344 "error-info": { 345 "ietf-sztp-csr:request-info": { 346 "key-generation": { 347 "selected-algorithm": { 348 "algorithm-identifier": "base64EncodedValue==" 349 } 350 }, 351 "csr-generation": { 352 "selected-format": { 353 "format-identifier": "ietf-sztp-csr:cmc" 354 } 355 }, 356 "cert-req-info": "base64EncodedValue==" 357 } 358 } 359 } 360 ] 361 } 362 } 364 Upon being prompted to provide a CSR, the SZTP-client would POST 365 another "get-bootstrapping-data" request, but this time including the 366 "csr" node to convey its CSR to the SZTP-server: 368 REQUEST 369 =============== NOTE: '\' line wrapping per RFC 8792 ================ 371 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 372 ng-data HTTP/1.1 373 HOST: example.com 374 Content-Type: application/yang.data+json 376 { 377 "ietf-sztp-bootstrap-server:input" : { 378 "hw-model": "model-x", 379 "os-name": "vendor-os", 380 "os-version": "17.3R2.1", 381 "nonce": "extralongbase64encodedvalue=", 382 "ietf-sztp-csr:csr": { 383 "p10": "base64encodedvalue==" 384 } 385 } 386 } 388 The SZTP-server responds with "onboarding-information" (encoded 389 inside the "conveyed-information" node) containing a signed identity 390 certificate for the CSR provided by the SZTP-client: 392 RESPONSE 394 HTTP/1.1 200 OK 395 Date: Sat, 31 Oct 2015 17:02:40 GMT 396 Server: example-server 397 Content-Type: application/yang.data+json 399 { 400 "ietf-sztp-bootstrap-server:output" : { 401 "reporting-level": "verbose", 402 "conveyed-information": "base64encodedvalue==" 403 } 404 } 406 How the signed certificate is conveyed inside the onboarding 407 information is outside the scope of this document. Some 408 implementations may choose to convey it inside a script (e.g., SZTP's 409 "pre-configuration-script"), while other implementations may choose 410 to convey it inside the SZTP "configuration" node. SZTP onboarding 411 information is described in Section 2.2 of [RFC8572]. 413 Following are two examples of conveying the signed certificate inside 414 the "configuration" node. Both examples assume that the SZTP-client 415 understands the "ietf-keystore" module defined in 416 [I-D.ietf-netconf-keystore]. 418 This first example illustrates the case where the signed certificate 419 is for the same asymmetric key used by the SZTP-client's 420 manufacturer-generated identity certificate (e.g., an IDevID, from 421 [Std-802.1AR-2018]). As such, the configuration needs to associate 422 the newly signed certificate with the existing asymmetric key: 424 =============== NOTE: '\' line wrapping per RFC 8792 ================ 426 { 427 "ietf-keystore:keystore": { 428 "asymmetric-keys": { 429 "asymmetric-key": [ 430 { 431 "name": "Manufacturer-Generated Hidden Key", 432 "public-key-format": "ietf-crypto-types:subject-public-key\ 433 -info-format", 434 "public-key": "base64encodedvalue==", 435 "hidden-private-key": [null], 436 "certificates": { 437 "certificate": [ 438 { 439 "name": "Manufacturer-Generated IDevID Cert", 440 "cert-data": "base64encodedvalue==" 441 }, 442 { 443 "name": "Newly-Generated LDevID Cert", 444 "cert-data": "base64encodedvalue==" 445 } 446 ] 447 } 448 } 449 ] 450 } 451 } 452 } 454 This second example illustrates the case where the signed certificate 455 is for a newly generated asymmetric key. As such, the configuration 456 needs to associate the newly signed certificate with the newly 457 generated asymmetric key: 459 =============== NOTE: '\' line wrapping per RFC 8792 ================ 461 { 462 "ietf-keystore:keystore": { 463 "asymmetric-keys": { 464 "asymmetric-key": [ 465 { 466 "name": "Manufacturer-Generated Hidden Key", 467 "public-key-format": "ietf-crypto-types:subject-public-key\ 468 -info-format", 469 "public-key": "base64encodedvalue==", 470 "hidden-private-key": [null], 471 "certificates": { 472 "certificate": [ 473 { 474 "name": "Manufacturer-Generated IDevID Cert", 475 "cert-data": "base64encodedvalue==" 476 } 477 ] 478 } 479 }, 480 { 481 "name": "Newly-Generated Hidden Key", 482 "public-key-format": "ietf-crypto-types:subject-public-key\ 483 -info-format", 484 "public-key": "base64encodedvalue==", 485 "hidden-private-key": [null], 486 "certificates": { 487 "certificate": [ 488 { 489 "name": "Newly-Generated LDevID Cert", 490 "cert-data": "base64encodedvalue==" 491 } 492 ] 493 } 494 } 495 ] 496 } 497 } 498 } 500 In addition to configuring the signed certificate, it is often 501 necessary to also configure the Issuer's signing certificate so that 502 the device (i.e., STZP-client) can authenticate certificates 503 presented by peer devices signed by the same issuer as its own. 504 While outside the scope of this document, one way to do this would be 505 to use the "ietf-truststore" module defined in 506 [I-D.ietf-netconf-trust-anchors]. 508 2.3. YANG Module 510 This module augments an RPC defined in [RFC8572], uses a data type 511 defined in [I-D.ietf-netconf-crypto-types], has an normative 512 references to [RFC2986] and [ITU.X690.2015], and an informative 513 reference to [Std-802.1AR-2018]. 515 file "ietf-sztp-csr@2021-06-15.yang" 517 module ietf-sztp-csr { 518 yang-version 1.1; 519 namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; 520 prefix sztp-csr; 522 import ietf-sztp-bootstrap-server { 523 prefix sztp-svr; 524 reference 525 "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 526 } 528 import ietf-yang-structure-ext { 529 prefix sx; 530 reference 531 "RFC 8791: YANG Data Structure Extensions"; 532 } 534 import ietf-crypto-types { 535 prefix ct; 536 reference 537 "RFC AAAA: YANG Data Types and Groupings for Cryptography"; 538 } 540 organization 541 "IETF NETCONF (Network Configuration) Working Group"; 543 contact 544 "WG Web: http://tools.ietf.org/wg/netconf 545 WG List: 546 Authors: Kent Watsen 547 Russ Housley 548 Sean Turner "; 550 description 551 "This module augments the 'get-bootstrapping-data' RPC, 552 defined in the 'ietf-sztp-bootstrap-server' module from 553 SZTP (RFC 8572), enabling the SZTP-client to obtain a 554 signed identity certificate (e.g., an LDevID from IEEE 555 802.1AR) as part of the SZTP onboarding information 556 response. 558 Copyright (c) 2020 IETF Trust and the persons identified 559 as authors of the code. All rights reserved. 561 Redistribution and use in source and binary forms, with 562 or without modification, is permitted pursuant to, and 563 subject to the license terms contained in, the Simplified 564 BSD License set forth in Section 4.c of the IETF Trust's 565 Legal Provisions Relating to IETF Documents 566 (https://trustee.ietf.org/license-info). 568 This version of this YANG module is part of RFC XXXX 569 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 570 itself for full legal notices. 572 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 573 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 574 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 575 document are to be interpreted as described in BCP 14 576 (RFC 2119) (RFC 8174) when, and only when, they appear 577 in all capitals, as shown here."; 579 revision 2021-06-15 { 580 description 581 "Initial version"; 582 reference 583 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 584 in a Secure Zero Touch Provisioning (SZTP) 585 Bootstrapping Request"; 586 } 588 identity certificate-request-format { 589 description 590 "A base identity for the request formats supported 591 by the SZTP-client. 593 Additional derived identities MAY be defined by 594 future efforts."; 595 } 597 identity p10 { 598 base certificate-request-format; 599 description 600 "Indicates that the SZTP-client supports generating 601 requests using the 'CertificationRequest' structure 602 defined in RFC 2986."; 603 reference 604 "RFC 2986: PKCS #10: Certification Request Syntax 605 Specification Version 1.7"; 606 } 608 identity cmc { 609 base certificate-request-format; 610 description 611 "Indicates that the SZTP-client supports generating 612 requests using a constrained version of the 'Full 613 PKI Request' structure defined in RFC 5272."; 614 reference 615 "RFC 5272: Certificate Management over CMS (CMC)"; 616 } 618 identity cmp { 619 base certificate-request-format; 620 description 621 "Indicates that the SZTP-client supports generating 622 requests that contain a PKCS#10 Certificate Signing 623 Request (p10cr), as defined in RFC 2986, encapsulated 624 in a Nested Message Content (nested), as defined in 625 RFC 4210."; 626 reference 627 "RFC 2986: PKCS #10: Certification Request Syntax 628 Specification Version 1.7 629 RFC 4210: Internet X.509 Public Key Infrastructure 630 Certificate Management Protocol (CMP)"; 631 } 633 // Protocol-accessible nodes 635 augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { 636 description 637 "This augmentation adds the 'csr-support' and 'csr' nodes to 638 the SZTP (RFC 8572) 'get-bootstrapping-data' request message, 639 enabling the SZTP-client to obtain an identity certificate 640 (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding 641 information response provided by the SZTP-server. 643 The 'csr-support' node enables the SZTP-client to indicate 644 that it supports generating certificate signing requests 645 (CSRs), and to provide details around the CSRs it is able 646 to generate. 648 The 'csr' node enables the SZTP-client to relay a CSR to 649 the SZTP-server."; 650 reference 651 "IEEE 802.1AR: IEEE Standard for Local and metropolitan 652 area networks - Secure Device Identity 653 RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 654 container csr-support { 655 presence 656 "Indicates that the SZTP-client is capable of sending CSRs."; 657 description 658 "The 'csr-support' node enables the SZTP-client to indicate 659 that it supports generating certificate signing requests 660 (CSRs), and provide details around the CSRs it is able 661 to generate. 663 When present, the SZTP-server MAY respond with the HTTP 664 error 400 (Bad Request) with an 'ietf-restconf:errors' 665 document having the 'error-tag' value 'missing-attribute' 666 and the 'error-info' node containing the 'request-info' 667 structure described in this module."; 668 container key-generation { 669 presence 670 "Indicates that the SZTP-client is capable of 671 generating a new asymmetric key pair. 673 If this node is not present, the SZTP-server MAY 674 request a CSR using the asymmetric key associated 675 with the device's existing identity certificate 676 (e.g., an IDevID from IEEE 802.1AR)."; 677 description 678 "Specifies details for the SZTP-client's ability to 679 generate a new asymmetric key pair."; 680 container supported-algorithms { 681 description 682 "A list of public key algorithms supported by the 683 SZTP-client for generating a new key."; 684 leaf-list algorithm-identifier { 685 type binary; 686 min-elements 1; 687 description 688 "An AlgorithmIdentifier, as defined in RFC 2986, 689 encoded using ASN.1 distinguished encoding rules 690 (DER), as specified in ITU-T X.690."; 691 reference 692 "RFC 2986: PKCS #10: Certification Request Syntax 693 Specification Version 1.7 694 ITU-T X.690: 695 Information technology - ASN.1 encoding rules: 696 Specification of Basic Encoding Rules (BER), 697 Canonical Encoding Rules (CER) and Distinguished 698 Encoding Rules (DER)."; 699 } 701 } 702 } 703 container csr-generation { 704 description 705 "Specifies details for the SZTP-client's ability to 706 generate a certificate signing requests."; 707 container supported-formats { 708 description 709 "A list of certificate request formats supported 710 by the SZTP-client for generating a new key."; 711 leaf-list format-identifier { 712 type identityref { 713 base certificate-request-format; 714 } 715 min-elements 1; 716 description 717 "A certificate request format supported by the 718 SZTP-client."; 719 } 720 } 721 } 722 } 723 container csr { 724 presence "Indicates that the SZTP-client has sent a CSR."; 725 description 726 "The 'csr' node enables the SZTP-client to convey 727 a certificate signing request, using the encoding 728 format selected by the SZT-server's 'request-info' 729 response to the SZTP-client's previously sent 730 'get-bootstrapping-data' request containing the 731 'csr-support' node. 733 When present, the SZTP-server SHOULD respond with 734 an SZTP onboarding information message containing 735 a signed certificate for the conveyed CSR. The 736 SZTP-server MAY alternatively respond with another 737 HTTP error containing another 'request-info', in 738 which case the SZTP-client MUST invalidate the CSR 739 sent in this node."; 740 choice request-type { 741 mandatory true; 742 description 743 "A choice amongst certificate signing request formats. 745 Additional formats MAY be augmented into this 'choice' 746 statement by future efforts."; 747 case p10 { 748 leaf p10 { 749 type ct:csr; 750 description 751 "A CertificationRequest structure, per RFC 2986. 752 Please see 'csr' in RFC AAAA for encoding details."; 753 reference 754 "RFC 2986: 755 PKCS #10: Certification Request Syntax Specification 756 RFC AAAA: 757 YANG Data Types and Groupings for Cryptography"; 758 } 759 } 760 case cmc { 761 leaf cmc { 762 type binary; 763 description 764 "A constrained version of the 'Full PKI Request' 765 message defined in RFC 5272, encoded using ASN.1 766 distinguished encoding rules (DER), as specified 767 in ITU-T X.690. 769 For asymmetric key-based origin authentication 770 of a CSR based on the IDevID's private key for the 771 associated IDevID's public key, the PKIData contains 772 one reqSequence element and no controlSequence, 773 cmsSequence, or otherMsgSequence elements. The 774 reqSequence is the TaggedRequest and it is the tcr 775 CHOICE. The tcr is the TaggedCertificationRequest 776 and it a bodyPartId and the certificateRequest 777 elements. The certificateRequest is signed with 778 the IDevID's private key. 780 For asymmetric key-based origin authentication 781 based on the IDevID's private key that encapsulates 782 a CSR signed by the LDevID's private key, the 783 PKIData contains one cmsSequence element and no 784 controlSequence, reqSequence, or otherMsgSequence 785 elements. The cmsSequence is the TaggedContentInfo 786 and it includes a bodyPartID element and a 787 contentInfo. The contentInfo is a SignedData 788 encapsulating a PKIData with one reqSequence 789 element and no controlSequence, cmsSequence, or 790 otherMsgSequence elements. The reqSequence is 791 the TaggedRequest and it is the tcr CHOICE. The 792 tcr is the TaggedCertificationRequest and it a 793 bodyPartId and the certificateRequest elements. 794 The certificateRequest is signed with the LDevID's 795 private key. 797 For shared secret-based origin authentication of 798 a CSR signed by the LDevID's private key, the 799 PKIData contains one cmsSequence element and no 800 controlSequence, reqSequence, or otherMsgSequence 801 elements. The cmsSequence is the TaggedContentInfo 802 and it includes a bodyPartID element and a 803 contentInfo. The contentInfo is an AuthenticatedData 804 encapsulating a PKIData with one reqSequence 805 element and no controlSequence, cmsSequence, or 806 otherMsgSequence elements. The reqSequence is the 807 TaggedRequest and it is the tcr CHOICE. The tcr 808 is the TaggedCertificationRequest and it a 809 bodyPartId and the certificateRequest elements. 810 The certificateRequest is signed with the LDevID's 811 private key."; 812 reference 813 "RFC 5272: Certificate Management over CMS (CMC) 814 ITU-T X.690: 815 Information technology - ASN.1 encoding rules: 816 Specification of Basic Encoding Rules (BER), 817 Canonical Encoding Rules (CER) and Distinguished 818 Encoding Rules (DER)."; 819 } 820 } 821 case cmp { 822 leaf cmp { 823 type binary; 824 description 825 "A PKIMessage structure, as defined in RFC 4210, 826 encoded using ASN.1 distinguished encoding rules 827 (DER), as specified in ITU-T X.690. 829 The PKIMessage structure contains a PKCS#10 830 Certificate Signing Request (p10cr), as defined in 831 RFC 2986, encapsulated in a Nested Message Content 832 (nested) structure, as defined in RFC 4210. 834 For asymmetric key-based origin authentication of 835 a CSR based on the IDevID's private key for the 836 associated IDevID's public key, PKIMessages contains 837 one PKIMessage with one body element, a header 838 element that is an empty sequence, and no protection 839 or extraCerts elements. The body element contains a 840 p10cr CHOICE. 842 For asymmetric key-based origin authentication based 843 on the IDevID's private key that encapsulates a CSR 844 signed by the LDevID's private key, PKIMessages 845 contains one PKIMessage with one header element, 846 one body element, one protection element, and one 847 extraCerts element. The header element contains 848 pvno, sender, recipient, and protectionAlg elements 849 and no other elements. The body element contains the 850 nested CHOICE. The nested element's PKIMessages 851 contains one PKIMessage with one body element, one 852 header element that is an empty sequence, and no 853 protection or extraCerts elements. The nested 854 element's body element contains a p10cr CHOICE. The 855 protection element contains the digital signature 856 generated with the IDevID's private key. The 857 extraCerts element contains the IDevID certificate. 859 For shared secret-based origin authentication of a 860 CSR signed by the LDevID's private key, PKIMessages 861 contains one PKIMessage with one header element, 862 one body element, one protection element, and no 863 extraCerts element. The header element contains 864 pvno, sender, recipient, and protectionAlg elements 865 and no other elements. The body element contains 866 the nested CHOICE. The nested element's PKIMessages 867 contains one PKIMessage with one body element, one 868 header element that is an empty sequence, and no 869 protection or extraCerts elements. The body element 870 contains a p10cr CHOICE. The protection element 871 contains the MAC value generated with the shared 872 secret."; 873 reference 874 "RFC 2986: 875 PKCS #10: Certification Request Syntax 876 Specification Version 1.7 877 RFC 4210: 878 Internet X.509 Public Key Infrastructure 879 Certificate Management Protocol (CMP) 880 ITU-T X.690: 881 Information technology - ASN.1 encoding rules: 882 Specification of Basic Encoding Rules (BER), 883 Canonical Encoding Rules (CER) and Distinguished 884 Encoding Rules (DER)."; 885 } 886 } 887 } 888 } 889 } 891 sx:structure request-info { 892 container key-generation { 893 presence 894 "Indicates that the SZTP-client is to generate a new 895 asymmetric key. If missing, then the SZTP-client 896 MUST reuse the key associated with its existing 897 identity certificate (e.g., IDevID). 899 This leaf MUST only appear if the SZTP-clients 900 'csr-support' included the 'key-generation' node."; 901 description 902 "A YANG data structure, per RFC 8791, that specifies 903 details for the key that the SZTP-client is to 904 generate."; 905 reference 906 "RFC 8791: YANG Data Structure Extensions"; 907 container selected-algorithm { 908 description 909 "The key algorithm selected by the SZTP-server. The 910 algorithm MUST be one of the algorithms specified 911 by the 'supported-algorithms' node in the 912 SZTP-client's request message."; 913 leaf algorithm-identifier { 914 type binary; 915 mandatory true; 916 description 917 "An AlgorithmIdentifier, as defined in RFC 2986, 918 encoded using ASN.1 distinguished encoding rules 919 (DER), as specified in ITU-T X.690."; 920 reference 921 "RFC 2986: PKCS #10: Certification Request Syntax 922 Specification Version 1.7 923 ITU-T X.690: 924 Information technology - ASN.1 encoding rules: 925 Specification of Basic Encoding Rules (BER), 926 Canonical Encoding Rules (CER) and Distinguished 927 Encoding Rules (DER)."; 928 } 929 } 930 } 931 container csr-generation { 932 description 933 "Specifies details for the CSR that the SZTP-client 934 is to generate."; 935 container selected-format { 936 description 937 "The CSR format selected by the SZTP-server. The 938 format MUST be one of the formats specified by 939 the 'supported-formats' node in the SZTP-client's 940 request message."; 942 leaf format-identifier { 943 type identityref { 944 base certificate-request-format; 945 } 946 mandatory true; 947 description 948 "A certificate request format to be used by the 949 SZTP-client."; 950 } 951 } 952 } 953 leaf cert-req-info { 954 type ct:csr-info; 955 description 956 "A CertificationRequestInfo structure, as defined in 957 RFC 2986, and modeled via a 'typedef' statement by 958 RFC AAAA. 960 Enables the SZTP-server to provide a fully-populated 961 CertificationRequestInfo structure that the SZTP-client 962 only needs to sign in order to generate the complete 963 'CertificationRequest' structure to send to SZTP-server 964 in its next 'get-bootstrapping-data' request message. 966 When provided, the SZTP-client SHOULD use this 967 structure to generate its CSR; failure to do so MAY 968 result in a 400 (Bad Request) response containing 969 another 'request-info' structure. 971 When not provided, the SZTP-client SHOULD generate a 972 CSR using the same structure defined in its existing 973 identity certificate (e.g., IDevID). 975 It is an error if the 'AlgorithmIdentifier' field 976 contained inside the 'SubjectPublicKeyInfo' field 977 does not match the algorithm identified by the 978 'selected-algorithm' node."; 979 reference 980 "RFC 2986: 981 PKCS #10: Certification Request Syntax Specification 982 RFC AAAA: 983 YANG Data Types and Groupings for Cryptography"; 984 } 985 } 986 } 988 990 3. Security Considerations 992 This document builds on top of the solution presented in [RFC8572] 993 and therefore all the Security Considerations discussed in RFC 8572 994 apply here as well. 996 3.1. SZTP-Client Considerations 998 3.1.1. Ensuring the Integrity of Asymmetric Private Keys 1000 The private key the SZTP-client uses for the dynamically-generated 1001 identity certificate MUST be protected from inadvertent disclosure in 1002 order to prevent identity fraud. 1004 The security of this private key is essential in order to ensure the 1005 associated identity certificate can be used as a root of trust. 1007 It is RECOMMENDED that devices are manufactured with an HSM (hardware 1008 security module), such as a TPM (trusted platform module), to 1009 generate and forever contain the private key within the security 1010 perimeter of the HSM. In such cases, the private key, and its 1011 associated certificates, MAY have long validity periods. 1013 In cases where the device does not possess an HSM, or otherwise is 1014 unable to use an HSM for the private key, it is RECOMMENDED to 1015 regenerate the private key (and associated identity certificates) 1016 periodically. Details for how to generate a new private key and 1017 associate a new identity certificate are outside the scope of this 1018 document. 1020 3.1.2. Reuse of a Manufacturer-generated Private Key 1022 It is RECOMMENDED that a new private key is generated for each CSR 1023 described in this document. 1025 This private key SHOULD be protected as well as the built-in private 1026 key associated with the device's initial secure device identity 1027 certificate (e.g., the IDevID, from [Std-802.1AR-2018]). 1029 In cases where it is not possible to generate a new private key that 1030 is protected as well as the built-in private key, it is RECOMMENDED 1031 to reuse the built-in private key rather than generate a new private 1032 key that is not as well protected. 1034 3.1.3. Replay Attack Protection 1036 This RFC enables an SZTP-client to announce an ability to generate 1037 new key to use for its CSR. 1039 When the SZTP-server responds with a request for the device to 1040 generate a new key, it is essential that the device actually 1041 generates a new key. 1043 Generating a new key each time enables the random bytes used to 1044 create the key to serve the dual-purpose of also acting like a 1045 "nonce" used in other mechanisms to detect replay attacks. 1047 When a fresh public/private key pair is generated for the request, 1048 confirmation to the SZTP-client that the response has not been 1049 replayed is enabled by the SZTP-client's fresh public key appearing 1050 in the signed certificate provided by the SZTP-server. 1052 When a public/private key pair associated with the IDevID used for 1053 the request, there may not be confirmation to the SZTP-client that 1054 the response has not been replayed; however, the worst case result is 1055 a lost certificate that is associated to the private key known only 1056 to the SZTP-client. 1058 3.1.4. Connecting to an Untrusted Bootstrap Server 1060 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1061 by blindly authenticating the SZTP-server's TLS end-entity 1062 certificate. 1064 As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- 1065 client MUST assert that the bootstrapping data returned is signed, if 1066 the SZTP-client is to trust it. 1068 However, the HTTP error message used in this document cannot be 1069 signed data, as described in RFC 8572. 1071 Therefore, the solution presented in this document cannot be used 1072 when the SZTP-client connects to an untrusted SZTP-server. 1074 Consistent with the recommendation presented in Section 9.6 of 1075 [RFC8572], SZTP-clients SHOULD NOT passed the "csr-support" input 1076 parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass 1077 instead the "signed-data-preferred" input parameter, as discussed in 1078 Appendix B of [RFC8572]. 1080 3.1.5. Selecting the Best Origin Authentication Mechanism 1082 When generating a new key, it is important that the client be able to 1083 provide additional proof to the CA that it was the entity that 1084 generated the key. 1086 All of the certificate request formats defined in this document 1087 (e.g., CMC, CMP, etc.), not including a raw PKCS#10, support origin 1088 authentication. 1090 These formats support origin authentication using both PKI and shared 1091 secret. 1093 Typically only one possible origin authentication mechanism can 1094 possibly be used but, in the case that the SZTP-client authenticates 1095 itself using both TLS-level (e.g., IDevID) and HTTP-level credentials 1096 (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the 1097 SZTP-client may need to choose between the two options. 1099 In the case the SZTP-client must choose between the asymmetric key 1100 option versus a shared secret for origin authentication, it is 1101 RECOMMENDED that the SZTP-client choose using the asymmetric key 1102 option. 1104 3.1.6. Clearing the Private Key and Associated Certificate 1106 Unlike a manufacturer-generated identity certificate (e.g., IDevID), 1107 the deployment-generated identity certificate (e.g., LDevID) and the 1108 associated private key (assuming a new private key was generated for 1109 the purpose), are considered user data and SHOULD be cleared whenever 1110 the device is reset to its factory default state, such as by the 1111 "factory-reset" RPC defined in [I-D.ietf-netmod-factory-default]. 1113 3.2. SZTP-Server Considerations 1115 3.2.1. Conveying Proof of Possession to a CA 1117 3.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server 1119 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1120 by blindly authenticating the SZTP-server's TLS end-entity 1121 certificate. 1123 As is recommended in Section 3.1.4 in this document, in such cases, 1124 SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. 1126 The reciprocal of this statement is that SZTP-servers, wanting to 1127 support SZTP-clients that don't trust them, SHOULD support the 1128 "signed-data-preferred" input parameter, as discussed in Appendix B 1129 of [RFC8572]. 1131 3.2.3. YANG Module Considerations 1133 The recommended format for documenting the Security Considerations 1134 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1135 the module defined in this document only augments two input 1136 parameters into the "get-bootstrapping-data" RPC in [RFC8572], and 1137 therefore only needs to point to the relevant Security Considerations 1138 sections in that RFC. 1140 * Security considerations for the "get-bootstrapping-data" RPC are 1141 described in Section 9.16 of [RFC8572]. 1143 * Security considerations for the "input" parameters passed inside 1144 the "get-bootstrapping-data" RPC are described in Section 9.6 of 1145 [RFC8572]. 1147 4. IANA Considerations 1149 4.1. The "IETF XML" Registry 1151 This document registers one URI in the "ns" subregistry of the IETF 1152 XML Registry [RFC3688] maintained at 1153 https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. 1154 Following the format in [RFC3688], the following registration is 1155 requested: 1157 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1158 Registrant Contact: The NETCONF WG of the IETF. 1159 XML: N/A, the requested URI is an XML namespace. 1161 4.2. The "YANG Module Names" Registry 1163 This document registers one YANG module in the YANG Module Names 1164 registry [RFC6020] maintained at https://www.iana.org/assignments/ 1165 yang-parameters/yang-parameters.xhtml. Following the format defined 1166 in [RFC6020], the below registration is requested: 1168 name: ietf-sztp-csr 1169 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1170 prefix: sztp-csr 1171 reference: RFC XXXX 1173 5. References 1175 5.1. Normative References 1177 [I-D.ietf-netconf-crypto-types] 1178 Watsen, K., "YANG Data Types and Groupings for 1179 Cryptography", Work in Progress, Internet-Draft, draft- 1180 ietf-netconf-crypto-types-19, 10 February 2021, 1181 . 1184 [ITU.X690.2015] 1185 International Telecommunication Union, "Information 1186 Technology - ASN.1 encoding rules: Specification of Basic 1187 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1188 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1189 X.690, ISO/IEC 8825-1, August 2015, 1190 . 1192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1193 Requirement Levels", BCP 14, RFC 2119, 1194 DOI 10.17487/RFC2119, March 1997, 1195 . 1197 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1198 Request Syntax Specification Version 1.7", RFC 2986, 1199 DOI 10.17487/RFC2986, November 2000, 1200 . 1202 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1203 the Network Configuration Protocol (NETCONF)", RFC 6020, 1204 DOI 10.17487/RFC6020, October 2010, 1205 . 1207 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1208 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1209 . 1211 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1212 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1213 . 1215 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1216 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1217 May 2017, . 1219 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1220 Touch Provisioning (SZTP)", RFC 8572, 1221 DOI 10.17487/RFC8572, April 2019, 1222 . 1224 5.2. Informative References 1226 [I-D.ietf-netconf-keystore] 1227 Watsen, K., "A YANG Data Model for a Keystore", Work in 1228 Progress, Internet-Draft, draft-ietf-netconf-keystore-21, 1229 10 February 2021, . 1232 [I-D.ietf-netconf-trust-anchors] 1233 Watsen, K., "A YANG Data Model for a Truststore", Work in 1234 Progress, Internet-Draft, draft-ietf-netconf-trust- 1235 anchors-14, 10 February 2021, 1236 . 1239 [I-D.ietf-netmod-factory-default] 1240 Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for 1241 Factory Default Settings", Work in Progress, Internet- 1242 Draft, draft-ietf-netmod-factory-default-15, 25 April 1243 2020, . 1246 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1247 DOI 10.17487/RFC3688, January 2004, 1248 . 1250 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1251 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1252 . 1254 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1255 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1256 DOI 10.17487/RFC8407, October 2018, 1257 . 1259 [Std-802.1AR-2018] 1260 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 1261 metropolitan area networks - Secure Device Identity", 14 1262 June 2018, . 1265 Authors' Addresses 1267 Kent Watsen 1268 Watsen Networks 1270 Email: kent+ietf@watsen.net 1271 Russ Housley 1272 Vigil Security, LLC 1274 Email: housley@vigilsec.com 1276 Sean Turner 1277 sn3rd 1279 Email: sean@sn3rd.com