idnits 2.17.00 (12 Aug 2021) /tmp/idnits36572/draft-badra-ecdhe-tls-psk-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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 220. 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 (February 1, 2008) is 5216 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 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: Informational February 1, 2008 4 Expires: July 2008 6 ECDHE_PSK Ciphersuites for Transport Layer Security (TLS) 7 draft-badra-ecdhe-tls-psk-03.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on July 31, 2008. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2008). 37 Abstract 39 This document extends RFC 4279 and RFC 4785 and specifies a set of 40 ciphersuites that use an Elliptic Curve Diffie-Hellman exchange 41 authenticated with a pre-shared key. These ciphersuites provide 42 Perfect Forward Secrecy. It also specifies one authentication-only 43 ciphersuites (with no encryption). This ciphersuite is useful when 44 authentication and integrity protection is desired, but 45 confidentiality is not needed or not permitted. 47 The reader is expected to become familiar with RFC 4279 and RFC 4785 48 prior to studying this document. 50 1. Introduction 52 RFC 4279 specifies ciphersuites for supporting TLS using pre-shared 53 symmetric keys and they (a) use only symmetric key operations for 54 authentication, (b) use a Diffie-Hellman exchange authenticated with 55 a pre-shared key, or (c) combines public key authentication of the 56 server with pre-shared key authentication of the client. 58 RFC 4785 specifies authentication-only ciphersuites (with no 59 encryption). 61 This document specifies a set of ciphersuites that use an Elliptic 62 Curve Diffie-Hellman exchange authenticated with a pre-shared key. 63 These ciphersuites provide Perfect Forward Secrecy. This document 64 also specifies one authentication-only ciphersuites (with no 65 encryption). This ciphersuite is useful when authentication and 66 integrity protection is desired, but confidentiality is not needed or 67 not permitted. 69 1.1. Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. ECDHE_PSK Key Exchange Algorithm 77 The ciphersuites in this section match the ciphersuites defined in 78 [RFC4279], except that they use an Elliptic Curve Diffie-Hellman 79 exchange [RFC4492] authenticated with a pre-shared key. They are 80 defined as follow: 82 CipherSuite Key Exchange Cipher Hash 84 TLS_ECDHE_PSK_WITH_RC4_128_SHA ECDHE_PSK RC4_128 SHA 85 TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA ECDHE_PSK 3DES_EDE_CBC SHA 86 TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA ECDHE_PSK AES_128_CBC SHA 87 TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA ECDHE_PSK AES_256_CBC SHA 89 When the ciphersuites defined in this document are used, the 90 'ec_diffie_hellman_psk' case inside the ServerKeyExchange and 91 ClientKeyExchange structure is used instead of the 'psk' case defined 92 in [RFC4279] (i.e. The ServerKeyExchange and ClientKeyExchange 93 messages include the Diffie-Hellman parameters). The PSK identity and 94 identity hint fields MUST have the same meaning specified in 95 [RFC4279] (note that the ServerKeyExchange message is always sent, 96 even if no PSK identity hint is provided). 98 The format of the ServerKeyExchange and ClientKeyExchange messages is 99 shown below. 101 struct { 102 select (KeyExchangeAlgorithm) { 103 /* other cases for rsa, diffie_hellman, etc. */ 104 case ec_diffie_hellman_psk: /* NEW */ 105 opaque psk_identity_hint<0..2^16-1>; 106 ServerECDHParams params; 107 }; 108 } ServerKeyExchange; 110 struct { 111 select (KeyExchangeAlgorithm) { 112 /* other cases for rsa, diffie_hellman, etc. */ 113 case ec_diffie_hellman_psk: /* NEW */ 114 opaque psk_identity<0..2^16-1>; 115 ClientECDiffieHellmanPublic public; 116 } exchange_keys; 117 } ClientKeyExchange; 119 The premaster secret is formed as follows. First, perform an ECDH 120 operation (See section 5.10 of [RFC4492]) to compute the shared 121 secret. Next, concatenate a uint16 containing the length of the 122 shared secret (in octets), the shared secret itself, a uint16 123 containing the length of the PSK (in octets), and the PSK itself. 125 This corresponds to the general structure for the premaster secrets 126 (see Note 1 in Section 2 of [RFC4279]), with "other_secret" 127 containing the shared secret: 129 struct { 130 opaque other_secret<0..2^16-1>; 131 opaque psk<0..2^16-1>; 132 }; 134 3. 2. ECDHE_PSK Key Exchange Algorithm with NULL Encryption 136 The ciphersuite in this section matches the ciphersuites defined in 137 [RFC4785], except that it uses an Elliptic Curve Diffie-Hellman 138 exchange authenticated with a pre-shared key. 140 CipherSuite Key Exchange Cipher Hash 142 TLS_ECDHE_PSK_WITH_NULL_SHA ECDHE_PSK NULL SHA 144 4. Security Considerations 146 The security considerations described throughout [RFC4346], [RFC4785] 147 and [RFC4279] apply here as well. 149 5. IANA Considerations 151 This document defines the following new ciphersuites, whose values 152 are to be assigned from the TLS Cipher Suite registry defined in 153 [RFC4346]. 155 CipherSuite TLS_ECDHE_PSK_WITH_RC4_128_SHA = { 0xXX, 0xXX }; 156 CipherSuite TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0xXX, 0xXX }; 157 CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA = { 0xXX, 0xXX }; 158 CipherSuite TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA = { 0xXX, 0xXX }; 159 CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA = { 0xXX, 0xXX }; 161 6. Acknowledgments 163 The author would like to thank Bodo Moeller, Simon Josefsson, Uri 164 Blumenthal, Pasi Eronen, and the TLS mailing list members for their 165 comments on the document. 167 7. References 169 7.1. Normative References 171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 172 Requirement Levels", BCP 14, RFC 2119, March 1997. 174 [RFC4346] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", 175 RFC 4346, April 200P. 177 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 178 for Transport Layer Security (TLS)", RFC 4279, December 179 2005. 181 [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK) 182 Ciphersuites with NULL Encryption for Transport Layer 183 Security (TLS)", RFC 4785, January 2007. 185 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., 186 Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher 187 Suites for Transport Layer Security (TLS)", RFC 4492, May 188 2006. 190 Author's Addresses 192 Mohamad Badra 193 LIMOS Laboratory - UMR6158, CNRS 194 France 196 Email: badra@isima.fr 198 Intellectual Property Statement 200 The IETF takes no position regarding the validity or scope of any 201 Intellectual Property Rights or other rights that might be claimed to 202 pertain to the implementation or use of the technology described in 203 this document or the extent to which any license under such rights 204 might or might not be available; nor does it represent that it has 205 made any independent effort to identify any such rights. Information 206 on the procedures with respect to rights in RFC documents can be 207 found in BCP 78 and BCP 79. 209 Copies of IPR disclosures made to the IETF Secretariat and any 210 assurances of licenses to be made available, or the result of an 211 attempt made to obtain a general license or permission for the use of 212 such proprietary rights by implementers or users of this 213 specification can be obtained from the IETF on-line IPR repository at 214 http://www.ietf.org/ipr. 216 The IETF invites any interested party to bring to its attention any 217 copyrights, patents or patent applications, or other proprietary 218 rights that may cover technology that may be required to implement 219 this standard. Please address the information to the IETF at 220 ietf-ipr@ietf.org. 222 Disclaimer of Validity 224 This document and the information contained herein are provided on an 225 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 226 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 227 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 228 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 229 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 230 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 232 Copyright Statement 234 Copyright (C) The IETF Trust (2008). 236 This document is subject to the rights, licenses and restrictions 237 contained in BCP 78, and except as set forth therein, the authors 238 retain all their rights. 240 Acknowledgment 242 Funding for the RFC Editor function is currently provided by the 243 Internet Society.