| < draft-mcgrew-tls-aes-ccm-ecc-07.txt | draft-mcgrew-tls-aes-ccm-ecc-08.txt > | |||
|---|---|---|---|---|
| TLS Working Group D. McGrew | TLS Working Group D. McGrew | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Intended status: Informational D. Bailey | Intended status: Informational D. Bailey | |||
| Expires: January 13, 2014 RSA/EMC | Expires: August 16, 2014 RSA/EMC | |||
| M. Campagna | M. Campagna | |||
| R. Dugal | R. Dugal | |||
| Certicom Corp. | Certicom Corp. | |||
| July 12, 2013 | February 12, 2014 | |||
| AES-CCM ECC Cipher Suites for TLS | AES-CCM ECC Cipher Suites for TLS | |||
| draft-mcgrew-tls-aes-ccm-ecc-07 | draft-mcgrew-tls-aes-ccm-ecc-08 | |||
| Abstract | Abstract | |||
| This memo describes the use of the Advanced Encryption Standard (AES) | This memo describes the use of the Advanced Encryption Standard (AES) | |||
| in the Counter and CBC-MAC Mode (CCM) of operation within Transport | in the Counter and CBC-MAC Mode (CCM) of operation within Transport | |||
| Layer Security (TLS) to provide confidentiality and data origin | Layer Security (TLS) to provide confidentiality and data origin | |||
| authentication. The AES-CCM algorithm is amenable to compact | authentication. The AES-CCM algorithm is amenable to compact | |||
| implementations, making it suitable for constrained environments. | implementations, making it suitable for constrained environments, | |||
| The ciphersuites defined in this document use Elliptic Curve | while at the same time providing a high level of security. The | |||
| Cryptography (ECC), and are advantageous in networks with limited | ciphersuites defined in this document use Elliptic Curve Cryptography | |||
| bandwidth. | (ECC), and are advantageous in networks with limited bandwidth. | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on January 13, 2014. | This Internet-Draft will expire on August 16, 2014. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2014 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Conventions Used In This Document . . . . . . . . . . . . . 3 | 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 | |||
| 2. ECC based AES-CCM Cipher Suites . . . . . . . . . . . . . . . . 3 | 2. ECC based AES-CCM Cipher Suites . . . . . . . . . . . . . . . 3 | |||
| 2.1. AEAD algorithms . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1. AEAD algorithms . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.2. Requirements on Curves and Hashes . . . . . . . . . . . . . 5 | 2.2. Requirements on Curves and Hashes . . . . . . . . . . . . 5 | |||
| 3. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
| 6.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 7 | 6.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . 7 | |||
| 6.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 7 | 6.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 6.3. Hardware Security Modules . . . . . . . . . . . . . . . . 7 | ||||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 | |||
| Appendix A. Recommended Curves and Algorithms . . . . . . . . . . 8 | Appendix A. Recommended Curves and Algorithms . . . . . . . . . . 9 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 1. Introduction | 1. Introduction | |||
| This document describes the use of Advanced Encryption Standard (AES) | This document describes the use of Advanced Encryption Standard (AES) | |||
| [AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS | [AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS | |||
| ciphersuites. AES-CCM provides both authentication and | ciphersuites. AES-CCM provides both authentication and | |||
| confidentiality and uses as its only primitive the AES encrypt | confidentiality and uses as its only primitive the AES encrypt | |||
| operation (the AES decrypt operation is not needed). This makes it | operation (the AES decrypt operation is not needed). This makes it | |||
| amenable to compact implementations, which is advantageous in | amenable to compact implementations, which is advantageous in | |||
| constrained environments. Of course, adoption outside of constrained | constrained environments. Of course, adoption outside of constrained | |||
| skipping to change at page 4, line 39 ¶ | skipping to change at page 4, line 39 ¶ | |||
| o Curves with a cofactor equal to one SHOULD be used; this | o Curves with a cofactor equal to one SHOULD be used; this | |||
| simplifies their use. | simplifies their use. | |||
| o The uncompressed point format MUST be supported. Other point | o The uncompressed point format MUST be supported. Other point | |||
| formats MAY be used. | formats MAY be used. | |||
| o The client SHOULD offer the elliptic_curves extension and the | o The client SHOULD offer the elliptic_curves extension and the | |||
| server SHOULD expect to receive it. | server SHOULD expect to receive it. | |||
| o The client MAY offer the ec_point_formats extension, but the | o The client MAY offer the ec_point_formats extension, but the | |||
| server need not expect to receive it. | server need not expect to receive it. | |||
| o [RFC6090] MAY be used as an implementation method. | o [RFC6090] MAY be used as an implementation method. | |||
| o The server's certificate SHOULD contain a suitable ECC public key, | o Following [RFC4492], the server's certificate MUST contain a | |||
| SHOULD be signed with a suitable ECC public key, and the elliptic | suitable ECC public key, and MUST be signed with a suitable ECC | |||
| curve and hash function SHOULD be selected to ensure a uniform | public key. The elliptic curve and hash function SHOULD be | |||
| security level; guidance on acceptable choices of hashes and | selected to ensure a uniform security level; guidance on | |||
| curves that can be used with each ciphersuite is detailed in | acceptable choices of hashes and curves that can be used with each | |||
| Section 2.2. The Signature Algorithms extension (Section | ciphersuite is detailed in Section 2.2. The Signature Algorithms | |||
| 7.4.1.4.1 of [RFC5246]) SHOULD be used to indicate support of | extension (Section 7.4.1.4.1 of [RFC5246]) SHOULD be used to | |||
| those signature and hash algorithms. If a client certificate is | indicate support of those signature and hash algorithms. If a | |||
| used, the same criteria SHOULD apply to it. | client certificate is used, the same criteria SHOULD apply to it. | |||
| Implementations of these ciphersuites will interoperate with | Implementations of these ciphersuites will interoperate with | |||
| [RFC4492], but can be more compact than a full implementation of that | [RFC4492], but can be more compact than a full implementation of that | |||
| RFC. | RFC. | |||
| 2.1. AEAD algorithms | 2.1. AEAD algorithms | |||
| The following AEAD algorithms are used: | The following AEAD algorithms are used: | |||
| AEAD_AES_128_CCM is used in the TLS_ECDHE_ECDSA_WITH_AES_128_CCM | AEAD_AES_128_CCM is used in the TLS_ECDHE_ECDSA_WITH_AES_128_CCM | |||
| skipping to change at page 6, line 7 ¶ | skipping to change at page 6, line 7 ¶ | |||
| the TLSCiphertext structure does not have the "aead" option in TLS | the TLSCiphertext structure does not have the "aead" option in TLS | |||
| 1.1. Because TLS has no way for the client to indicate that it | 1.1. Because TLS has no way for the client to indicate that it | |||
| supports TLS 1.2 but not earlier, a non-compliant server might | supports TLS 1.2 but not earlier, a non-compliant server might | |||
| potentially negotiate TLS 1.1 or earlier and select one of the cipher | potentially negotiate TLS 1.1 or earlier and select one of the cipher | |||
| suites in this document. Clients MUST check the TLS version and | suites in this document. Clients MUST check the TLS version and | |||
| generate a fatal "illegal_parameter" alert if they detect an | generate a fatal "illegal_parameter" alert if they detect an | |||
| incorrect version. | incorrect version. | |||
| 4. History | 4. History | |||
| The 08 version changed a MUST to a SHOULD to align with [RFC4492] and | ||||
| tweaked text identified during IESG review. It also adds text | ||||
| describing the unfortunate interaction between PKCS 11 and the TLS | ||||
| AEAD ciphersuites that Mike StJohns identified. | ||||
| The 07 version removed the mandatory-to-implement elliptic curves and | The 07 version removed the mandatory-to-implement elliptic curves and | |||
| hash functions, and replaced them with non-normative guidance, which | hash functions, and replaced them with non-normative guidance, which | |||
| is in Appendix A. | is in Appendix A. | |||
| The 06 version replaced obsoleted references with updated ones to | The 06 version replaced obsoleted references with updated ones to | |||
| RFC6066, RFC6655, RFC5246, fixes a boilerplate error, and corrects | RFC6066, RFC6655, RFC5246, fixes a boilerplate error, and corrects | |||
| the section reference for the truncated HMAC RFC. It also changes | the section reference for the truncated HMAC RFC. It also changes | |||
| the mandatory-to-implement curves and hash algorithms to be less | the mandatory-to-implement curves and hash algorithms to be less | |||
| restrictive, so that the specification can potentially be used with | restrictive, so that the specification can potentially be used with | |||
| curves other than secp256r1, secp384r1, and secp521r1. A reference | curves other than secp256r1, secp384r1, and secp521r1. A reference | |||
| skipping to change at page 7, line 4 ¶ | skipping to change at page 7, line 6 ¶ | |||
| This section is to be removed by the RFC editor upon publication. | This section is to be removed by the RFC editor upon publication. | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| IANA is requested to assign the values for the ciphersuites defined | IANA is requested to assign the values for the ciphersuites defined | |||
| in Section Section 2 from the TLS and DTLS CipherSuite registries. | in Section Section 2 from the TLS and DTLS CipherSuite registries. | |||
| IANA, please note that the DTLS-OK column should be marked as "Y" for | IANA, please note that the DTLS-OK column should be marked as "Y" for | |||
| each of these algorithms. | each of these algorithms. | |||
| 6. Security Considerations | 6. Security Considerations | |||
| 6.1. Perfect Forward Secrecy | 6.1. Perfect Forward Secrecy | |||
| The perfect forward secrecy properties of ephemeral Diffie-Hellman | The perfect forward secrecy properties of ephemeral Diffie-Hellman | |||
| ciphersuites are discussed in the security analysis of [RFC5246]. | ciphersuites are discussed in the security analysis of [RFC5246]. | |||
| This analysis applies to the ECDHE ciphersuites. | This analysis applies to the ECDHE ciphersuites. | |||
| 6.2. Counter Reuse | 6.2. Counter Reuse | |||
| AES-CCM security requires that the counter is never reused. The IV | AES-CCM security requires that the counter is never reused. The | |||
| construction in Section 2 is designed to prevent counter reuse. | nonce construction in Section 2 is designed to prevent counter reuse. | |||
| 6.3. Hardware Security Modules | ||||
| A ciphersuite can be implemented in such a way that the secret keys | ||||
| and private keys are stored inside a Hardware Security Module (HSM), | ||||
| and the cryptographic operations involving those keys are performed | ||||
| by the HSM on data provided by an application interacting with the | ||||
| HSM through an interface such as that defined by the Cryptographic | ||||
| Token Interface Standard [PKCS11]. When an AEAD ciphersuite, such as | ||||
| those in this note, are implemented in this way, special handling of | ||||
| the nonce is required. This is because the "salt" part of the nonce | ||||
| is set to the client_write_IV or server_write_IV, which is a function | ||||
| of the TLS master secret. | ||||
| Another potential issue with the Cryptographic Token Interface | ||||
| Standard is that the use of the DecryptUpdate function is not | ||||
| possible with the CCM decrypt operation, or the decrypt operation any | ||||
| other authenticated encryption method. This is because the | ||||
| DecryptUpdate requires that post-decryption plaintext be returned | ||||
| before the authentication check is completed. | ||||
| 7. Acknowledgements | 7. Acknowledgements | |||
| This draft borrows heavily from [RFC5288]. Thanks are due to Robert | This draft borrows heavily from [RFC5288]. Thanks are due to Robert | |||
| Cragie for his great help in making this work complete, correct, and | Cragie for his great help in making this work complete, correct, and | |||
| useful, and to Peter Dettman for his review. | useful, and to Peter Dettman for his review. Thanks also to Mike | |||
| StJohns for pointing out the HSM issues. | ||||
| This draft is motivated by the considerations raised in the Zigbee | This draft is motivated by the considerations raised in the Zigbee | |||
| Smart Energy 2.0 working group. | Smart Energy 2.0 working group. | |||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [AES] National Institute of Standards and Technology, | [AES] National Institute of Standards and Technology, | |||
| "Specification for the Advanced Encryption Standard | "Specification for the Advanced Encryption Standard | |||
| (AES)", FIPS 197, November 2001. | (AES)", FIPS 197, November 2001. | |||
| [CCM] National Institute of Standards and Technology, | [CCM] National Institute of Standards and Technology, | |||
| "Recommendation for Block Cipher Modes of Operation: The | "Recommendation for Block Cipher Modes of Operation: The | |||
| CCM Mode for Authentication and Confidentiality", SP 800- | CCM Mode for Authentication and Confidentiality", SP 800- | |||
| 38C, May 2004. | 38C, May 2004. | |||
| skipping to change at page 8, line 37 ¶ | skipping to change at page 9, line 12 ¶ | |||
| "Recommendation for Key Management - Part 1: General | "Recommendation for Key Management - Part 1: General | |||
| (Revision 3)", SP 800-57 Part 1, July 2012. | (Revision 3)", SP 800-57 Part 1, July 2012. | |||
| 8.2. Informative References | 8.2. Informative References | |||
| [IEEE802154] | [IEEE802154] | |||
| Institute of Electrical and Electronics Engineers, | Institute of Electrical and Electronics Engineers, | |||
| "Wireless Personal Area Networks", IEEE Standard 802.15.4- | "Wireless Personal Area Networks", IEEE Standard 802.15.4- | |||
| 2006, 2006. | 2006, 2006. | |||
| [PKCS11] RSA Laboratories, "PKCS #11: Cryptographic Token Interface | ||||
| Standard version 2.20", Public Key Cryptography | ||||
| Standards PKCS#11-v2.20, 2004. | ||||
| [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM | [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM | |||
| Mode with IPsec Encapsulating Security Payload (ESP)", | Mode with IPsec Encapsulating Security Payload (ESP)", | |||
| RFC 4309, December 2005. | RFC 4309, December 2005. | |||
| Appendix A. Recommended Curves and Algorithms | Appendix A. Recommended Curves and Algorithms | |||
| This memo does not mandate any particular elliptic curves or | This memo does not mandate any particular elliptic curves or | |||
| cryptographic algorithms, for the sake of flexibility. However, | cryptographic algorithms, for the sake of flexibility. However, | |||
| since the main motivation for the AES-CCM-ECC ciphersuites is their | since the main motivation for the AES-CCM-ECC ciphersuites is their | |||
| suitability for constrained environments, it is valuable to identify | suitability for constrained environments, it is valuable to identify | |||
| a particular suitable set of curves and algorithms. | a particular suitable set of curves and algorithms. | |||
| This appendix identifies a set of elliptic curves and cryptographic | This appendix identifies a set of elliptic curves and cryptographic | |||
| algorithms that meet the requirements of this note, which are widely | algorithms that meet the requirements of this note, which are widely | |||
| supported and believed to be secure. | supported and believed to be secure. | |||
| The curves and hash algorithms recommended for each ciphersuite are: | The curves and hash algorithms recommended for each ciphersuite are: | |||
| An implementation that includes either | An implementation that includes either | |||
| TLS_ECDHE_ECDSA_WITH_AES_128_CCM or | TLS_ECDHE_ECDSA_WITH_AES_128_CCM or | |||
| TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 MUST support the secp256r1 | TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 SHOULD support the secp256r1 | |||
| curve and the SHA-256 hash function. | curve and the SHA-256 hash function. | |||
| An implementation that includes either | An implementation that includes either | |||
| TLS_ECDHE_ECDSA_WITH_AES_256_CCM or | TLS_ECDHE_ECDSA_WITH_AES_256_CCM or | |||
| TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 MUST support the secp384r1 | TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 SHOULD support the secp384r1 | |||
| curve and the SHA-384 hash function, and MAY support the secp521r1 | curve and the SHA-384 hash function, and MAY support the secp521r1 | |||
| curve and the SHA-512 hash function. | curve and the SHA-512 hash function. | |||
| More information about the secp256r1, secp384r1, and secp521r1 curves | More information about the secp256r1, secp384r1, and secp521r1 curves | |||
| is available in Appendix A of [RFC4492]. | is available in Appendix A of [RFC4492]. | |||
| It is not necessary to implement the above curves and hash functions | It is not necessary to implement the above curves and hash functions | |||
| in order to conform to this specification. Other elliptic curves, | in order to conform to this specification. Other elliptic curves, | |||
| such as the Brainpool curves [RFC5639] for example, meet the criteria | such as the Brainpool curves [RFC5639] for example, meet the criteria | |||
| laid out in this memo. | laid out in this memo. | |||
| End of changes. 25 change blocks. | ||||
| 41 lines changed or deleted | 72 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/ | ||||