idnits 2.17.1 draft-kwatsen-netconf-sztp-csr-01.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 218 has weird spacing: '...ntifier bin...' == Line 221 has weird spacing: '...ntifier ide...' == Line 258 has weird spacing: '...rmation cms...' == Line 277 has weird spacing: '...ntifier bin...' == Line 280 has weird spacing: '...ntifier ide...' -- The document date (10 June 2020) is 1409 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-15 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2015' ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-17 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-10 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: 12 December 2020 S. Turner 7 sn3rd 8 10 June 2020 10 Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch 11 Provisioning (SZTP) Bootstrapping Request 12 draft-kwatsen-netconf-sztp-csr-01 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 * "2020-06-10" --> 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 12 December 2020. 72 Copyright Notice 74 Copyright (c) 2020 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 . . . . . . . . . . . . . . 24 101 3.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 24 102 3.1.5. Selecting the Best Origin Authentication Mechanism . 25 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 . . . . . . . . . . . . . . . . . . 27 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 8 of [RFC8572]. 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 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 195 module: ietf-sztp-csr 197 augment /ietf-sztp-bootstrap-server:get-bootstrapping-data/ietf-sz\ 198 tp-bootstrap-server:input: 199 +---- csr-support! 200 | +---- key-generation! 201 | | +---- supported-algorithms 202 | | +---- algorithm-identifier* binary 203 | +---- csr-generation 204 | +---- supported-formats 205 | +---- format-identifier* identityref 206 +---- csr! 207 +---- (request-type) 208 +--:(p10) 209 | +---- p10? ietf-crypto-types:csr 210 +--:(cmc) 211 | +---- cmc? binary 212 +--:(cmp) 213 +---- cmp? binary 215 structure: request-info 216 +-- key-generation! 217 | +-- selected-algorithm 218 | +-- algorithm-identifier binary 219 +-- csr-generation 220 | +-- selected-format 221 | +-- format-identifier identityref 222 +-- cert-req-info? binary 224 To further illustrate how the augmentation and structure defined by 225 the "ietf-sztp-csr" module are used, below are two additional tree 226 diagrams showing these nodes placed where they are used. 228 The following tree diagram [RFC8340] illustrates SZTP's "get- 229 bootstrapping-data" RPC with the augmentation in place. 231 module: ietf-sztp-bootstrap-server 233 rpcs: 234 +---x get-bootstrapping-data 235 +---w input 236 | +---w signed-data-preferred? empty 237 | +---w hw-model? string 238 | +---w os-name? string 239 | +---w os-version? string 240 | +---w nonce? binary 241 | +---w sztp-csr:csr-support! 242 | | +---w sztp-csr:key-generation! 243 | | | +---w sztp-csr:supported-algorithms 244 | | | +---w sztp-csr:algorithm-identifier* binary 245 | | +---w sztp-csr:csr-generation 246 | | +---w sztp-csr:supported-formats 247 | | +---w sztp-csr:format-identifier* identityref 248 | +---w sztp-csr:csr! 249 | +---w (sztp-csr:request-type) 250 | +--:(sztp-csr:p10) 251 | | +---w sztp-csr:p10? ct:csr 252 | +--:(sztp-csr:cmc) 253 | | +---w sztp-csr:cmc? binary 254 | +--:(sztp-csr:cmp) 255 | +---w sztp-csr:cmp? binary 256 +--ro output 257 +--ro reporting-level? enumeration {onboarding-server}? 258 +--ro conveyed-information cms 259 +--ro owner-certificate? cms 260 +--ro ownership-voucher? cms 262 The following tree diagram [RFC8340] illustrates RESTCONF's "errors" 263 RPC-reply message with the "request-info" structure in place. 265 module: ietf-restconf 266 +--ro errors 267 +--ro error* [] 268 +--ro error-type enumeration 269 +--ro error-tag string 270 +--ro error-app-tag? string 271 +--ro error-path? instance-identifier 272 +--ro error-message? string 273 +--ro error-info 274 +--ro request-info 275 +--ro key-generation! 276 | +--ro selected-algorithm 277 | +--ro algorithm-identifier binary 278 +--ro csr-generation 279 | +--ro selected-format 280 | +--ro format-identifier identityref 281 +--ro cert-req-info? binary 283 2.2. Example Usage 285 | The examples below are encoded using JSON, but they could 286 | equally well be encoded using XML, as is supported by SZTP. 288 An SZTP-client implementing this specification would signal to the 289 bootstrap server its willingness to generate a CSR by including the 290 "csr-support" node in its "get-bootstrapping-data" RPC, as 291 illustrated below. 293 REQUEST 294 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 296 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 297 ng-data HTTP/1.1 298 HOST: example.com 299 Content-Type: application/yang.data+json 301 { 302 "ietf-sztp-bootstrap-server:input" : { 303 "hw-model": "model-x", 304 "os-name": "vendor-os", 305 "os-version": "17.3R2.1", 306 "nonce": "extralongbase64encodedvalue=", 307 "ietf-sztp-csr:csr-support": { 308 "key-generation": { 309 "supported-algorithms": { 310 "algorithm-identifier": [ 311 "base64encodedvalue1=", 312 "base64encodedvalue2=", 313 "base64encodedvalue3=" 314 ] 315 } 316 }, 317 "csr-generation": { 318 "supported-formats": { 319 "format-identifier": [ 320 "ietf-sztp-csr:p10", 321 "ietf-sztp-csr:cmc", 322 "ietf-sztp-csr:cmp" 323 ] 324 } 325 } 326 } 327 } 328 } 330 Assuming the SZTP-server wishes to prompt the SZTP-client to provide 331 a CSR, then it would respond with an HTTP 400 (Bad Request) error 332 code: 334 RESPONSE 335 HTTP/1.1 400 Bad Request 336 Date: Sat, 31 Oct 2015 17:02:40 GMT 337 Server: example-server 338 Content-Type: application/yang.data+json 340 { 341 "ietf-restconf:errors" : { 342 "error" : [ 343 { 344 "error-type": "application", 345 "error-tag": "missing-attribute", 346 "error-message": "Missing input parameter", 347 "error-info": { 348 "ietf-sztp-csr:request-info": { 349 "key-generation": { 350 "selected-algortithm": { 351 "algorithm-identifier": "base64EncodedValue==" 352 } 353 }, 354 "csr-generation": { 355 "selected-format": { 356 "format-identifier": "ietf-sztp-csr:cmc" 357 } 358 }, 359 "cert-req-info": "base64EncodedValue==" 360 } 361 } 362 } 363 ] 364 } 365 } 367 Upon being prompted to provide a CSR, the SZTP-client would POST 368 another "get-bootstrapping-data" request, but this time including the 369 "csr" node to convey its CSR to the SZTP-server: 371 REQUEST 372 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 374 POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ 375 ng-data HTTP/1.1 376 HOST: example.com 377 Content-Type: application/yang.data+json 379 { 380 "ietf-sztp-bootstrap-server:input" : { 381 "hw-model": "model-x", 382 "os-name": "vendor-os", 383 "os-version": "17.3R2.1", 384 "nonce": "extralongbase64encodedvalue=", 385 "ietf-sztp-csr:csr": { 386 "p10": "base64encodedvalue==" 387 } 388 } 389 } 391 The SZTP-server responds with "onboarding-information" (conveyed 392 encoded inside the "conveyed-information" node) containing a signed 393 identity certificate for the CSR provided by the SZTP-client: 395 RESPONSE 397 HTTP/1.1 200 OK 398 Date: Sat, 31 Oct 2015 17:02:40 GMT 399 Server: example-server 400 Content-Type: application/yang.data+json 402 { 403 "ietf-sztp-bootstrap-server:output" : { 404 "reporting-level": "verbose", 405 "conveyed-information": "base64encodedvalue==" 406 } 407 } 409 How the signed certificate is conveyed inside the onboarding 410 information is outside the scope of this document. Some 411 implementations may choose to convey it inside a script (e.g., SZTP's 412 "pre-configuration-script"), while other implementations convey it 413 inside the SZTP "configuration" node. 415 Following are two examples of conveying the signed certificate inside 416 the "configuration" node. Both examples assume that the SZTP-client 417 understands the "ietf-keystore" module defined in 418 [I-D.ietf-netconf-keystore]. 420 This first example illustrates the case where the signed certificate 421 is for the same asymmetric key used by the SZTP-client's 422 manufacturer-generated identity certificate (e.g., an IDevID). As 423 such, the configuration needs to associate the newly signed 424 certificate with the existing asymmetric key: 426 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 428 { 429 "ietf-keystore:keystore": { 430 "asymmetric-keys": { 431 "asymmetric-key": [ 432 { 433 "name": "Manufacturer-Generated Hidden Key", 434 "public-key-format": "ietf-crypto-types:subject-public-key\ 435 -info-format", 436 "public-key": "base64encodedvalue==", 437 "hidden-private-key": [null], 438 "certificates": { 439 "certificate": [ 440 { 441 "name": "Manufacturer-Generated IDevID Cert", 442 "cert": "base64encodedvalue==" 443 }, 444 { 445 "name": "Newly-Generated LDevID Cert", 446 "cert": "base64encodedvalue==" 447 } 448 ] 449 } 450 } 451 ] 452 } 453 } 454 } 456 This second example illustrates the case where the signed certificate 457 is for a newly generated asymmetric key. As such, the configuration 458 needs to associate the newly signed certificate with the newly 459 generated asymmetric key: 461 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 463 { 464 "ietf-keystore:keystore": { 465 "asymmetric-keys": { 466 "asymmetric-key": [ 467 { 468 "name": "Manufacturer-Generated Hidden Key", 469 "public-key-format": "ietf-crypto-types:subject-public-key\ 470 -info-format", 471 "public-key": "base64encodedvalue==", 472 "hidden-private-key": [null], 473 "certificates": { 474 "certificate": [ 475 { 476 "name": "Manufacturer-Generated IDevID Cert", 477 "cert": "base64encodedvalue==" 478 } 479 ] 480 } 481 }, 482 { 483 "name": "Newly-Generated Hidden Key", 484 "public-key-format": "ietf-crypto-types:subject-public-key\ 485 -info-format", 486 "public-key": "base64encodedvalue==", 487 "hidden-private-key": [null], 488 "certificates": { 489 "certificate": [ 490 { 491 "name": "Newly-Generated LDevID Cert", 492 "cert": "base64encodedvalue==" 493 } 494 ] 495 } 496 } 497 ] 498 } 499 } 500 } 502 In addition to configuring the signed certificate, it is often 503 necessary to also configure the Issuer's signing certificate so that 504 the the device (i.e., STZP-client) can authenticate certificates 505 presented by peer devices signed by the same issuer as its own. 506 While outside the scope of this document, one way to do this would be 507 to use the "ietf-truststore" module defined in 508 [I-D.ietf-netconf-trust-anchors]. 510 2.3. YANG Module 512 This module augments an RPC defined in [RFC8572], uses a data type 513 defined in [I-D.ietf-netconf-crypto-types], has an normative 514 references to [RFC2986] and [ITU.X690.2015], and an informative 515 reference to [Std-802.1AR-2018]. 517 file "ietf-sztp-csr@2020-06-10.yang" 519 module ietf-sztp-csr { 520 yang-version 1.1; 521 namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; 522 prefix sztp-csr; 524 import ietf-sztp-bootstrap-server { 525 prefix sztp-svr; 526 reference "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 527 } 529 import ietf-yang-structure-ext { 530 prefix sx; 531 reference "RFC BBBB:YANG Data Structure Extensions"; 532 } 534 import ietf-crypto-types { 535 prefix ct; 536 reference "RFC AAAA: Common YANG Data Types for Cryptography"; 537 } 539 organization 540 "IETF NETCONF (Network Configuration) Working Group"; 542 contact 543 "WG Web: http://tools.ietf.org/wg/netconf 544 WG List: 545 Authors: Kent Watsen 546 Russ Housley 547 Sean Turner "; 549 description 550 "This module augments the 'get-bootstrapping-data' RPC, 551 defined in the 'ietf-sztp-bootstrap-server' module from 552 SZTP (RFC 8572), enabling the SZTP-client to obtain a 553 signed identity certificate (e.g., an LDevID from IEEE 554 802.1AR) as part of the SZTP 'onboarding-information' 555 response. 557 Copyright (c) 2020 IETF Trust and the persons identified 558 as authors of the code. All rights reserved. 560 Redistribution and use in source and binary forms, with 561 or without modification, is permitted pursuant to, and 562 subject to the license terms contained in, the Simplified 563 BSD License set forth in Section 4.c of the IETF Trust's 564 Legal Provisions Relating to IETF Documents 565 (https://trustee.ietf.org/license-info). 567 This version of this YANG module is part of RFC XXXX 568 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 569 itself for full legal notices. 571 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 572 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 573 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 574 document are to be interpreted as described in BCP 14 575 (RFC 2119) (RFC 8174) when, and only when, they appear 576 in all capitals, as shown here."; 578 revision 2020-06-10 { 579 description 580 "Initial version"; 581 reference 582 "RFC XXXX: Conveying a Certificate Signing Request (CSR) 583 in a Secure Zero Touch Provisioning (SZTP) 584 Bootstrapping Request"; 585 } 587 identity certificate-request-format { 588 description 589 "A base identity for the request formats supported 590 by the SZTP-client. 592 Additional derived identities MAY be defined by 593 future efforts."; 594 } 596 identity p10 { 597 base "certificate-request-format"; 598 description 599 "Indicates that the SZTP-client supports generating 600 requests using the 'CertificationRequest' structure 601 defined in RFC 2986."; 602 reference 603 "RFC 2986: PKCS #10: Certification Request Syntax 604 Specification Version 1.7"; 605 } 606 identity cmc { 607 base "certificate-request-format"; 608 description 609 "Indicates that the SZTP-client supports generating 610 requests using a constrained version of the 'Full 611 PKI Request' structure defined in RFC 5272."; 612 reference 613 "RFC 5272: Certificate Management over CMS (CMC)"; 614 } 616 identity cmp { 617 base "certificate-request-format"; 618 description 619 "Indicates that the SZTP-client supports generating 620 requests that contain a PKCS#10 Certificate Signing 621 Request (p10cr), as defined in RFC 2986, encapsulated 622 in a Nested Message Content (nested), as defined in 623 RFC 4210."; 624 reference 625 "RFC 2986: PKCS #10: Certification Request Syntax 626 Specification Version 1.7 627 RFC 4210: Internet X.509 Public Key Infrastructure 628 Certificate Management Protocol (CMP)"; 629 } 631 // Protocol-accessible nodes 633 augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { 635 description 636 "This augmentation adds the 'csr-support' and 'csr' nodes to 637 the SZTP (RFC 8572) 'get-bootstrapping-data' request message, 638 enabling the SZTP-client to obtain an identity certificate 639 (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding 640 information response provided by the SZTP-server. 642 The 'csr-support' node enables the SZTP-client to indicate 643 that it supports generating certificate signing requests 644 (CSRs), and to provide details around the CSRs it is able 645 to generate. 647 The 'csr' node enables the SZTP-client to relay a CSR to 648 the SZTP-server."; 650 reference 651 "IEEE 802.1AR: IEEE Standard for Local and metropolitan 652 area networks - Secure Device Identity 654 RFC 8572: Secure Zero Touch Provisioning (SZTP)"; 656 container csr-support { 657 presence 658 "Indicates that the SZTP-client is capable of sending CSRs."; 659 description 660 "The 'csr-support' node enables the SZTP-client to indicate 661 that it supports generating certificate signing requests 662 (CSRs), and to provide details around the CSRs it is able 663 to generate. 665 When present, the SZTP-server MAY respond with the HTTP 666 error 400 (Bad Request) with an 'ietf-restconf:errors' 667 document having the 'error-tag' value 'missing-attribute' 668 and the 'error-info' node containing the 'request-info' 669 structure described in this module."; 670 container key-generation { 671 presence 672 "Indicates that the SZTP-client is capable of 673 generating a new asymmetric key pair. 675 If this node is not present, the SZTP-server MAY 676 request a CSR using the asymmetric key associated 677 with the device's existing identity certificate 678 (e.g., an LDevID from IEEE 802.1AR)."; 679 description 680 "Specifies details for the SZTP-client's ability to 681 generate a new asymmetric key pair."; 682 container supported-algorithms { 683 description 684 "A list of public key algorithms supported by the 685 SZTP-client for generating a new key."; 686 leaf-list algorithm-identifier { 687 type binary; 688 min-elements 1; 689 description 690 "An AlgorithmIdentifier, as defined in RFC 2986, 691 encoded using ASN.1 distinguished encoding rules 692 (DER), as specified in ITU-T X.690."; 693 reference 694 "RFC 2986: PKCS #10: Certification Request Syntax 695 Specification Version 1.7 696 ITU-T X.690: 697 Information technology - ASN.1 encoding rules: 698 Specification of Basic Encoding Rules (BER), 699 Canonical Encoding Rules (CER) and Distinguished 700 Encoding Rules (DER)."; 701 } 703 } 704 } 705 container csr-generation { 706 description 707 "Specifies details for the SZTP-client's ability to 708 generate a certificate signing requests."; 709 container supported-formats { 710 description 711 "A list of certificate request formats supported 712 by the SZTP-client for generating a new key."; 713 leaf-list format-identifier { 714 type identityref { 715 base certificate-request-format; 716 } 717 min-elements 1; 718 description 719 "A certificate request format supported by the 720 SZTP-client."; 721 } 722 } 723 } 724 } 726 container csr { 727 presence 728 "Indicates that the SZTP-client has sent a CSR."; 729 description 730 "The 'csr' node enables the SZTP-client to convey 731 a certificate signing request, using the encoding 732 format selected by the SZT-server's 'request-info' 733 response to the SZTP-client's previously sent 734 'get-bootstrapping-data' request containing the 735 'csr-support' node. 737 When present, the SZTP-server SHOULD respond with 738 an SZTP 'onboarding-information' message containing 739 a signed certificate for the conveyed CSR. The 740 SZTP-server MAY alternatively respond with another 741 HTTP error containing another 'request-info', in 742 which case the SZTP-client MUST invalidate the CSR 743 sent in this node."; 744 choice request-type { 745 mandatory true; 746 description 747 "A choice amongst certificate signing request formats. 749 Additional formats MAY be augmented into this 'choice' 750 statement by future efforts."; 752 case p10 { 753 leaf p10 { 754 type ct:csr; 755 description 756 "A CertificationRequest structure, per RFC 2986. 757 Please see 'csr' in RFC AAAA for encoding details."; 758 reference 759 "RFC 2986: 760 PKCS #10: Certification Request Syntax Specification 761 RFC AAAA: 762 Common YANG Data Types for Cryptography"; 763 } 764 } 765 case cmc { 766 leaf cmc { 767 type binary; 768 description 769 "A constrained version of the 'Full PKI Request' 770 message defined in RFC 5272, encoded using ASN.1 771 distinguished encoding rules (DER), as specified 772 in ITU-T X.690. 774 For asymmetric key-based origin authentication 775 of a CSR based on the IDevID's private key for the 776 associated IDevID's public key, the PKIData contains 777 one reqSequence element and no controlSequence, 778 cmsSequence, or otherMsgSequence elements. The 779 reqSequence is the TaggedRequest and it is the tcr 780 CHOICE. The tcr is the TaggedCertificationRequest 781 and it a bodyPartId and the certificateRequest 782 elements. The certificateRequest is signed with 783 the IDevID's private key. 785 For asymmetric key-based origin authentication 786 based on the IDevID's private key that encapsulates 787 a CSR signed by the LDevID's private key, the 788 PKIData contains one cmsSequence element and no 789 controlSequence, reqSequence, or otherMsgSequence 790 elements. The cmsSequence is the TaggedContentInfo 791 and it includes a bodyPartID element and a 792 contentInfo. The contentInfo is a SignedData 793 encapsulating a PKIData with one reqSequence 794 element and no controlSequence, cmsSequence, or 795 otherMsgSequence elements. The reqSequence is 796 the TaggedRequest and it is the tcr CHOICE. The 797 tcr is the TaggedCertificationRequest and it a 798 bodyPartId and the certificateRequest elements. 799 The certificateRequest is signed with the LDevID's 800 private key. 802 For shared secret-based origin authentication of 803 a CSR signed by the LDevID's private key, the 804 PKIData contains one cmsSequence element and no 805 controlSequence, reqSequence, or otherMsgSequence 806 elements. The cmsSequence is the TaggedContentInfo 807 and it includes a bodyPartID element and a 808 contentInfo. The contentInfo is an AuthenticatedData 809 encapsulating a PKIData with one reqSequence 810 element and no controlSequence, cmsSequence, or 811 otherMsgSequence elements. The reqSequence is the 812 TaggedRequest and it is the tcr CHOICE. The tcr 813 is the TaggedCertificationRequest and it a 814 bodyPartId and the certificateRequest elements. 815 The certificateRequest is signed with the LDevID's 816 private key."; 817 reference 818 "RFC 5272: Certificate Management over CMS (CMC) 819 ITU-T X.690: 820 Information technology - ASN.1 encoding rules: 821 Specification of Basic Encoding Rules (BER), 822 Canonical Encoding Rules (CER) and Distinguished 823 Encoding Rules (DER)."; 824 } 825 } 826 case cmp { 827 leaf cmp { 828 type binary; 829 description 830 "A PKIMessage structure, as defined in RFC 4210, 831 encoded using ASN.1 distinguished encoding rules 832 (DER), as specified in ITU-T X.690. 834 The PKIMessage structure contains a PKCS#10 835 Certificate Signing Request (p10cr), as defined in 836 RFC 2986, encapsulated in a Nested Message Content 837 (nested) structure, as defined in RFC 4210.”; 839 For asymmetric key-based origin authentication of 840 a CSR based on the IDevID's private key for the 841 associated IDevID's public key, PKIMessages contains 842 one PKIMessage with one body element, a header 843 element that is an empty sequence, and no protection 844 or extraCerts elements. The body element contains a 845 p10cr CHOICE. 847 For asymmetric key-based origin authentication based 848 on the IDevID's private key that encapsulates a CSR 849 signed by the LDevID's private key, PKIMessages 850 contains one PKIMessage with one header element, 851 one body element, one protection element, and one 852 extraCerts element. The header element contains 853 pvno, sender, recipient, and protectionAlg elements 854 and no other elements. The body element contains the 855 nested CHOICE. The nested element's PKIMessages 856 contains one PKIMessage with one body element, one 857 header element that is an empty sequence, and no 858 protection or extraCerts elements. The nested 859 element's body element contains a p10cr CHOICE. The 860 protection element contains the digital signature 861 generated with the IDevID's private key. The 862 extraCerts element contains the IDevID certificate. 864 For shared secret-based origin authentication of a 865 CSR signed by the LDevID's private key, PKIMessages 866 contains one PKIMessage with one header element, 867 one body element, one protection element, and no 868 extraCerts element. The header element contains 869 pvno, sender, recipient, and protectionAlg elements 870 and no other elements. The body element contains 871 the nested CHOICE. The nested element's PKIMessages 872 contains one PKIMessage with one body element, one 873 header element that is an empty sequence, and no 874 protection or extraCerts elements. The body element 875 contains a p10cr CHOICE. The protection element 876 contains the MAC value generated with the shared 877 secret."; 878 reference 879 "RFC 2986: 880 PKCS #10: Certification Request Syntax 881 Specification Version 1.7 882 RFC 4210: 883 Internet X.509 Public Key Infrastructure 884 Certificate Management Protocol (CMP) 885 ITU-T X.690: 886 Information technology - ASN.1 encoding rules: 887 Specification of Basic Encoding Rules (BER), 888 Canonical Encoding Rules (CER) and Distinguished 889 Encoding Rules (DER)."; 890 } 891 } 892 } 893 } 894 } 895 sx:structure request-info { 896 container key-generation { 897 presence 898 "Indicates that the SZTP-client is to generate a new 899 asymmetric key. If missing, then the SZTP-client 900 MUST reuse the key associated with its existing 901 identity certificate (e.g., IDevID). 903 This leaf MUST only appear if the SZTP-clients 904 'csr-support' included the 'key-generation' node."; 905 description 906 "Specifies details for the key that the SZTP-client 907 is to generate."; 908 container selected-algorithm { 909 description 910 "The key algorithm selected by the SZTP-server. The 911 algorithm MUST be one of the algorithms specified 912 by the 'supported-algorithms' node in the 913 SZTP-client's request message."; 914 leaf algorithm-identifier { 915 type binary; 916 mandatory true; 917 description 918 "An AlgorithmIdentifier, as defined in RFC 2986, 919 encoded using ASN.1 distinguished encoding rules 920 (DER), as specified in ITU-T X.690."; 921 reference 922 "RFC 2986: PKCS #10: Certification Request Syntax 923 Specification Version 1.7 924 ITU-T X.690: 925 Information technology - ASN.1 encoding rules: 926 Specification of Basic Encoding Rules (BER), 927 Canonical Encoding Rules (CER) and Distinguished 928 Encoding Rules (DER)."; 929 } 930 } 931 } 932 container csr-generation { 933 description 934 "Specifies details for the CSR that the SZTP-client 935 is to generate."; 936 container selected-format { 937 description 938 "The CSR format selected by the SZTP-server. The 939 format MUST be one of the formats specified by 940 the 'supported-formats' node in the SZTP-client's 941 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 binary; 955 description 956 "A CertificationRequestInfo structure, as defined in 957 RFC 2986, encoded using ASN.1 distinguished encoding 958 rules (DER), as specified in ITU-T X.690. 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 another 400 (Bad Request) response. 970 When not provided, the SZTP-client SHOULD generate a 971 CSR using the same structure defined in its existing 972 identity certificate (e.g., IDevID). 974 It is an error if the 'AlgorithmIdentifier' field 975 contained inside the 'SubjectPublicKeyInfo' field 976 does not match the algorithm identified by the 977 'selected-algorithm' node."; 978 reference 979 "RFC 2986: PKCS #10: Certification Request Syntax 980 Specification Version 1.7 981 ITU-T X.690: 982 Information technology - ASN.1 encoding rules: 983 Specification of Basic Encoding Rules (BER), 984 Canonical Encoding Rules (CER) and Distinguished 985 Encoding Rules (DER)."; 986 } 987 } 988 } 990 992 3. Security Considerations 994 This document builds on top of the solution presented in [RFC8572] 995 and therefore all the Security Considerations discussed in RFC 8572 996 apply here as well. 998 3.1. SZTP-Client Considerations 1000 3.1.1. Ensuring the Integrity of Asymmetric Private Keys 1002 The private key the SZTP-client uses for the dynamically-generated 1003 identity certificate MUST be protected from inadvertent disclosure in 1004 order to prevent identity fraud. 1006 The security of this private key is essential in order to ensure the 1007 associated identity certificate can be used as a root of trust. 1009 It is RECOMMENDED that devices are manufactured with an HSM (hardware 1010 security module), such as a TPM (trusted platform module), to 1011 generate and forever contain the private key within the security 1012 perimeter of the HSM. In such cases, the private key, and its 1013 associated certificates, MAY have long validity periods. 1015 In cases where the device does not possess an HSM, or otherwise is 1016 unable to use an HSM for the private key, it is RECOMMENDED to 1017 regenerate the private key (and associated identity certificates) 1018 periodically. Details for how to generate a new private key and 1019 associate a new identity certificate are outside the scope of this 1020 document. 1022 3.1.2. Reuse of a Manufacturer-generated Private Key 1024 It is RECOMMENDED in [RFC8572] that devices are shipped from 1025 manufacturing with a secure device identity certificate (e.g., an 1026 IDevID, from [Std-802.1AR-2018]). It is also RECOMMENDED that the 1027 private key for these necessarily long-lived certificates be stored 1028 in an HSM, such as a TPM. Lastly, per the previous consideration, 1029 when devices generate a new private key, it is also RECOMMENDED that 1030 the private key is protected by the HSM. 1032 However, it is understood that space on an HSM chip may be limited, 1033 potentially to the point of not being able to store an additional 1034 private key for the CSR described in this document, and that it may 1035 not be possible to store hardware-protected keys outside the TPM 1036 (e.g., a TPM-encrypted key stored in non-volatile memory). In such 1037 cases, it is RECOMMENDED to reuse the existing hardware-protected 1038 private key rather than generate a second private key outside of 1039 protection afforded by the hardware. 1041 3.1.3. Replay Attack Protection 1043 This RFC enables an SZTP-client to announce an ability to generate 1044 new key to use for its CSR. 1046 When the SZTP-server responds with a request for the device to 1047 generate a new key, it is essential that the device actually 1048 generates a new key. 1050 Generating a new key each time enables the random bytes used to 1051 create the key to serve the dual-purpose of also acting like a 1052 "nonce" used in other mechanisms to detect replay attacks. 1054 When a fresh public/private key pair is generated for the request, 1055 confirmation to the SZTP-client that the response has not been 1056 replayed is enabled by the SZTP-client's fresh public key appearing 1057 in the signed certificate provided by the SZTP-server. 1059 When a public/private key pair associated with the IDevID used for 1060 the request, there may not be confirmation to the SZTP-client that 1061 the response has not been replayed; however, the worst case result is 1062 a lost certificate that is associated to the private key known only 1063 to the SZTP-client. 1065 3.1.4. Connecting to an Untrusted Bootstrap Server 1067 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1068 by blindly authenticating the SZTP-server's TLS end-entity 1069 certificate. 1071 As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- 1072 client MUST assert that the bootstrapping data returned is signed, if 1073 the SZTP-client is to trust it. 1075 However, the HTTP error message used in this document cannot be 1076 signed data, as described in RFC 8572. 1078 Therefore, the solution presented in this document cannot be used 1079 when the SZTP-client connects to an untrusted SZTP-server. 1081 Consistent with the recommendation presented in Section 9.6 of 1082 [RFC8572], SZTP-clients SHOULD NOT passed the "csr-support" input 1083 parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass 1084 instead the "signed-data-preferred" input parameter, as discussed in 1085 Appendix B of [RFC8572]. 1087 3.1.5. Selecting the Best Origin Authentication Mechanism 1089 When generating a new key, it is important that the client be able to 1090 provide additional proof to the CA that it was the entity that 1091 generated the key. 1093 All of the certificate request formats defined in this document 1094 (e.g., CMS, CMP, etc.), not including a raw PKCS#10, support origin 1095 authentication. 1097 These formats support origin authentication using both PKI and shared 1098 secret. 1100 Typically only one possible origin authentication mechanism can 1101 possibly be used but, in the case that the SZTP-client authenticates 1102 itself using both TLS-level (e.g., IDevID) and HTTP-level credentials 1103 (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the 1104 SZTP-client may need to choose between the two options. 1106 In the case the SZTP-client must choose between the asymmetric key 1107 option versus a shared secret for origin authentication, it is 1108 RECOMMENDED that the SZTP-client choose using the asymmetric key 1109 option. 1111 3.1.6. Clearing the Private Key and Associated Certificate 1113 Unlike a manufacturer-generated identity certificate (e.g., IDevID), 1114 the deployment-generated identity certificate (e.g., LDevID) and the 1115 associated private key (assuming a new private key was generated for 1116 the purpose), are considered user data and SHOULD be cleared whenever 1117 the device is reset to its factory default state, such as by the 1118 "factory-reset" RPC defined in [I-D.ietf-netmod-factory-default]. 1120 3.2. SZTP-Server Considerations 1122 3.2.1. Conveying Proof of Possession to a CA 1124 3.2.2. Supporting SZTP-Clients that don't trust the SZTP-Server 1126 [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, 1127 by blindly authenticating the SZTP-server's TLS end-entity 1128 certificate. 1130 As is recommended in Section 3.1.4 in this document, in such cases, 1131 SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. 1133 The reciprocal of this statement is that SZTP-servers, wanting to 1134 support SZTP-clients that don't trust them, SHOULD support the 1135 "signed-data-preferred" input parameter, as discussed in Appendix B 1136 of [RFC8572]. 1138 3.2.3. YANG Module Considerations 1140 The recommended format for documenting the Security Considerations 1141 for YANG modules is described in Section 3.7 of [RFC8407]. However, 1142 the module defined in this document only augments two input 1143 parameters into the "get-bootstrapping-data" RPC in [RFC8572], and 1144 therefore only needs to point to the relevant Security Considerations 1145 sections in that RFC. 1147 * Security considerations for the "get-bootstrapping-data" RPC are 1148 described in Section 9.16 of [RFC8572]. 1150 * Security considerations for the "input" parameters passed inside 1151 the "get-bootstrapping-data" RPC are described in Section 9.6 of 1152 [RFC8572]. 1154 4. IANA Considerations 1156 4.1. The IETF XML Registry 1158 This document registers one URI in the "ns" subregistry of the IETF 1159 XML Registry [RFC3688] maintained at 1160 https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. 1161 Following the format in [RFC3688], the following registration is 1162 requested: 1164 URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1165 Registrant Contact: The NETCONF WG of the IETF. 1166 XML: N/A, the requested URI is an XML namespace. 1168 4.2. The YANG Module Names Registry 1170 This document registers one YANG module in the YANG Module Names 1171 registry [RFC6020] maintained at https://www.iana.org/assignments/ 1172 yang-parameters/yang-parameters.xhtml. Following the format defined 1173 in [RFC6020], the below registration is requested: 1175 name: ietf-sztp-csr 1176 namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr 1177 prefix: sztp-csr 1178 reference: RFC XXXX 1180 5. References 1181 5.1. Normative References 1183 [I-D.ietf-netconf-crypto-types] 1184 Watsen, K., "Common YANG Data Types for Cryptography", 1185 Work in Progress, Internet-Draft, draft-ietf-netconf- 1186 crypto-types-15, 20 May 2020, 1187 . 1190 [ITU.X690.2015] 1191 International Telecommunication Union, "Information 1192 Technology - ASN.1 encoding rules: Specification of Basic 1193 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1194 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1195 X.690, ISO/IEC 8825-1, August 2015, 1196 . 1198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1199 Requirement Levels", BCP 14, RFC 2119, 1200 DOI 10.17487/RFC2119, March 1997, 1201 . 1203 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1204 Request Syntax Specification Version 1.7", RFC 2986, 1205 DOI 10.17487/RFC2986, November 2000, 1206 . 1208 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1209 the Network Configuration Protocol (NETCONF)", RFC 6020, 1210 DOI 10.17487/RFC6020, October 2010, 1211 . 1213 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1214 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1215 . 1217 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1218 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1219 May 2017, . 1221 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1222 Touch Provisioning (SZTP)", RFC 8572, 1223 DOI 10.17487/RFC8572, April 2019, 1224 . 1226 5.2. Informative References 1228 [I-D.ietf-netconf-keystore] 1229 Watsen, K., "A YANG Data Model for a Keystore", Work in 1230 Progress, Internet-Draft, draft-ietf-netconf-keystore-17, 1231 20 May 2020, . 1234 [I-D.ietf-netconf-trust-anchors] 1235 Watsen, K., "A YANG Data Model for a Truststore", Work in 1236 Progress, Internet-Draft, draft-ietf-netconf-trust- 1237 anchors-10, 20 May 2020, . 1240 [I-D.ietf-netmod-factory-default] 1241 WU, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for 1242 Factory Default Settings", Work in Progress, Internet- 1243 Draft, draft-ietf-netmod-factory-default-15, 25 April 1244 2020, . 1247 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1248 DOI 10.17487/RFC3688, January 2004, 1249 . 1251 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1252 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1253 . 1255 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1256 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1257 DOI 10.17487/RFC8407, October 2018, 1258 . 1260 [Std-802.1AR-2018] 1261 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 1262 metropolitan area networks - Secure Device Identity", 14 1263 June 2018, . 1266 Authors' Addresses 1268 Kent Watsen 1269 Watsen Networks 1271 Email: kent+ietf@watsen.net 1272 Russ Housley 1273 Vigil Security, LLC 1275 Email: housley@vigilsec.com 1277 Sean Turner 1278 sn3rd 1280 Email: sean@sn3rd.com