idnits 2.17.1 draft-ietf-tls-psk-new-mac-aes-gcm-05.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 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 346. 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 (October 31, 2008) is 5649 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBC' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 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 October 31, 2008 4 Expires: April 2009 6 Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with 7 SHA-256/384 and AES Galois Counter Mode 8 draft-ietf-tls-psk-new-mac-aes-gcm-05.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 April 31, 2009. 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 pre-shared key cipher suites for TLS which uses stronger digest 45 algorithms (i.e., SHA-256 or SHA-384) and another set which uses the 46 Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). 48 Table of Contents 50 1. Introduction...................................................3 51 1.1. Applicability Statement...................................3 52 1.2. Conventions used in this document.........................4 53 2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM..4 54 3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384.........4 55 3.1. PSK Key Exchange Algorithm with SHA-256/384...............5 56 3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384...........5 57 3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384...........5 58 4. Security Considerations........................................6 59 5. IANA Considerations............................................6 60 6. Acknowledgments................................................7 61 7. References.....................................................7 62 7.1. Normative References......................................7 63 7.2. Informative References....................................8 64 Author's Addresses................................................8 65 Intellectual Property Statement...................................8 66 Disclaimer of Validity............................................9 68 1. Introduction 70 The benefits of pre-shared symmetric-key vs. public-/private-key 71 pair based authentication for the key exchange in TLS have been 72 explained in the Introduction of [RFC4279]. This document leverages 73 the already defined algorithms for the application of newer, 74 generally regarded stronger, cryptographic primitives and building 75 blocks. 77 TLS 1.2 [RFC5246] adds support for authenticated encryption with 78 additional data (AEAD) cipher modes [RFC5116]. This document 79 describes the use of Advanced Encryption Standard (AES) [AES] in 80 Galois Counter Mode (GCM) [GCM] (AES-GCM) with various pre-shared 81 key (PSK) authenticated key exchange mechanisms ([RFC4279] and 82 [RFC4785]) in cipher suites for Transport Layer Security (TLS). 84 This document also specifies PSK cipher suites for TLS which replace 85 SHA-1 by SHA-256 or SHA-384 [SHS]. RFC 4279 [RFC4279] and RFC 4785 86 [RFC4785] describe PSK cipher suites for TLS. However, all of the 87 RFC 4279 and the RFC 4785 cipher suites use HMAC-SHA1 as their MAC 88 algorithm. Due to recent analytic work on SHA-1 [Wang05], the IETF 89 is gradually moving away from SHA-1 and towards stronger hash 90 algorithms. 92 Related TLS cipher suites with key exchange algorithms that are 93 authenticated using public/private key pairs have recently been 94 specified: 96 - RSA, DSS, and Diffie-Hellman based cipher suites in [RFC5288], 97 and 99 - ECC based cipher suites with SHA-256/384 and AES-GCM in 100 [RFC5289]. 102 The reader is expected to become familiar with these two memos prior 103 to studying this document. 105 1.1. Applicability Statement 107 The cipher suites defined in Section 3 can be negotiated, whatever 108 the negotiated TLS version is. 110 The cipher suites defined in Section 2 can be negotiated in TLS 111 version 1.2 or higher. 113 1.2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM 121 The following six cipher suites use the new authenticated encryption 122 modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) 123 [GCM]. The cipher suites with DHE_PSK key exchange algorithm 124 (TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 and 125 TLS_DHE_PSK_WITH_AES_256_GCM_SHA348) provide Perfect Forward Secrecy 126 (PFS). 128 CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 129 CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 130 CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 131 CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 132 CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 133 CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 135 These cipher suites use authenticated encryption with additional 136 data (AEAD) algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM as 137 described in RFC 5116. GCM is used as described in [RFC5288]. 139 The PSK, DHE_PSK and RSA_PSK key exchanges are performed as defined 140 in [RFC4279]. 142 The Pseudo Random Function (PRF) algorithms SHALL be as follows: 144 For cipher suites ending with _SHA256, the PRF is the TLS PRF 145 [RFC5246] with SHA-256 as the hash function. 147 For cipher suites ending with _SHA384, the PRF is the TLS PRF 148 [RFC5246] with SHA-384 as the hash function. 150 Implementations MUST send a TLS Alert 'bad_record_mac' for all types 151 of failures encountered in processing the AES-GCM algorithm. 153 3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384 155 The first two cipher suites described in each of the following three 156 sections use AES [AES] in Cipher Block Chaining (CBC) mode [CBC] for 157 data confidentiality, whereas the other two cipher suites do not 158 provide data confidentiality; all cipher suites provide integrity 159 protection and authentication using HMAC-based MACs. 161 3.1. PSK Key Exchange Algorithm with SHA-256/384 163 CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 164 CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 165 CipherSuite TLS_PSK_WITH_NULL_SHA256 = {0xXX,0xXX}; 166 CipherSuite TLS_PSK_WITH_NULL_SHA384 = {0xXX,0xXX}; 168 The above four cipher suites are the same as the corresponding 169 cipher suites in RFC 4279 and RFC 4785 (with names ending in "_SHA" 170 in place of "_SHA256" or "_SHA384"), except for the hash and PRF 171 algorithms: 173 o For cipher suites with names ending in "_SHA256": 175 - The MAC is HMAC [RFC2104] with SHA-256 as the hash 176 function. 178 - When negotiated in a version of TLS prior to 1.2, the PRF 179 from that version is used; otherwise the PRF is the TLS 180 PRF [RFC5246] with SHA-256 as the hash function. 182 o For cipher suites with names ending in "_SHA384": 184 - The MAC is HMAC [RFC2104] with SHA-384 as the hash 185 function. 187 - When negotiated in a version of TLS prior to 1.2, the PRF 188 from that version is used; otherwise the PRF is the TLS 189 PRF [RFC5246] with SHA-384 as the hash function. 191 3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384 193 CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 194 CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 195 CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256 = {0xXX,0xXX}; 196 CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384 = {0xXX,0xXX}; 198 The above four cipher suites are the same as the corresponding 199 cipher suites in RFC 4279 and RFC 4785 (with names ending in "_SHA" 200 in place of "_SHA256" or "_SHA384"), except for the hash and PRF 201 algorithms, as explained in Section 3.1. 203 3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384 205 CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 206 CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 207 CipherSuite TLS_RSA_PSK_WITH_NULL_SHA256 = {0xXX,0xXX}; 208 CipherSuite TLS_RSA_PSK_WITH_NULL_SHA384 = {0xXX,0xXX}; 210 The above four cipher suites are the same as the corresponding 211 cipher suites in RFC 4279 and RFC 4785 (with names ending in "_SHA" 212 in place of "_SHA256" or "_SHA384"), except for the hash and PRF 213 algorithms, as explained in Section 3.1. 215 4. Security Considerations 217 The security considerations in [RFC4279], [RFC4785] and [RFC5288] 218 apply to this document as well. In particular, as authentication- 219 only cipher suites (with no encryption) defined here do not support 220 confidentiality, care should be taken not to send sensitive 221 information (such as passwords) over connections protected with one 222 of the cipher suites with NULL encryption defined in this document. 224 As described in [RFC5288], the cipher suites defined in the Section 225 2 of this document may only be used with TLS 1.2 or greater. The 226 cipher suites defined in the Section 3 may be used, whatever the 227 negotiated TLS version is. 229 5. IANA Considerations 231 IANA has assigned the following values for the cipher suites defined 232 in this document: 234 CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 235 CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 236 CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 237 CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 238 CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256 = {0xXX,0xXX}; 239 CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384 = {0xXX,0xXX}; 240 CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 241 CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 242 CipherSuite TLS_PSK_WITH_NULL_SHA256 = {0xXX,0xXX}; 243 CipherSuite TLS_PSK_WITH_NULL_SHA384 = {0xXX,0xXX}; 244 CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 245 CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 246 CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256 = {0xXX,0xXX}; 247 CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384 = {0xXX,0xXX}; 248 CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 = {0xXX,0xXX}; 249 CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384 = {0xXX,0xXX}; 250 CipherSuite TLS_RSA_PSK_WITH_NULL_SHA256 = {0xXX,0xXX}; 251 CipherSuite TLS_RSA_PSK_WITH_NULL_SHA384 = {0xXX,0xXX}; 253 6. Acknowledgments 255 This draft borrows heavily from [RFC5289] and [RFC5288]. 257 The author appreciates Alfred Hoenes for his detailed review and 258 effort on issues resolving discussion. The author would like also 259 to acknowledge Ibrahim Hajjeh, Simon Josefsson, Hassnaa Moustafa, 260 Joseph Salowey and Pascal Urien for their reviews of the content of 261 the document. 263 7. References 265 7.1. Normative References 267 [AES] National Institute of Standards and Technology, 268 "Specification for the Advanced Encryption Standard 269 (AES)", FIPS 197, November 2001. 271 [CBC] National Institute of Standards and Technology, 272 "Recommendation for Block Cipher Modes of Operation - 273 Methods and Techniques", SP 800-38A, December 2001. 275 [GCM] National Institute of Standards and Technology, 276 "Recommendation for Block Cipher Modes of Operation: 277 Galois/Counter Mode (GCM) for Confidentiality and 278 Authentication", SP 800-38D, November 2007. 280 [SHS] National Institute of Standards and Technology, "Secure 281 Hash Standard", FIPS 180-2, August 2002. 283 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 284 Hashing for Message Authentication", RFC 2104, February 285 1997. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 291 for Transport Layer Security (TLS)", RFC 4279, December 292 2005. 294 [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK) 295 Ciphersuites with NULL Encryption for Transport Layer 296 Security (TLS)", RFC 4785, January 2007. 298 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 299 Encryption", RFC 5116, January 2008. 301 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 302 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 304 [RFC5288] Salowey, J., A. Choudhury, and C. McGrew, "RSA based AES- 305 GCM Cipher Suites for TLS", RFC 5288, August 2008. 307 7.2. Informative References 309 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 310 256/384 and AES Galois Counter Mode", RFC 5289, August 311 2008. 313 [Wang05] Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 314 Full SHA-1", CRYPTO 2005, August 2005. 316 Author's Addresses 318 Mohamad Badra 319 LIMOS Laboratory - UMR6158, CNRS 320 France 322 Email: badra@isima.fr 324 Intellectual Property Statement 326 The IETF takes no position regarding the validity or scope of any 327 Intellectual Property Rights or other rights that might be claimed 328 to pertain to the implementation or use of the technology described 329 in this document or the extent to which any license under such 330 rights might or might not be available; nor does it represent that 331 it has made any independent effort to identify any such rights. 332 Information on the procedures with respect to rights in RFC 333 documents can be found in BCP 78 and BCP 79. 335 Copies of IPR disclosures made to the IETF Secretariat and any 336 assurances of licenses to be made available, or the result of an 337 attempt made to obtain a general license or permission for the use 338 of such proprietary rights by implementers or users of this 339 specification can be obtained from the IETF on-line IPR repository 340 at http://www.ietf.org/ipr. 342 The IETF invites any interested party to bring to its attention any 343 copyrights, patents or patent applications, or other proprietary 344 rights that may cover technology that may be required to implement 345 this standard. Please address the information to the IETF at 346 ietf-ipr@ietf.org. 348 Disclaimer of Validity 350 This document and the information contained herein are provided on 351 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 352 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 353 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 354 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 355 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 356 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 357 FOR A PARTICULAR PURPOSE. 359 Copyright Statement 361 Copyright (C) The IETF Trust (2008). 363 This document is subject to the rights, licenses and restrictions 364 contained in BCP 78, and except as set forth therein, the authors 365 retain all their rights. 367 Acknowledgment 369 Funding for the RFC Editor function is currently provided by the 370 Internet Society.