--- 1/draft-ietf-lamps-cms-mix-with-psk-05.txt 2019-08-06 14:13:04.620761106 -0700 +++ 2/draft-ietf-lamps-cms-mix-with-psk-06.txt 2019-08-06 14:13:04.680762625 -0700 @@ -1,18 +1,18 @@ INTERNET-DRAFT R. Housley Internet Engineering Task Force (IETF) Vigil Security Intended Status: Proposed Standard -Expires: 5 December 2019 5 June 2019 +Expires: 6 February 2020 6 August 2019 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) - + Abstract The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once @@ -78,25 +78,25 @@ B.1. Originator Processing Example . . . . . . . . . . . . . . 23 B.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 26 B.3. Recipient Processing Example . . . . . . . . . . . . . . . 27 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed - today. It is an open question whether or not it is feasible to build - a large-scale quantum computer, and if so, when that might happen. - However, if such a quantum computer is invented, many of the - cryptographic algorithms and the security protocols that use them - would become vulnerable. + today [S1994]. It is an open question whether or not it is feasible + to build a large-scale quantum computer, and if so, when that might + happen [NAS2019]. However, if such a quantum computer is invented, + many of the cryptographic algorithms and the security protocols that + use them would become vulnerable. The Cryptographic Message Syntax (CMS) [RFC5652][RFC5083] supports key transport and key agreement algorithms that could be broken by the invention of a large-scale quantum computer [C2PQ]. These algorithms include RSA [RFC8017], Diffie-Hellman [RFC2631], and Elliptic Curve Diffie-Hellman [RFC5753]. As a result, an adversary that stores CMS-protected communications today, could decrypt those communications in the future when a large-scale quantum computer becomes available. @@ -109,31 +109,31 @@ quantum computer by mixing the output of existing key transport and key agreement algorithms with a pre-shared key (PSK). Secure communication can be achieved today by mixing a strong PSK with the output of an existing key transport algorithm, like RSA [RFC8017], or an existing key agreement algorithm, like Diffie-Hellman [RFC2631] or Elliptic Curve Diffie-Hellman [RFC5753]. A security solution that is believed to be quantum resistant can be achieved by using a PSK with sufficient entropy along with a quantum resistant key derivation function (KDF), like HKDF [RFC5869], and a quantum resistant encryption algorithm, like 256-bit AES [AES]. In this way, today's - CMS-protected communication can be invulnerable to an attacker with a + CMS-protected communication can be resistant to an attacker with a large-scale quantum computer. In addition, there may be other reasons for including a strong PSK besides protection against the future invention of a large-scale quantum computer. For example, there is always the possibility of a cryptoanalytic breakthrough on one or more of the classic public-key algorithm, and there are longstanding concerns about undisclosed - trapdoors in Diffie-Hellamn parameters. Inclusion of a strong PSK as - part of the overall key management offer additional protection - against these concerns. + trapdoors in Diffie-Hellman parameters [FGHT2016]. Inclusion of a + strong PSK as part of the overall key management offer additional + protection against these concerns. Note that the CMS also supports key management techniques based on symmetric key-encryption keys and passwords, but they are not discussed in this document because they are already quantum resistant. The symmetric key-encryption key technique is quantum resistant when used with an adequate key size. The password technique is quantum resistant when used with a quantum-resistant key derivation function and a sufficiently large password. 1.1. Terminology @@ -236,21 +236,21 @@ KDF is the key-encryption key, which is used for the encryption of the content-encryption key or content-authenticated-encryption key. The second key management technique, called keyAgreePSK, see Section 4, uses a key agreement algorithm to establish a pairwise key-encryption key, which is then mixed with the PSK using a KDF to produce a second pairwise key-encryption key, which is then used to encrypt the content-encryption key or content-authenticated- encryption key. -3. KeyTransPSKRecipientInfo +3. keyTransPSK Per-recipient information using keyTransPSK is represented in the KeyTransPSKRecipientInfo type, which is indicated by the id-ori- keyTransPSK object identifier. Each instance of KeyTransPSKRecipientInfo establishes the content-encryption key or content-authenticated-encryption key for one or more recipients that have access to the same PSK. The id-ori-keyTransPSK object identifier is: @@ -295,21 +295,21 @@ ktris contains one KeyTransRecipientInfo type for each recipient; it uses a key transport algorithm to establish the key-derivation key. KeyTransRecipientInfo is described in Section 6.2.1 of [RFC5652]. encryptedKey is the result of encrypting the content-encryption key or the content-authenticated-encryption key with the key- encryption key. EncryptedKey is an OCTET STRING. -4. KeyAgreePSKRecipientInfo +4. keyAgreePSK Per-recipient information using keyAgreePSK is represented in the KeyAgreePSKRecipientInfo type, which is indicated by the id-ori- keyAgreePSK object identifier. Each instance of KeyAgreePSKRecipientInfo establishes the content-encryption key or content-authenticated-encryption key for one or more recipients that have access to the same PSK. The id-ori-keyAgreePSK object identifier is: @@ -378,21 +378,21 @@ authenticated-encryption key with the second pairwise key- encryption key. EncryptedKey is an OCTET STRING. The RecipientEncryptedKeys type is defined in Section 6.2.2 of [RFC5652]. 5. Key Derivation Many key derivation functions (KDFs) internally employ a one-way hash function. When this is the case, the hash function that is used is identified by the KeyDerivationAlgorithmIdentifier. HKDF [RFC5869] - is one example of a KDF that make use fo a hash function. + is one example of a KDF that makes use of a hash function. A KDF has several input values. This section describes the conventions for using the KDF to compute the key-encryption key for KeyTransPSKRecipientInfo and KeyAgreePSKRecipientInfo. For simplicity, the terminology used in the HKDF [RFC5869] specification is used here. The KDF inputs are: IKM is the input keying material; it is the symmetric secret input @@ -406,21 +406,21 @@ L is the length of output keying material in octets; the value depends on the key-encryption algorithm that will be used. The algorithm is identified by the KeyEncryptionAlgorithmIdentifier. In addition, the OBJECT IDENTIFIER portion of the KeyEncryptionAlgorithmIdentifier is included in the next input value, called info. info is optional context and application specific information. The DER-encoding of CMSORIforPSKOtherInfo is used as the info value, and the PSK is included in this structure. Note that - EXPLICIT tagging is used in the ASN.1 module that deines this + EXPLICIT tagging is used in the ASN.1 module that defines this structure. For KeyTransPSKRecipientInfo, the ENUMERATED value of 5 is used. For KeyAgreePSKRecipientInfo, the ENUMERATED value of 10 is used. CMSORIforPSKOtherInfo is defined by the following ASN.1 structure: CMSORIforPSKOtherInfo ::= SEQUENCE { psk OCTET STRING, keyMgmtAlgType ENUMERATED { keyTrans (5), keyAgree (10) }, @@ -477,24 +477,24 @@ AlgorithmIdentifier{}, KEY-DERIVATION FROM AlgorithmInformation-2009 -- [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } OTHER-RECIPIENT, OtherRecipientInfo, CMSVersion, KeyTransRecipientInfo, OriginatorIdentifierOrKey, UserKeyingMaterial, RecipientEncryptedKeys, EncryptedKey, KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier - FROM CryptographicMessageSyntax-2009 -- [RFC5911] + FROM CryptographicMessageSyntax-2010 -- [RFC6268] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) - id-mod-cms-2004-02(41) } ; + id-mod-cms-2009(58) } ; -- -- OtherRecipientInfo Types (ori-) -- SupportedOtherRecipInfo OTHER-RECIPIENT ::= { ori-keyTransPSK | ori-keyAgreePSK, ... } @@ -518,21 +518,21 @@ encryptedKey EncryptedKey } PreSharedKeyIdentifier ::= OCTET STRING KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo -- -- Key Agreement with Pre-Shared Key -- - ori-keyAgreePSK ORI-TYPE ::= { + ori-keyAgreePSK OTHER-RECIPIENT ::= { KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK } id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 } KeyAgreePSKRecipientInfo ::= SEQUENCE { version CMSVersion, -- always set to 0 pskid PreSharedKeyIdentifier, originator [0] EXPLICIT OriginatorIdentifierOrKey, ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, kdfAlgorithm KeyDerivationAlgorithmIdentifier, @@ -563,21 +563,21 @@ private key, the agreement private key, the key-derivation key, and the key-encryption key. Compromise of the PSK will make the encrypted content vulnerable to the future invention of a large-scale quantum computer. Compromise of the PSK and either the key transport private key or the agreement private key may result in the disclosure of all contents protected with that combination of keying material. Compromise of the PSK and the key-derivation key may result in disclosure of all contents protected with that combination of keying material. Compromise of the key-encryption key may result in the disclosure of all content-encryption keys or content-authenticated- - encryption keys that were protected with that keying materail, which + encryption keys that were protected with that keying material, which in turn may result in the disclosure of the content. A large-scale quantum computer will essentially negate the security provided by the key transport algorithm or the key agreement algorithm, which means that the attacker with a large-scale quantum computer can discover the key-derivation key. In addition a large- scale quantum computer effectively cuts the security provided by a symmetric key algorithm in half. Therefore, the PSK needs at least 256 bits of entropy to provide 128 bits of security. To match that same level of security, the key derivation function needs to be @@ -624,75 +624,83 @@ Once an attacker has the PSK, they can decrypt stored traffic if they ever gain access to a large-scale quantum computer in the same manner as a legitimate group member. Sound cryptographic key hygiene is to use a key for one and only one purpose. Use of the recipient's public key for both the traditional CMS and the PSK-mixing variation specified in this document would be a violation of this principle; however, there is no known way for an attacker to take advantage of this situation. That said, an application should enforce separation whenever possible. For - example, an purpose identifier for use in the X.509 extended key - usage certificate extension [RFC5280] could be identified in the - future to indicate that a public key should only be used in - conjunction with a PSK, or only without. + example, a purpose identifier for use in the X.509 extended key usage + certificate extension [RFC5280] could be identified in the future to + indicate that a public key should only be used in conjunction with a + PSK, or only without. Implementations must randomly generate key-derivation keys as well as the content-encryption keys or content-authenticated-encryption keys. Also, the generation of public/private key pairs for the key transport and key agreement algorithms rely on a random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. [RFC4086] offers important guidance in this area. Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptoanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will be reduced. Therefore, cryptographic algorithm implementations should be modular, allowing new algorithms - to be readily inserted. That is, implementors should be prepared for + to be readily inserted. That is, implementers should be prepared for the set of supported algorithms to change over time. + The security properties provided by the mechanisms specified in this + document can be validated using formal methods. A ProVerif proof in + [H2019] shows that an attacker with a large-scale quantum computer + that is capable of breaking the Diffie-Hellman key agreement + algorithm cannot disrupt the delivery of the content-encryption key + to the recipient and the attacker cannot learn the content-encryption + key from the protocol exchange. + 8. Privacy Considerations An observer can see which parties are using each PSK simply by watching the PSK key identifiers. However, the addition of these key identifiers is not really making privacy worse. When key transport is used, the RecipientIdentifier is always present, and it clearly identifies each recipient to an observer. When key agreement is used, either the IssuerAndSerialNumber or the RecipientKeyIdentifier is always present, and these clearly identify each recipient. 9. IANA Considerations - One object identifier for the ASN.1 module in the Section 5 was - assigned in the SMI Security for S/MIME Module Identifiers + One object identifier for the ASN.1 module in Section 6 was assigned + in the SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0) [IANA-MOD] registry: - id-mod-cms-ori-psk-2017 OBJECT IDENTIFIER ::= { + id-mod-cms-ori-psk-2019 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) mod(0) TBD0 } - One object identifier for an arc to assign Other Recipient Info - Identifiers was assigned in the SMI Security for S/MIME Mail Security + One new registry was created for Other Recipient Info Identifiers + within the SMI Security for S/MIME Mail Security (1.2.840.113549.1.9.16) [IANA-SMIME] registry: id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) TBD1 } - This assignment created the new SMI Security for Other Recipient Info - Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry with the - following two entries with references to this document: + Two assignments were made in the new SMI Security for Other Recipient + Info Identifiers (1.2.840.113549.1.9.16.TBD1) [IANA-ORI] registry + with references to this document: id-ori-keyTransPSK OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ori(TBD1) 1 } id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ori(TBD1) 2 } 10. References @@ -723,32 +731,46 @@ 10.2. Informative References [AES] National Institute of Standards and Technology, FIPS Pub 197: Advanced Encryption Standard (AES), 26 November 2001. [C2PQ] Hoffman, P., "The Transition from Classical to Post- Quantum Cryptography", work-in-progress, draft-hoffman- c2pq-04, August 2018. + [FGHT2016] Fried, J., Gaudry, P., Heninger, N., and E. Thome, "A + kilobit hidden SNFS discrete logarithm computation", + Cryptology ePrint Archive, Report 2016/961, 2016. + https://eprint.iacr.org/2016/961.pdf. + [H2019] Hammell, J., "Re: [lamps] WG Last Call for draft-ietf- lamps-cms-mix-with-psk", , 27 May 2019. [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- numbers.xhtml#security-smime-0. [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- numbers.xhtml#security-smime. [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- - numbers.xhtml#security-smime-13. + numbers.xhtml#security-smime-TBD1. + + [NAS2019] National Academies of Sciences, Engineering, and Medicine, + "Quantum Computing: Progress and Prospects", The National + Academies Press, DOI 10.17226/25196, 2019. + + [S1994] Shor, P., "Algorithms for Quantum Computation: Discrete + Logarithms and Factoring", Proceedings of the 35th Annual + Symposium on Foundations of Computer Science, 1994, pp. + 124-134. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC4086] D. Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", RFC 4086, June 2005. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key @@ -761,39 +783,43 @@ [RFC5869] Krawczyk, H., and P. Eronen, "HMAC-based Extract-and- Expand Key Derivation Function (HKDF)", RFC 5869, May 2010. [RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010. [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the - Public Key Infrastructure Using X.509 (PKIX)" RFC 5912, + Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010. + [RFC6268] Schaad, J., S. Turner, "Additional New ASN.1 Modules for + the Cryptographic Message Syntax (CMS) and the Public Key + Infrastructure Using X.509 (PKIX)", RFC 6268, July 2011. + [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, November 2016. Appendix A: Key Transport with PSK Example This example shows the establishment of an AES-256 content-encryption key using: - a pre-shared key of 256 bits; - key transport using RSA PKCS#1 v1.5 with a 3072-bit key; - key derivation using HKDF with SHA-384; and - key wrap using AES-256-KEYWRAP. In real-world use, the originator would encrypt the key-derivation key in their own RSA public key as well as the recipient's public - key. This is omited in an attempt to simplify the example. + key. This is omitted in an attempt to simplify the example. A.1. Originator Processing Example The pre-shared key known to Alice and Bob: c244cdd11a0d1f39d9b61282770244fb0f6befb91ab7f96cb05213365cf95b15 The identifier assigned to the pre-shared key is: ptf-kmc:13614122112 Alice obtains Bob's public key: @@ -860,24 +886,24 @@ ae4ea1d99e78fcdcea12d9f10d991ac71502939ee0c30ebdcc97dd1fc5ba3566 c83d0dd5d1b4faa5 Alice encrypts the content using AES-256-GCM with the content- encryption key. The 12-octet nonce used is: cafebabefacedbaddecaf888 The content plaintext is: 48656c6c6f2c20776f726c6421 - The resutling ciphertext is: + The resulting ciphertext is: 9af2d16f21547fcefed9b3ef2d - The resutling 12-octet authentication tag is: + The resulting 12-octet authentication tag is: a0e5925cc184e0172463c44c A.2. ContentInfo and AuthEnvelopedData Alice encodes the AuthEnvelopedData and the ContentInfo, and sends the result to Bob. The resulting structure is: 0 650: SEQUENCE { 4 11: OBJECT IDENTIFIER authEnvelopedData : { 1 2 840 113549 1 9 16 1 23 } @@ -1020,37 +1046,37 @@ encryption key, and checks the received authentication tag. The 12-octet nonce used is: cafebabefacedbaddecaf888 The 12-octet authentication tag is: a0e5925cc184e0172463c44c The received ciphertext content is: 9af2d16f21547fcefed9b3ef2d - The resutling plaintext content is: + The resulting plaintext content is: 48656c6c6f2c20776f726c6421 Appendix B: Key Agreement with PSK Example This example shows the establishment of an AES-256 content-encryption key using: - a pre-shared key of 256 bits; - key agreement using ECDH on curve P-384 and X9.63 KDF with SHA-384; - key derivation using HKDF with SHA-384; and - key wrap using AES-256-KEYWRAP. In real-world use, the originator would treat themselves as an additional recipient by performing key agreement with their own static public key and the ephemeral private key generated for this - message. This is omited in an attempt to simplify the example. + message. This is omitted in an attempt to simplify the example. B.1. Originator Processing Example The pre-shared key known to Alice and Bob: 4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4 The identifier assigned to the pre-shared key is: ptf-kmc:216840110121 Alice randomly generates a content-encryption key: @@ -1123,20 +1149,23 @@ Alice uses AES-KEY-WRAP to encrypt the content-encryption key with the KEK2; the wrapped key is: 229fe0b45e40003e7d8244ec1b7e7ffb2c8dca16c36f5737222553a71263a92b de08866a602d63f4 Alice encrypts the content using AES-256-GCM with the content- encryption key. The 12-octet nonce used is: dbaddecaf888cafebabeface + The plaintext is: + 48656c6c6f2c20776f726c6421 + The resulting ciphertext is: fc6d6f823e3ed2d209d0c6ffcf The resulting 12-octet authentication tag is: 550260c42e5b29719426c1ff B.2. ContentInfo and AuthEnvelopedData Alice encodes the AuthEnvelopedData and the ContentInfo, and sends the result to Bob. The resulting structure is: @@ -1253,36 +1282,28 @@ encryption key, and checks the received authentication tag. The 12-octet nonce used is: dbaddecaf888cafebabeface The 12-octet authentication tag is: 550260c42e5b29719426c1ff The received ciphertext content is: fc6d6f823e3ed2d209d0c6ffcf - The resutling plaintext content is: + The resulting plaintext content is: 48656c6c6f2c20776f726c6421 Acknowledgements - Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean - Turner, and Daniel Van Geest for their review and insightful - comments. They have greatly improved the design, clarity, and - implementation guidance. - - The security properties provided by the mechanisms specified in this - document can be validated using formal methods. A ProVerif proof in - [H2019] shows that an attacker with a large-scale quantum computer - that is capable of breaking the Diffie-Hellman key agreement - algorithm cannot disrupt the delivery of the content-encryption key - to the recipient and the attacker cannot learn the content-encryption - key from the protocol exchange. + Many thanks to Roman Danyliw, Burt Kaliski, Panos Kampanakis, Jim + Schaad, Robert Sparks, Sean Turner, and Daniel Van Geest for their + review and insightful comments. They have greatly improved the + design, clarity, and implementation guidance. Author's Address Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 USA EMail: housley@vigilsec.com