< draft-ietf-lamps-cms-mix-with-psk-04.txt   draft-ietf-lamps-cms-mix-with-psk-05.txt >
INTERNET-DRAFT R. Housley INTERNET-DRAFT R. Housley
Internet Engineering Task Force (IETF) Vigil Security Internet Engineering Task Force (IETF) Vigil Security
Intended Status: Proposed Standard Intended Status: Proposed Standard
Expires: 11 November 2019 10 May 2019 Expires: 5 December 2019 5 June 2019
Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)
<draft-ietf-lamps-cms-mix-with-psk-04.txt> <draft-ietf-lamps-cms-mix-with-psk-05.txt>
Abstract Abstract
The invention of a large-scale quantum computer would pose a serious The invention of a large-scale quantum computer would pose a serious
challenge for the cryptographic algorithms that are widely deployed challenge for the cryptographic algorithms that are widely deployed
today. The Cryptographic Message Syntax (CMS) supports key transport today. The Cryptographic Message Syntax (CMS) supports key transport
and key agreement algorithms that could be broken by the invention of and key agreement algorithms that could be broken by the invention of
such a quantum computer. By storing communications that are such a quantum computer. By storing communications that are
protected with the CMS today, someone could decrypt them in the protected with the CMS today, someone could decrypt them in the
future when a large-scale quantum computer becomes available. Once future when a large-scale quantum computer becomes available. Once
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 4 1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6 3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6
4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7 4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7
5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A: Key Transport with PSK Example . . . . . . . . . . . . 17 Appendix A: Key Transport with PSK Example . . . . . . . . . . . . 17
A.1. Originator Processing Example . . . . . . . . . . . . . . 17 A.1. Originator Processing Example . . . . . . . . . . . . . . 18
A.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 20 A.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 20
A.3. Recipient Processing Example . . . . . . . . . . . . . . . 22 A.3. Recipient Processing Example . . . . . . . . . . . . . . . 22
Appendix B: Key Agreement with PSK Example . . . . . . . . . . . . 23 Appendix B: Key Agreement with PSK Example . . . . . . . . . . . . 23
B.1. Originator Processing Example . . . . . . . . . . . . . . 23 B.1. Originator Processing Example . . . . . . . . . . . . . . 23
B.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 26 B.2. ContentInfo and AuthEnvelopedData . . . . . . . . . . . . 26
B.3. Recipient Processing Example . . . . . . . . . . . . . . . 27 B.3. Recipient Processing Example . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The invention of a large-scale quantum computer would pose a serious The invention of a large-scale quantum computer would pose a serious
challenge for the cryptographic algorithms that are widely deployed challenge for the cryptographic algorithms that are widely deployed
today. It is an open question whether or not it is feasible to build 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. a large-scale quantum computer, and if so, when that might happen.
However, if such a quantum computer is invented, many of the However, if such a quantum computer is invented, many of the
cryptographic algorithms and the security protocols that use them cryptographic algorithms and the security protocols that use them
would become vulnerable. would become vulnerable.
The Cryptographic Message Syntax (CMS) [RFC5652][RFC5803] supports The Cryptographic Message Syntax (CMS) [RFC5652][RFC5083] supports
key transport and key agreement algorithms that could be broken by key transport and key agreement algorithms that could be broken by
the invention of a large-scale quantum computer [C2PQ]. These the invention of a large-scale quantum computer [C2PQ]. These
algorithms include RSA [RFC8017], Diffie-Hellman [RFC2631], and algorithms include RSA [RFC8017], Diffie-Hellman [RFC2631], and
Elliptic Curve Diffie-Hellman [RFC5753]. As a result, an adversary Elliptic Curve Diffie-Hellman [RFC5753]. As a result, an adversary
that stores CMS-protected communications today, could decrypt those that stores CMS-protected communications today, could decrypt those
communications in the future when a large-scale quantum computer communications in the future when a large-scale quantum computer
becomes available. becomes available.
Once quantum-secure key management algorithms are available, the CMS Once quantum-secure key management algorithms are available, the CMS
will be extended to support them, if the existing syntax does not will be extended to support them, if the existing syntax does not
skipping to change at page 14, line 12 skipping to change at page 14, line 12
KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable
to the future invention of a large-scale quantum computer. to the future invention of a large-scale quantum computer.
Implementers should not send the same content in different messages, Implementers should not send the same content in different messages,
one using a quantum-resistant key management algorithm and the other one using a quantum-resistant key management algorithm and the other
using a non-quantum-resistant key management algorithm, even if the using a non-quantum-resistant key management algorithm, even if the
content-encryption key is generated independently. Doing so may content-encryption key is generated independently. Doing so may
allow an eavesdropper to correlate the messages, making the content allow an eavesdropper to correlate the messages, making the content
vulnerable to the future invention of a large-scale quantum computer. vulnerable to the future invention of a large-scale quantum computer.
This specification does not require that PSK is known only by the
sender and recipients. The PSK may be known to a group. Since
confidentiality depends on the key transport or key agreement
algorithm, knowledge of the PSK by other parties does not enable
eavesdropping. However, group members can record the traffic of
other members, and then decrypt it if they ever gain access to a
large-scale quantum computer. Also, when many parties know the PSK,
there are many opportunities for theft of the PSK by an attacker.
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 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 purpose. Use of the recipient's public key for both the traditional
CMS and the PSK-mixing variation specified in this document would be CMS and the PSK-mixing variation specified in this document would be
a violations of this principle; however, there is no known way for an a violation of this principle; however, there is no known way for an
attacker to take advantage of this situation. However, an attacker to take advantage of this situation. That said, an
application should enforce separation whenever possible. For application should enforce separation whenever possible. For
example, an purpose identifier for use in the X.509 extended key example, an purpose identifier for use in the X.509 extended key
usage certificate extension [RFC5280] could be identified in the usage certificate extension [RFC5280] could be identified in the
future to indicate that a public key should only be used in future to indicate that a public key should only be used in
conjunction with a PSK, or only without. conjunction with a PSK, or only without.
Implementations must randomly generate key-derivation keys as well as Implementations must randomly generate key-derivation keys as well as
the content-encryption keys or content-authenticated-encryption keys. the content-encryption keys or content-authenticated-encryption keys.
Also, the generation of public/private key pairs for the key Also, the generation of public/private key pairs for the key
transport and key agreement algorithms rely on a random numbers. The transport and key agreement algorithms rely on a random numbers. The
skipping to change at page 16, line 21 skipping to change at page 16, line 38
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, 2015. (DER)", ITU-T Recommendation X.690, 2015.
10.2. Informative References 10.2. Informative References
[AES] National Institute of Standards and Technology, FIPS Pub [AES] National Institute of Standards and Technology, FIPS Pub
197: Advanced Encryption Standard (AES), 26 November 2001. 197: Advanced Encryption Standard (AES), 26 November 2001.
[C2PQ] Hoffman, P., "The Transition from Classical to Post- [C2PQ] Hoffman, P., "The Transition from Classical to Post-
Quantum Cryptography", work-in-progress, draft-hoffman- Quantum Cryptography", work-in-progress, draft-hoffman-
c2pq-03, February 2018. c2pq-04, August 2018.
[H2019] Hammell, J., "Re: [lamps] WG Last Call for draft-ietf-
lamps-cms-mix-with-psk", <https://mailarchive.ietf.org/
arch/msg/spasm/_6d_4jp3sOprAnbU2fp_yp_-6-k>, 27 May 2019.
[IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi- [IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi-
numbers.xhtml#security-smime-0. numbers.xhtml#security-smime-0.
[IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi- [IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi-
numbers.xhtml#security-smime. numbers.xhtml#security-smime.
[IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi- [IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi-
numbers.xhtml#security-smime-13. numbers.xhtml#security-smime-13.
skipping to change at page 23, line 39 skipping to change at page 23, line 39
Appendix B: Key Agreement with PSK Example Appendix B: Key Agreement with PSK Example
This example shows the establishment of an AES-256 content-encryption This example shows the establishment of an AES-256 content-encryption
key using: key using:
- a pre-shared key of 256 bits; - a pre-shared key of 256 bits;
- key agreement using ECDH on curve P-384 and X9.63 KDF - key agreement using ECDH on curve P-384 and X9.63 KDF
with SHA-384; with SHA-384;
- key derivation using HKDF with SHA-384; and - key derivation using HKDF with SHA-384; and
- key wrap using AES-256-KEYWRAP. - key wrap using AES-256-KEYWRAP.
In real-world use, the originator would treat themselves as an additional In real-world use, the originator would treat themselves as an
recipient by performing key agreement with their own static public key additional recipient by performing key agreement with their own
the ephemeral private key generated for this message. This is omited in static public key and the ephemeral private key generated for this
an attempt to simplify the example. message. This is omited in an attempt to simplify the example.
B.1. Originator Processing Example B.1. Originator Processing Example
The pre-shared key known to Alice and Bob: The pre-shared key known to Alice and Bob:
4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4 4aa53cbf500850dd583a5d9821605c6fa228fb5917f87c1c078660214e2d83e4
The identifier assigned to the pre-shared key is: The identifier assigned to the pre-shared key is:
ptf-kmc:216840110121 ptf-kmc:216840110121
Alice randomly generates a content-encryption key: Alice randomly generates a content-encryption key:
skipping to change at page 29, line 12 skipping to change at page 29, line 12
The resutling plaintext content is: The resutling plaintext content is:
48656c6c6f2c20776f726c6421 48656c6c6f2c20776f726c6421
Acknowledgements Acknowledgements
Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean
Turner, and Daniel Van Geest for their review and insightful Turner, and Daniel Van Geest for their review and insightful
comments. They have greatly improved the design, clarity, and comments. They have greatly improved the design, clarity, and
implementation guidance. 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.
Author's Address Author's Address
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
516 Dranesville Road 516 Dranesville Road
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
 End of changes. 11 change blocks. 
14 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/