--- 1/draft-ietf-lamps-lightweight-cmp-profile-09.txt 2022-02-01 07:16:35.295835843 -0800 +++ 2/draft-ietf-lamps-lightweight-cmp-profile-10.txt 2022-02-01 07:16:35.491840741 -0800 @@ -1,19 +1,19 @@ LAMPS Working Group H. Brockhaus, Ed. Internet-Draft D. von Oheimb Intended status: Standards Track S. Fries -Expires: 20 June 2022 Siemens - 17 December 2021 +Expires: 5 August 2022 Siemens + 1 February 2022 Lightweight Certificate Management Protocol (CMP) Profile - draft-ietf-lamps-lightweight-cmp-profile-09 + draft-ietf-lamps-lightweight-cmp-profile-10 Abstract This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and IoT scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices @@ -30,61 +30,61 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 20 June 2022. + This Internet-Draft will expire on 5 August 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 1.2. Motivation for a lightweight profile of CMP . . . . . . . 5 1.3. Special requirements of industrial and IoT scenarios . . 6 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7 1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7 1.6. Compatibility with existing CMP profiles . . . . . . . . 8 - 1.7. Scope of this document . . . . . . . . . . . . . . . . . 9 + 1.7. Scope of this document . . . . . . . . . . . . . . . . . 10 1.8. Structure of this document . . . . . . . . . . . . . . . 10 1.9. Convention and Terminology . . . . . . . . . . . . . . . 11 2. Solution architecture . . . . . . . . . . . . . . . . . . . . 12 - 3. Generic aspects of the PKI message . . . . . . . . . . . . . 13 - 3.1. General description of the CMP message header . . . . . . 14 - 3.2. General description of the CMP message protection . . . . 16 + 3. Generic aspects of the PKI message . . . . . . . . . . . . . 14 + 3.1. General description of the CMP message header . . . . . . 15 + 3.2. General description of the CMP message protection . . . . 17 3.3. General description of CMP message extraCerts . . . . . . 17 - 3.4. Generic PKI management operation prerequisites . . . . . 17 + 3.4. Generic PKI management operation prerequisites . . . . . 18 3.5. Generic validation of a PKI message . . . . . . . . . . . 19 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 21 3.6.1. Reporting error conditions upstream . . . . . . . . . 21 3.6.2. Reporting error conditions downstream . . . . . . . . 22 3.6.3. Handling error conditions on nested messages used for batching . . . . . . . . . . . . . . . . . . . . . . 22 - 3.6.4. Reporting error conditions . . . . . . . . . . . . . 22 + 3.6.4. Reporting error conditions . . . . . . . . . . . . . 23 4. End Entity PKI management operations . . . . . . . . . . . . 24 4.1. Requesting a new certificate from a PKI . . . . . . . . . 27 4.1.1. Requesting a certificate from a new PKI with signature-based protection . . . . . . . . . . . . . 28 4.1.2. Requesting an additional certificate with signature-based protection . . . . . . . . . . . . . 34 4.1.3. Updating an existing certificate with signature protection . . . . . . . . . . . . . . . . . . . . . 35 4.1.4. Requesting a certificate from a legacy PKI using a PKCS#10 request . . . . . . . . . . . . . . . . . . . 36 @@ -303,29 +303,31 @@ UNISIG has included a CMP profile for enrollment of TLS certificates in the Subset-137 specifying the ETRAM/ETCS on-line key management for train control systems [UNISIG.Subset-137] in 2015. Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI management operations for unattended devices and services. 1.5. Use of CMP in SZTP and BRSKI environments - In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments, - SZTP-CSR [I-D.ietf-netconf-sztp-csr] includes certificate signing - requests (CSR) in device bootstrapping to obtain a public-key + In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other + environments using NETCONF/YANG modules, SZTP-CSR + [I-D.ietf-netconf-sztp-csr] offers a YANG module that includes + different types of certificate requests to obtain a public-key certificate for a locally generated key pair. One option is using a - CMP p10cr message. Such a CSR is of form ietf-sztp-types:cmp-csr - from module ietf-sztp-csr. To allow PKI management entities to also - comply with this profile, the p10cr message must be formatted by the - EE as described in Section 4.1.4 of this profile, and it may be - forwarded as specified in Section 5.2. + CMP p10cr message. Such a message is of the form ietf-ztp-types:cmp- + csr from module ietf-ztp-csr and offers both proof-of-possession and + proof-of-identity. To allow PKI management entities to also comply + with this profile, the p10cr message must be formatted by the EE as + described in Section 4.1.4 of this profile, and it may be forwarded + as specified in Section 5.2. In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous Enrollment [I-D.ietf-anima-brski-async-enroll] describes a generalization regarding the employed enrollment protocols to allow alternatives to EST [RFC7030]. For the use of CMP, it requires adherence to this profile. 1.6. Compatibility with existing CMP profiles @@ -846,26 +849,21 @@ specific name patterns for subject DN or SAN portions that may identify an RA, and/or by having a dedicated root CA usable only for authenticating PKI management entities. * Each PKI management entity MUST have sufficient information to be able to authorize the downstream PKI entity requesting the PKI management operation. Note: For authorizing an RA the same examples apply as above. The authorization of EEs can be very specific to the application - domain and may involve information from configuration or inventory - database. It may involve, e.g., the issuer information of the EE - certificate, specific contents of the CMP protection certificate - used by the EE such as name patterns of subject DN or SAN - portions, shared secret information, and other types of - credentials and evidence potentially communicated out-of-band. + domain based on local PKI policy. 3.5. Generic validation of a PKI message This section describes generic validation steps of each PKI entity receiving a PKI request or response message before any further processing or forwarding. If a PKI management entity decides to terminate a PKI management operation because a check failed, it MUST send a negative response or an error message as described in Section 3.6. The PKIFailureInfo bits given below in parentheses MAY be used in the failInfo field of the PKIStatusInfo as described in @@ -1005,21 +1002,21 @@ according to the checks described in Section 3.5 it MUST report them downstream in the form of an error message as described in Section 3.6.4. 3.6.3. Handling error conditions on nested messages used for batching Batching of messages using nested messages as described in Section 5.2.2.2 requires special error handling. If the error condition is on an upstream nested message containing - batched requests, it MUST not attempt to respond to the individual + batched requests, it MUST NOT attempt to respond to the individual requests included in it. In case a PKI management entity receives an error message in response to a nested message, it must propagate the error by responding with an error message to each of the request messages contained in the nested message. In case a PKI management entity detects an error condition on the downstream nested message received in response to a nested message sent before, it MAY ignore this error condition and handle the @@ -1245,24 +1243,24 @@ potentially intended restrictions of the key usage. Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 [NIST.SP.800-57p1r5] the newly generated private key MAY be used for self-signature, if technically possible, even if the keyUsage extension requested in the certificate request prohibits generation of digital signatures. The requesting EE provides the binding of the proof-of-possession to its identity by signature-based or MAC-based protection of the CMP - request message containing that POP. As detailed in Section 5.1.1 - and Section 5.1.2, an upstream PKI management entity should verify - whether this EE is authorized to obtain a certificate with the - requested subject and other fields and extensions. + request message containing that POP. An upstream PKI management + entity should verify whether this EE is authorized to obtain a + certificate with the requested subject and other fields and + extensions. The EE MAY indicate the certificate profile to use in the certProfile extension of the generalInfo field in the PKIHeader of the certificate request message as described in Section 3.1. In case the EE receives a CA certificate in the caPubs field for installation as a new trust anchor, it MUST properly authenticate the message and authorize the sender as trusted source of the new trust anchor. This authorization is typically indicated using shared secret information for protecting an initialization response (ir) @@ -2819,21 +2817,21 @@ -- As described in Section 3.2 -- MUST use the same credentials as in the first response -- message of the PKI management operation extraCerts RECOMMENDED -- As described in Section 3.3 -- MAY be omitted if the message size is critical and the EE has -- cached the extraCerts from the first response message of -- the PKI management operation - Final response – any type of response message + Final response - any type of response message Field Value header -- MUST be the header as described for the response message -- of the respective PKI management operation body -- The response of the PKI management entity to the initial @@ -3018,26 +3016,23 @@ message if this is technically necessary. Concrete PKI system specifications may define in more detail when to do so. This is particularly relevant in the upstream communication of a request message. Each forwarding PKI management entity has one or more functionalities. It may * verify the identities of EEs and make authorization decisions for - certification request processing based on specific knowledge of - the local setup, e.g., by consulting an inventory or asset - management system, + certification request processing based on local PKI policy, * add or modify fields of certificate request messages, - * store data from a message in a database for later usage or audit purposes, * provide traversal of a network boundary, * replace a MAC-based protection by a signature-based protection that can be verified also further upstream, * double-check if the messages transferred back and forth are properly protected and well-formed, @@ -3175,23 +3170,23 @@ The PKI management entity responding to the request contained in the nested message sends the response message as described in Section 5.1, without wrapping it in a nested message. Note: This form of nesting messages is characterized by the fact that the transactionID in the header of the nested message is the same as the one used in the included message. Specific prerequisites augmenting the prerequisites in Section 3.4: - * The PKI management entity MUST have the authorization to perform - the validation and approval of the respective request according to - the PKI policies. + * The PKI management entity MUST be able to validate the respective + request and have the authorization to perform approval of the + request according to the PKI policies. Message flow: Step# PKI management entity PKI management entity 1 format nested 2 -> nested -> 3 handle or forward nested 4 format or receive response 5 <- response <- 6 forward response @@ -3310,45 +3305,45 @@ This variant of forwarding a message means that a PKI management entity forwards a CMP message with or without modifying the message header or body while preserving any included proof-of-possession. In case the PKI management entity breaks an existing proof-of- possession, the message adaptation described in Section 5.2.3.2 needs to be applied instead. Specific prerequisites augmenting the prerequisites in Section 3.4: - * The PKI management entity MUST have the authorization to perform - the validation and approval of the respective request according to - the PKI policies. + * The PKI management entity MUST be able to validate the respective + request and have the authorization to perform approval of the + request according to the PKI policies. 5.2.3.2. Breaking proof-of-possession This variant of forwarding a message needs to be used if a PKI management entity breaks a signature-based proof-of-possession in a certificate request message, for instance because it forwards an ir or cr message with modifications of the certTemplate, i.e., modification, addition, or removal of fields. The PKI management entity MUST verify the proof-of-possession contained in the original message using the included public key. If successful, the PKI management entity MUST change the popo field value to raVerified. Specific prerequisites augmenting the prerequisites in Section 3.4: - * The PKI management entity MUST have the authorization to verify - the proof-of-possession. + * The PKI management entity MUST be authorized to replace the proof- + of-possession (after verifying it) with raVerified. - * The PKI management entity MUST have the authorization to perform - the validation and approval of the respective request according to - the PKI policies. + * The PKI management entity MUST be able to validate the respective + request and have the authorization to perform approval of the + request according to the PKI policies. The new popo field MUST contain the raVerified choice in the certReq structure of the modified message as follows: popo raVerified REQUIRED -- MUST have the value NULL and indicates that the PKI -- management entity verified the popo of the original message 5.3. Acting on behalf of other PKI entities @@ -3535,22 +3530,22 @@ keys, also confidentiality is a must. These goals are sufficiently achieved by CMP itself, also in an end-to-end fashion. If a second line of defense is required or general privacy concerns exist, TLS can be used to provide confidentiality on a hop-by-hop basis. TLS SHOULD be used with certificate-based authentication to further protect the HTTP transfer as described in [RFC2818]. The CMP transfer via HTTPS MUST use TLS server authentication and SHOULD use TLS client authentication. - Note: The requirements for checking certificates given in [RFC5280], - [RFC5246], and [RFC8446] MUST be followed for the TLS layer. + Note: The requirements for checking certificates given in [RFC5280] + and either [RFC5246] or [RFC8446] MUST be followed for the TLS layer. Certificate status checking SHOULD be used for the TLS certificates of all communication partners. TLS with mutual authentication based on shared secret information MAY be used in case no suitable certificates for certificate-based authentication are available, e.g., a PKI management operation with MAC-based protection is used. Note: The entropy of the shared secret information is crucial for the level of protection available using shard secret information-based @@ -3890,30 +3885,30 @@ Sahni, M. and S. Tripathi, "CoAP Transfer for the Certificate Management Protocol", Work in Progress, Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 November 2021, . [I-D.ietf-lamps-cmp-algorithms] Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, "Certificate Management Protocol (CMP) Algorithms", Work in Progress, Internet-Draft, draft-ietf-lamps-cmp- - algorithms-08, 17 November 2021, + algorithms-09, 22 December 2021, . + cmp-algorithms-09>. [I-D.ietf-lamps-cmp-updates] Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate Management Protocol (CMP) Updates", Work in Progress, - Internet-Draft, draft-ietf-lamps-cmp-updates-15, 17 - December 2021, . + Internet-Draft, draft-ietf-lamps-cmp-updates-17, 12 + January 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . @@ -3982,23 +3977,23 @@ Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in Progress, Internet-Draft, draft-ietf-anima-brski-prm-00, 25 October 2021, . [I-D.ietf-netconf-sztp-csr] Watsen, K., Housley, R., and S. Turner, "Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request", Work in - Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-12, - 3 December 2021, . + Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-13, + 31 January 2022, . [IEC.62443-3-3] IEC, "Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels", IEC 62443-3-3, August 2013, . [IEEE.802.1AR_2018] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR-2018, @@ -4170,20 +4165,25 @@ } } } Appendix B. History of changes Note: This appendix will be deleted in the final version of the document. + From version 09 -> 10: + + * Resolved some nits reported by I-D nit checker tool + * Resolve some wording issues + From version 08 -> 09: * Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 into more detailed tables in Section 7 (see thread "WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight- cmp-profile-08") * Updated Section 3.1 and 4.1.1 making implicitConfirm recommended for ir/cr/p10cr/kur and providing further recommendations on its use (see thread "certConf - WG Last Call for draft-ietf-lamps-cmp- updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08") @@ -4315,22 +4317,22 @@ From version 01 -> 02: * Extend Section 1.6 with regard to conflicts with UNISIG Subset- 137. * Minor clarifications on extraCerts in Section 3.3 and Section 4.1.1. * Complete specification of requesting a certificate from a trusted PKI with signature protection in Section 4.1.2. * Changed from symmetric key-encryption to password-based key - management technique in section Section 4.1.6.3 as discussed on - the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- + management technique in Section 4.1.6.3 as discussed on the + mailing list (see thread "draft-ietf-lamps-lightweight-cmp- profile-01, section 5.1.6.1") * Changed delayed enrollment described in Section 4.4 from recommended to optional as decided at IETF 107 * Introduced the new RootCAKeyUpdate structure for root CA certificate update in Section 4.3.2 as decided at IETF 107 (also see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, section 5.4.3") * Extend the description of the CertReqTemplate PKI management operation, including an example added in the Appendix. Keep rsaKeyLen as a single integer value in Section 4.3.3 as discussed