Internet Engineering Task Force D. Harkins, Ed. Internet-Draft Aruba Networks Intended status: Standards Track December 4, 2007 Expires: June 6, 2008 RSA AES-SIV Ciphersuites for TLS draft-harkins-tls-rsa-aes-siv-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo describes two new ciphersuites for the Transport Layer Security (TLS) protocol using the Advanced Encryption Standard (AES) in Synthetic IV (SIV) mode. SIV provides authenticated encryption with associated data (AEAD) and, unlike other AEAD cipher modes, provides resistance to nonce misuse. Harkins Expires June 6, 2008 [Page 1] Internet-Draft TLS RSA AES SIV December 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. RSA-based AES-SIV Cipher Suites . . . . . . . . . . . . . . . . 3 3. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Harkins Expires June 6, 2008 [Page 2] Internet-Draft TLS RSA AES SIV December 2007 1. Introduction This memo describes TLS ciphersuites based on the use of AES [AES] in SIV [SIV-AES] mode. SIV provides nonce-based authenticated encryption with associated data (AEAD) but unlike other cipher modes provides resistance to misuse of the nonce. It is therefore uniquely suited for applications where the supply of nonces is outside the cryptographic engine or where an application developer is responsible for adhering to any guidelines on nonce use. Other AEAD cipher modes can outperform SIV in raw throughput but they are somewhat fragile because their security depends entirely on their proper use. In many cases it is desirable to build a robust system that will be secure even in the presence of unintentional programming errors, system misconfiguration, or intentional misuse. In these cases SIV is more appropriate to use than other AEAD cipher modes. The ciphersuites defined here are used with RSA-based key exchange and can be used in both TLS 1.2 [rfc4346bis] and DTLS [RFC4347] SIV is well-suited for control plane applications. For example CAPWAP, which uses DTLS to protect communications for the provisioning and management of wireless termination points (WTPs) by access controllers (ACs). This traffic will be processed by a control processor on the AC and will therefore have lessened performance requirements and will most likely be handled by an application process written by a programmer who obtains DTLS services through an API. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. RSA-based AES-SIV Cipher Suites The ciphersuites defined herein are based on the AES-SIV authenticated encryption with associated data (AEAD) algorithms AEAD.SIV_CMAC_256 and AEAD.SIV_SIV_CMAC_512 to be described in [AEAD]. The following ciphersuites are defined: CipherSuite TLS_RSA_WITH_AES_SIV_CMAC_256_SHA256 = {TBD1,TBD1} Harkins Expires June 6, 2008 [Page 3] Internet-Draft TLS RSA AES SIV December 2007 CipherSuite TLS_RSA_WITH_AES_SIV_CMAC_512_SHA384 = {TBD2,TBD2} CipherSuite TLS_RSA_DHE_WITH_AES_SIV_CMAC_256_SHA256 = {TBD3,TBD3} CipherSuite TLS_RSA_DHE_WITH_AES_SIV_CMAC_512_SHA384 = {TBD4,TBD4} SIV-AES provides both encryption and authentication using [AES] in [CMAC] mode and [CTR] mode. When the underlying AES cipher uses a 128 bit key SIV-AES takes a 256 bit key as input. When the underlying AES cipher uses a 256 bit key AES-SIV takes a 512 bit key. The nonce used with these cipher suites MUST be 16 octets. It will be carried in the IV field of the GenericAEADCipher structure, therefore for all the algorithms defined in this section SecurityParameters.iv_length=16. SIV is resistant to nonce misuse and therefore there is no uniqueness requirement placed on its nonce. If a nonce is reused authenticity is not affected and confidentiality is affected only to the extent that an attacker would know that the same plaintext, same associated data, and same nonce were protected twice with the same key. The nonce is chosen by the sender and is included in the (D)TLS packet. It SHOULD be harvested from a pool having at least 128 bits of entropy but a non-random source MAY also be used, such as a timestamp or counter. The length of plaintext sent to a ciphersuite defined in this section is indicated by the length in the TLSCompressed structure. The ciphertext output will be expanded by the 128 bits. The RSA and RSA-DHE key exchange are performed as defined in [rfc4346bis]. Cipher modes like SIV that provide authenticated encryption obviate the need for an explicit MAC of the payload. The use of HMAC for data protection has therefore been replaced but a hash function is still used for the TLS PRF. Each ciphersuite defined in this section explicitly specifies the hash algorithm to use with the TLS PRF. The following ciphersuites SHALL use SHA256 as the TLS PRF hash function: TLS_RSA_WITH_AES_SIV_CMAC_256_SHA256 Harkins Expires June 6, 2008 [Page 4] Internet-Draft TLS RSA AES SIV December 2007 TLS_RSA_DHE_WITH_AES_SIV_CMAC_256_SHA256 The following ciphersuites SHALL use SHA384 as the TLS PRF hash function: TLS_RSA_WITH_AES_SIV_CMAC_512_SHA384 TLS_RSA_DHE_WITH_AES_SIV_CMAC_512_SHA384 3. TLS Versions The ciphersuites defined in this memo make use of features defined in TLS 1.2 [rfc4346bis]. Therefore they MUST NOT be used with earlier versions of TLS. Clients MUST NOT offer these ciphersuites if they do not also offer TLS 1.2 or later and servers MUST NOT select one of these ciphers if they select an earlier version. Because TLS does not provide a way for a client to indicate it supports version 1.2 but not earlier versions a non-compliant server may negotiate an earlier version but select one of these ciphersuites. Therefore clients MUST check the TLS version and generate a fatal "illegal_paramter" alert if they detect an incorrect version. 4. IANA Considerations IANA will define the following values for ciphersuites defined in this draft: CipherSuite TLS_RSA_WITH_AES_128_SIV_CMAC_SHA256 = {TBD1,TBD1} CipherSuite TLS_RSA_WITH_AES_256_SIV_CMAC_SHA384 = {TBD2,TBD2} CipherSuite TLS_RSA_DHE_WITH_AES_128_SIV_CMAC_SHA256 = {TBD3,TBD3} CipherSuite TLS_RSA_DHE_WITH_AES_256_SIV_CMAC_SHA384 = {TBD4,TBD4} 5. Security Considerations SIV performs authenticated encryption with associated data. A proof of the security of SIV is in [DAE]. The nonce passed to a ciphersuite defined in this memo SHOULD be unique but in the event that a nonce is reused security is retained. For a fuller description see [SIV-AES]. Harkins Expires June 6, 2008 [Page 5] Internet-Draft TLS RSA AES SIV December 2007 6. Acknowledgements This memo liberally borrows text and format from [gcm-suites] which itself borrows heavily from [tls-ecc-new-mac] and [suiteb-for-tls]. The editor thanks the authors of those drafts for setting a path that has simply been followed. 7. References 7.1. Normative References [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", Internet-Draft: draft-mcgrew-auth-enc-05.txt (a work in progress), February 2007. [AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197. [CMAC] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", NIST Special Pulication 800-38B. [CTR] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", NIST Special Pulication 800-38A, 2001 edition. [DAE] Rogaway, P. and T. Shrimpton, "Deterministic Authenticated Encryption, A Provable-Security Treatment of the Key-Wrap Problem", September 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347. [SIV-AES] Harkins, D., "SIV Authenticated Encryption Using AES", Internet-Draft: draft-dharkins-siv-aes-01 (a work in progress). [rfc4346bis] Bierks, T. and E. Rescorla, "The TLS Protocol Version 1.2", Internet-Draft: draft-ietf-tls-rfc4346-bis-03 (a work in progress). Harkins Expires June 6, 2008 [Page 6] Internet-Draft TLS RSA AES SIV December 2007 7.2. Informative References [gcm-suites] Salowey, J., Choudhury, A., and D. McGrew, "RSA based AES- GCM Cipher Suites for TLS", Internet-Draft: draft-ietf-tls-rsa-aes-gcm-00 (a work in progress). [suiteb-for-tls] Salter, M. and E. Rescorla, "Suite B Cipher Suites for TLS", Internet-Draft: draft-ietf-tls-suiteb-01 (a work in progress). [tls-ecc-new-mac] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 256/384 and AES Galois Counter Mode", Internet-Draft: draft-ietf-tls-ecc-new-mac-01 (a work in progress). Author's Address Dan Harkins (editor) Aruba Networks Email: dharkins@arubanetworks.com Harkins Expires June 6, 2008 [Page 7] Internet-Draft TLS RSA AES SIV December 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Harkins Expires June 6, 2008 [Page 8]