idnits 2.17.1 draft-badra-tls-psk-new-mac-aes-gcm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 323. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 17, 2008) is 5823 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBC' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TLS Working Group Mohamad Badra 2 Internet Draft LIMOS Laboratory 3 Intended status: Standards Track May 17, 2008 4 Expires: October 2008 6 Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with 7 SHA-256/384 and AES Galois Counter Mode 8 draft-badra-tls-psk-new-mac-aes-gcm-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on October 17, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 RFC 4279 and RFC 4785 describe pre-shared key cipher suites for 42 Transport Layer Security (TLS). However, all those cipher suites 43 use SHA-1 as their MAC algorithm. This document describes a set of 44 cipher suites for TLS/DTLS which uses stronger digest algorithms 45 (i.e., SHA-256 or SHA-384) and another which uses the Advanced 46 Encryption Standard (AES) in Galois Counter Mode (GCM). 48 Table of Contents 50 1. Introduction...................................................3 51 1.1. Conventions used in this document.........................3 52 2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM..3 53 3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384.........4 54 3.1. PSK Key Exchange Algorithm with SHA-256/384...............4 55 3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384...........5 56 3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384...........5 57 4. Security Considerations........................................5 58 5. IANA Considerations............................................5 59 6. Acknowledgments................................................6 60 7. References.....................................................6 61 7.1. Normative References......................................6 62 7.2. Informative References....................................7 63 Author's Addresses................................................7 64 Intellectual Property and Copyright Statements....................8 66 1. Introduction 68 TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated 69 encryption with additional data (AEAD) cipher modes [RFC5116]. This 70 document describes the use of Advanced Encryption Standard (AES) 71 [AES] in Galois Counter Mode (GCM) [GCM] (AES-GCM) with various pre- 72 shared key (PSK) key exchange mechanisms ([RFC4279] and [RFC4785]) 73 as a cipher suite for Transport Layer Security (TLS). 75 This document also specifies PSK cipher suites for TLS which replace 76 SHA-1 by SHA-256 or SHA-384 [SHS]. RFC 4279 [RFC4279] and RFC 4785 77 [RFC4785] describe PSK cipher suites for TLS. However, all of the 78 RFC 4279 and the RFC 4785 cipher suites use HMAC-SHA1 as their MAC 79 algorithm. Due to recent analytic work on SHA-1 [Wang05], the IETF 80 is gradually moving away from SHA-1 and towards stronger hash 81 algorithms. 83 ECC based cipher suites with SHA-256/384 and AES-GCM are defined in 84 [I-D.ietf-tls-ecc-new-mac]; RSA, DSS and Diffie-Hellman based cipher 85 suites are specified in [I-D.ietf-tls-rsa-aes-gcm]. The reader is 86 expected to become familiar with these two memos prior to studying 87 this document. 89 1.1. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM 97 The following eight cipher suites use the new authenticated 98 encryption modes defined in TLS 1.2 with AES in Galois Counter Mode 99 (GCM) [GCM]. The cipher suites with DHE_PSK key exchange algorithm 100 (TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 and 101 TLS_DHE_PSK_WITH_AES_128_GCM_SHA348) provide Perfect Forward Secrecy 102 (PFS). 104 CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 105 CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256 = {0xXX,0xXX}; 106 CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384 = {0xXX,0xXX}; 107 CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 108 CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 109 CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 110 CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 111 CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 113 These cipher suites use authenticated encryption with additional 114 data (AEAD) algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM 115 described in RFC 5116. GCM is used as described in [I-D.ietf-tls- 116 rsa-aes-gcm]. 118 The PSK, DHE_PSK and RSA_PSK key exchanges are performed as defined 119 in [RFC4279]. 121 The PRFs SHALL be as follows: 123 For cipher suites ending with _SHA256, the PRF is the TLS PRF 124 [I-D.ietf-tls-rfc4346-bis] with SHA-256 as the hash function. 126 For cipher suites ending with _SHA384, the PRF is the TLS PRF 127 [I-D.ietf-tls-rfc4346-bis] with SHA-384 as the hash function. 129 Implementations MUST send TLS Alert bad_record_mac for all types of 130 failures encountered in processing the AES-GCM algorithm. 132 3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384 134 The cipher suites described in this section use AES [AES] in CBC 135 [CBC] mode with an HMAC-based MAC. 137 3.1. PSK Key Exchange Algorithm with SHA-256/384 139 CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 140 CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256 = {0xXX,0xXX}; 141 CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384 = {0xXX,0xXX}; 142 CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 143 CipherSuite TLS_PSK_WITH_NULL_SHA256 = {0xXX,0xXX}; 144 CipherSuite TLS_PSK_WITH_NULL_SHA384 = {0xXX,0xXX}; 146 The above six cipher suites are the same as the corresponding cipher 147 suites in RFC 4279 and RFC 4785 (with names ending in "_SHA" in 148 place of "_SHA256" or "_SHA384"), except for the hash and PRF 149 algorithms. 151 The PRF and MAC algorithms SHALL be as follows: 153 For cipher suites ending with _SHA256, the PRF is the TLS PRF 154 [I-D.ietf-tls-rfc4346-bis] with SHA-256 as the hash function. 155 The MAC is HMAC [RFC2104] with SHA-256 as the hash function. 157 For cipher suites ending with _SHA384, the PRF is the TLS PRF 158 [I-D.ietf-tls-rfc4346-bis] with SHA-384 as the hash function. 159 The MAC is HMAC [RFC2104] with SHA-384 as the hash function. 161 3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384 163 CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 164 CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384 = {0xXX,0xXX}; 165 CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256 = {0xXX,0xXX}; 166 CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 167 CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256 = {0xXX,0xXX}; 168 CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384 = {0xXX,0xXX}; 170 The above six cipher suites are the same as the corresponding cipher 171 suites in RFC 4279 and RFC 4785 (with names ending in "_SHA" in 172 place of "_SHA256" or "_SHA384"), except for the hash and PRF 173 algorithms, as explained in section 3.1. 175 3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384 177 CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 178 CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384 = {0xXX,0xXX}; 179 CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256 = {0xXX,0xXX}; 180 CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 182 The above four cipher suites are the same as the corresponding 183 cipher suites in RFC 4279 and RFC 4785 (with names ending in "_SHA" 184 in place of "_SHA256" or "_SHA384"), except for the hash and PRF 185 algorithms, as explained in section 3.1. 187 4. Security Considerations 189 The security considerations in RFC 4279, RFC 4758, and [I-D.ietf- 190 tls-rsa-aes-gcm] apply to this document as well. In addition, as 191 described in [I-D.ietf-tls-rsa-aes-gcm], these cipher suites may 192 only be used with TLS 1.2 or greater. 194 5. IANA Considerations 196 IANA has assigned the following values for the cipher suites defined 197 in this document: 199 CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 200 CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256 = {0xXX,0xXX}; 201 CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384 = {0xXX,0xXX}; 202 CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 203 CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 204 CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 205 CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 206 CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 207 CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 208 CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256 = {0xXX,0xXX}; 209 CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384 = {0xXX,0xXX}; 210 CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 211 CipherSuite TLS_PSK_WITH_NULL_SHA256 = {0xXX,0xXX}; 212 CipherSuite TLS_PSK_WITH_NULL_SHA384 = {0xXX,0xXX}; 213 CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 214 CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384 = {0xXX,0xXX}; 215 CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256 = {0xXX,0xXX}; 216 CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 217 CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256 = {0xXX,0xXX}; 218 CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384 = {0xXX,0xXX}; 219 CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 220 CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384 = {0xXX,0xXX}; 221 CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256 = {0xXX,0xXX}; 222 CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 224 6. Acknowledgments 226 This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac] and [I- 227 D.ietf-tls-rsa-aes-gcm]. 229 The author appreciates Alfred Hoenes for his detailed review and 230 effort on issues resolving discussion. The author would like also 231 to acknowledge Ibrahim Hajjeh, Simon Josefsson, Hassnaa Moustafa, 232 Joseph Salowey and Pascal Urien for their reviews of the content of 233 the document. 235 7. References 237 7.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [I-D.ietf-tls-rfc4346-bis] 243 Dierks, T. and E. Rescorla, "The Transport Layer Security 244 (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis- 245 10, work in progress, March 2008. 247 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 248 Hashing for Message Authentication", RFC 2104, February 249 1997. 251 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 252 Encryption", RFC 5116, January 2008. 254 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 255 for Transport Layer Security (TLS)", RFC 4279, December 256 2005. 258 [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK) 259 Ciphersuites with NULL Encryption for Transport Layer 260 Security (TLS)", RFC 4785, January 2007. 262 [AES] National Institute of Standards and Technology, 263 "Specification for the Advanced Encryption Standard 264 (AES)", FIPS 197, November 2001. 266 [SHS] National Institute of Standards and Technology, "Secure 267 Hash Standard", FIPS 180-2, August 2002. 269 [CBC] National Institute of Standards and Technology, 270 "Recommendation for Block Cipher Modes of Operation - 271 Methods and Techniques", SP 800-38A, December 2001. 273 [GCM] National Institute of Standards and Technology, 274 "Recommendation for Block Cipher Modes of Operation: 275 Galois/Counter Mode (GCM) for Confidentiality and 276 Authentication", SP 800-38D, November 2007. 278 [I-D.ietf-tls-rsa-aes-gcm] 279 Salowey, J., A. Choudhury, and C. McGrew, "RSA based AES- 280 GCM Cipher Suites for TLS", draft-ietf-tls-rsa-aes-gcm-03 281 (work in progress), April 2008. 283 7.2. Informative References 285 [Wang05] Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 286 Full SHA-1", CRYPTO 2005, August 2005. 288 [I-D.ietf-tls-ecc-new-mac] 289 Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 290 256/384 and AES Galois Counter Mode", draft-ietf-tls-ecc- 291 new-mac-07 (work in progress), May 2008. 293 Author's Addresses 295 Mohamad Badra 296 LIMOS Laboratory - UMR6158, CNRS 297 France 299 Email: badra@isima.fr 301 Intellectual Property Statement 303 The IETF takes no position regarding the validity or scope of any 304 Intellectual Property Rights or other rights that might be claimed 305 to pertain to the implementation or use of the technology described 306 in this document or the extent to which any license under such 307 rights might or might not be available; nor does it represent that 308 it has made any independent effort to identify any such rights. 309 Information on the procedures with respect to rights in RFC 310 documents can be found in BCP 78 and BCP 79. 312 Copies of IPR disclosures made to the IETF Secretariat and any 313 assurances of licenses to be made available, or the result of an 314 attempt made to obtain a general license or permission for the use 315 of such proprietary rights by implementers or users of this 316 specification can be obtained from the IETF on-line IPR repository 317 at http://www.ietf.org/ipr. 319 The IETF invites any interested party to bring to its attention any 320 copyrights, patents or patent applications, or other proprietary 321 rights that may cover technology that may be required to implement 322 this standard. Please address the information to the IETF at 323 ietf-ipr@ietf.org. 325 Disclaimer of Validity 327 This document and the information contained herein are provided on 328 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 329 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 330 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 331 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 332 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 333 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 334 FOR A PARTICULAR PURPOSE. 336 Copyright Statement 338 Copyright (C) The IETF Trust (2008). 340 This document is subject to the rights, licenses and restrictions 341 contained in BCP 78, and except as set forth therein, the authors 342 retain all their rights. 344 Acknowledgment 346 Funding for the RFC Editor function is currently provided by the 347 Internet Society.