--- 1/draft-ietf-lamps-cmp-algorithms-09.txt 2022-02-14 07:13:27.361038315 -0800 +++ 2/draft-ietf-lamps-cmp-algorithms-10.txt 2022-02-14 07:13:27.425039914 -0800 @@ -1,21 +1,21 @@ LAMPS Working Group H. Brockhaus, Ed. Internet-Draft H. Aschauer Updates: 4210 (if approved) Siemens Intended status: Standards Track M. Ounsworth -Expires: 25 June 2022 J. Gray +Expires: 18 August 2022 J. Gray Entrust - 22 December 2021 + 14 February 2022 Certificate Management Protocol (CMP) Algorithms - draft-ietf-lamps-cmp-algorithms-09 + draft-ietf-lamps-cmp-algorithms-10 Abstract This document updates RFC 4210 describing the conventions for using concrete cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. Status of This Memo @@ -25,91 +25,78 @@ 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 25 June 2022. + This Internet-Draft will expire on 18 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. - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 - 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 8 + 4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 7 4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 - 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 - 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11 4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11 4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12 4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12 - 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 13 + 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 6. Message Authentication Code Algorithms . . . . . . . . . . . 14 - 6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 14 + 6. Message Authentication Code Algorithms . . . . . . . . . . . 13 + 6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 13 6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14 - 6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 15 - - 6.2. Symmetric key-based MAC . . . . . . . . . . . . . . . . . 15 + 6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.2. Symmetric key-based MAC . . . . . . . . . . . . . . . . . 14 6.2.1. SHA2-based HMAC . . . . . . . . . . . . . . . . . . . 15 - 6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 16 + 6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 15 6.2.3. SHAKE-based KMAC . . . . . . . . . . . . . . . . . . 16 - 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 17 + 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 16 7.1. Algorithm Profile for RFC 4210 PKI Management Message - Profiles . . . . . . . . . . . . . . . . . . . . . . . . 20 - 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 22 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 - 11. Normative References . . . . . . . . . . . . . . . . . . . . 25 - 12. Informative References . . . . . . . . . . . . . . . . . . . 29 - Appendix A. History of changes . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + Profiles . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 21 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 + 11. Normative References . . . . . . . . . . . . . . . . . . . . 24 + 12. Informative References . . . . . . . . . . . . . . . . . . . 28 + Appendix A. History of changes . . . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. @@ -166,26 +153,22 @@ SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output functions (SHAKEs) SHAKE128 and SHAKE256. Currently SHAKE128 and SHAKE256 are the only members of the SHA3-family which are specified for use in X.509 and PKIX [RFC8692], and CMS [RFC8702] as one-way hash function for use with RSASSA-PSS and ECDSA as one-way hash function for use with RSASSA-PSS and ECDSA. SHAKE is an extendable-output function and FIPS Pub 202 [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash function. When SHAKE is used in CMP as a message digest algorithm, - the message digested by the SHAKE function MUST be appended with the - OCTET_STRING equivalent of "CMP_SHAKE128" for SHAKE128 and - "CMP_SHAKE256" for SHAKE 256 and the output length MUST be 256 bits - for SHAKE128 and 512 bits for SHAKE256. - - < ToDo: This note must be checked and confirmed by experts. > + the output length MUST be 256 bits for SHAKE128 and 512 bits for + SHAKE256. The message digest algorithms SHAKE128 and SHAKE256 are identified by the following OIDs: id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashalgs(2) 11 } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashalgs(2) 12 } @@ -322,22 +305,20 @@ id-Ed448 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 113 } Specific conventions to be considered are specified in RFC 8419 [RFC8419]. Note: The hash algorithm used to calculate the certHash in certConf messages MUST be SHA512 if the certificate to be confirmed has been signed using Ed25519 and SHAKE256 with d=512 if signed using Ed448. - < ToDo: This note must be checked and confirmed by experts. > - 4. Key Management Algorithms CMP utilizes the following general key management techniques: key agreement, key transport, and passwords. CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes the use of CMS [RFC5652] EnvelopedData by deprecating the use of EncryptedValue. 4.1. Key Agreement Algorithms @@ -729,29 +709,20 @@ nistAlgorithm(4) aes(1) 49 } Specific conventions to be considered for AES-GMAC are specified in RFC 9044 [RFC9044]. 6.2.3. SHAKE-based KMAC The KMAC algorithm is defined in RFC 8702 [RFC8702] and FIPS SP 800-185 [NIST.SP.800-185]. - Note: Currently it is assumed that the advantage of a HW - implementation over a SW implementation of KMAC is greater than of - HMAC-SHA2. Therefore, the advantage of an attacker is greater if - KMAC is used as a prf in PasswordBasedMac and PBKDF2. For this - reason, the use of KMAC as a prf in PasswordBasedMac and PBKDF2 is - discouraged. - - < ToDo: This note must be checked and confirmed by experts. > - The SHAKE-based KMAC algorithm is identified by the following OIDs: id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 19 } id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 20 } Specific conventions to be considered for KMAC with SHAKE are @@ -793,46 +764,50 @@ algorithms used for the key management technique (Section 7.2: PROT_ENC_ALG or Section 7.1: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) and the encryption of the content-encryption key and private key (Section 7.2: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.1: KM_KW_ALG, PROT_SYM_ALG). The following table shows the algorithms listed in this document sorted by their bits of security. If an implementation intends to enroll and manage certificate for keys of a specific security, it SHALL implement and use algorithms of at least that strength for the - respective PKI management operation. If one column does not provide - a suitable algorithm, the implementer MUST choose one offering more + respective PKI management operation. If one row does not provide a + suitable algorithm, the implementer MUST choose one offering more bits of security. - +========+===========+=========+=========+===============+==========+ - |Bits of |Recommended|RSA / D-H|Elliptic |Hash function |Symmetric | - |security|for | |curve |or XOF with |encryption| - | |managing | | |specified | | - | |keys up to | | |output length | | + +========+============+=========+==============+=========+==========+ + |Bits of |Recommended |RSA / D-H|Elliptic curve|Hash |Symmetric | + |security|for managing| | |function |encryption| + | |keys up to | | |or XOF | | + | | | | |with | | + | | | | |specified| | + | | | | |output | | + | | | | |length | | | | | | |(d) | | - +========+===========+=========+=========+===============+==========+ - |112 |RSA2048 |RSA2048 |secp224r1|SHA224 | | - | |secp224r1 |D-H(2048)| | | | - +--------+-----------+---------+---------+---------------+----------+ - |128 |RSA3072 |RSA3072 |secp256r1|SHA256 |AES-128 | - | |secp256r1 |D-H(3072)|Ed25519/ |SHAKE128(d=256)| | - | |Ed25519 | |X25519 | | | - +--------+-----------+---------+---------+---------------+----------+ - |192 |secp384r1 | |secp384r1|SHA384 |AES-192 | - +--------+-----------+---------+---------+---------------+----------+ - |224 |Ed448 | |Ed448/ | | | - | | | |X448 | | | - +--------+-----------+---------+---------+---------------+----------+ - |256 |secp521r1 | |secp521r1|SHA512 |AES-256 | - | | | | |SHAKE256(d=512)| | - +--------+-----------+---------+---------+---------------+----------+ + +========+============+=========+==============+=========+==========+ + |112 |RSA2048, |RSA2048, |ECDSA/ECDH |SHA224 | | + | |secp224r1 |D-H(2048)|(secp224r1) | | | + +--------+------------+---------+--------------+---------+----------+ + |128 |RSA3072, |RSA3072, |ECDSA/ECDH |SHA256, |AES-128 | + | |secp256r1, |D-H(3072)|(secp256r1), |SHAKE128 | | + | |Curve25519 | |Ed25519/X25519|(d=256) | | + +--------+------------+---------+--------------+---------+----------+ + |192 |secp384r1 | |ECDSA/ECDH |SHA384 |AES-192 | + | | | |(secp384r1) | | | + +--------+------------+---------+--------------+---------+----------+ + |224 |Curve448 | |Ed448/X448 | | | + +--------+------------+---------+--------------+---------+----------+ + |256 |secp521r1 | |ECDSA/ECDH |SHA512, |AES-256 | + | | | |(secp521r1) |SHAKE256 | | + | | | | |(d=512) | | + +--------+------------+---------+--------------+---------+----------+ Table 1: Cryptographic algorithms sorted by their bits of security The following table shows the cryptographic algorithms sorted by their usage in CMP and with more details. +=====+=============+===============+===============+===============+ |Bits |Recommended |CMP protection |Key management | Key-wrap and | |of |for managing | |technique | symmetric | |secu-|keys up to | | | encryption | @@ -850,55 +825,52 @@ | | |(2048, SHA224),|(2048), | | | | |ECDSA |ECDH | | | | |(secp224r1, |(secp224r1, | | | | |SHA224 or |SHA224), | | | | |SHAKE128), |PBKDF2 (HMAC- | | | | |PBMAC1 (HMAC- |SHA224) | | | | |SHA224) | | | +-----+-------------+---------------+---------------+---------------+ |128 |RSA3072, |RSASSA-PSS |ESDH (3072), | AES-128 | | |secp256r1, |(3072, SHA256 |RSAES-OAEP | | - | |Ed25519 |or SHAKE128), |(3072, SHA256),| | + | |Curve25519 |or SHAKE128), |(3072, SHA256),| | | | |RSAEncryption |RSAEncryption | | | | |(3072, SHA256),|(3072), | | | | |ECDSA |ECDH | | | | |(secp256r1, |(secp256r1, | | | | |SHA256 or |SHA256), | | - | | |SHAKE128), |ECDH (X25519), | | + | | |SHAKE128), |X25519, | | | | |Ed25519 |PBKDF2 (HMAC- | | | | |(SHA512), |SHA256) | | | | |PBMAC1 (HMAC- | | | | | |SHA256) | | | +-----+-------------+---------------+---------------+---------------+ |192 |secp384r1 |ECDSA |ECDH | AES-192 | | | |(secp384r1, |(secp384r1, | | | | |SHA384), |SHA384), | | | | |PBMAC1 (HMAC- |PBKDF2 (HMAC- | | | | |SHA384) |SHA384) | | +-----+-------------+---------------+---------------+---------------+ - |224 |Ed448 |Ed448 |ECDH (X448) | | + |224 |Curve448 |Ed448 |X448 | | | | |(SHAKE256) | | | +-----+-------------+---------------+---------------+---------------+ |256 |secp521r1 |ECDSA |ECDH | AES-256 | | | |(secp521r1, |(secp521r1, | | | | |SHA512 or |SHA512), | | | | |SHAKE256), |PBKDF2 (HMAC- | | | | |PBMAC1 (HMAC- |SHA512) | | | | |SHA512) | | | +-----+-------------+---------------+---------------+---------------+ Table 2: Cryptographic algorithms sorted by their bits of security and usage by CMP - < ToDo: Table 1 and 2 above must be checked and confirmed by experts. - > - To avoid consuming too much computational resources it is recommended to choose a set of algorithms offering roughly the same level of security. Below are provided several algorithm profiles which are balanced, assuming the implementer chooses MAC secrets and/or certificate profiles of at least equivalent strength. 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles The following table updates the definitions of algorithms used within PKI Management Message Profiles as defined in CMP Appendix D.2 @@ -1069,31 +1041,20 @@ introduced that are more resistant to today's attacks. This document lists many cryptographic algorithms usable with CMP to offer implementer a more up to date choice. Finally, the algorithms to be supported also heavily depend on the certificates and PKI management operations utilized in the target environment. The algorithm with the lowest security strength and the entropy of shared secret information define the security of the overall solution, see Section 7. - SHAKE is an extendable-output function and FIPS Pub 202 - [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash - function. To prevent known attacks SHAKE MUST only be used as hash - function within CMP [RFC4210] and CMP Updates - [I-D.ietf-lamps-cmp-updates] if the output length is fixed to d=256 - for SHAKE128 and d=512 for SHAKE256 as described in [RFC8702] and - MUST NOT be used with different output lengths. - - < ToDo: The above security consideration must be checked and - confirmed by experts. > - When using MAC-based message protection the use of PBMAC1 is preferable to that of PasswordBasedMac. First, PBMAC1 is a well- known scrutinized algorithm, which is not true for PasswordBasedMac. Second, the PasswordBasedMac algorithm as specified in RFC 4211 Section 4.4 [RFC4211] is essentially PBKDF1 (as defined in RFC 8018 Section 5.1 [RFC8018]) with an HMAC step at the end. Here we update to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018]. PBKDF2 is superior to PBKDF1 in an improved internal construct for iterated hashing, and in removing PBKDF1's limitation of only being able to derive keys up to the size of the underlying hash function. @@ -1102,29 +1063,20 @@ algorithm by most standards bodies, and therefore presents difficulties to implementer who are submitting their CMP implementations for certification, hence moving to a PBKDF2-based mechanism. This change is in alignment with [RFC9045] which updates [RFC4211] to allow the use of PBMAC1 in CRMF. AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2; the use of AES-GMAC more than once with the same key and the same nonce will break the security. - Currently it is assumed that the advantage of a HW implementation - over a SW implementation of KMAC is greater than of HMAC-SHA2. - Therefore, the advantage of an attacker is greater if KMAC is used as - a prf in PasswordBasedMac and PBKDF2. For this reason, the use of - KMAC as a prf in PasswordBasedMac and PBKDF2 is discouraged. - - < ToDo: This security consideration must be checked and confirmed by - experts. > - In Section 7 of this document there is also an update to the Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY be supported when implementing the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. It is recognized that there may be older CMP implementations in use that conform to the algorithm use profile from Appendix D.2 of RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. Therefore, it is expected that many CMP systems may already support @@ -1149,31 +1101,31 @@ May thanks also to all reviewers like Serge Mister, Mark Ferreira, Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen Fries for their input and feedback to this document. Apologies to all not mentioned reviewers and supporters. 11. Normative References [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, . [I-D.ietf-lamps-lightweight-cmp-profile] Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight Certificate Management Protocol (CMP) Profile", Work in Progress, Internet-Draft, draft-ietf-lamps-lightweight- - cmp-profile-09, 17 December 2021, + cmp-profile-10, 1 February 2022, . + lightweight-cmp-profile-10>. [NIST.FIPS.180-4] Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, . [NIST.FIPS.186-4] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", NIST NIST FIPS 186-4, @@ -1365,20 +1317,29 @@ Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, DOI 10.17487/RFC8692, December 2019, . Appendix A. History of changes Note: This appendix will be deleted in the final version of the document. + From version 09 -> 10: + + * Removed the pre-RFC5378 work disclaimer after the RFC 4210 authors + granted BCP78 rights to the IETF Trust + * Implemented the changes proposed by Quynh, (see thread "Quynh + Action: draft-ietf-lamps-cmp-algorithms-08.txt") and removed + markers for ToDos regarding this review of SHAKE and KMAC usage as + well as on the tables in Section 7 + From version 08 -> 09: * Updated IPR disclaimer From version 07 -> 08: * Fixing issues from WG and AD review * Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of SHAKE and KMAC and added ToDo regarding checking respective notes * Added two tables showing algorithms sorted by their strength to