idnits 2.17.1 draft-badra-tls-password-00.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 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 376. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DTLS' is mentioned on line 226, but not defined ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4132 (ref. 'TLSCAM') (Obsoleted by RFC 5932) ** Obsolete normative reference: RFC 3268 (ref. 'TLSAES') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4492 (ref. 'TLSECC') (Obsoleted by RFC 8422) -- Possible downref: Normative reference to a draft: ref. 'TLSCTR' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Badra 3 INTERNET DRAFT LIMOS Laboratory 4 April 19, 2007 Expires: October 2007 6 Password Ciphersuites for Transport Layer Security (TLS) 7 9 Status 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 18 other groups may also distribute working documents as Internet 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on October 19, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document specifies a set of new ciphersuites for the Transport 41 Layer Security (TLS) protocol to support TLS client authentication 42 based on passwords. These ciphersuites provide client credential 43 protection. 45 1 Introduction 47 TLS defines several ciphersuites providing authentication, data 48 protection and session key exchange between two communicating 49 entities. TLS uses public key certificates [TLS], Kerberos [KERB] or 50 preshared key [PSK] for authentication. This document describes how 51 to use passwords, shared in advance among the communicating parties, 52 to authenticate the TLS clients. 54 1.2 Requirements language and Terminologies 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [KEYWORDS]. 60 2. Password Key Exchange Algorithm 62 This document specifies a set of ciphersuites for TLS to make use of 63 existing password databases (e.g. AAA databases) to support client 64 password-based authentication. These ciphersuites reuse existing key 65 exchange algorithms as well as existing MAC, stream and bloc ciphers 66 algorithms from [TLS] and [TLSCTR], [TLSECC], [TLSAES] and [TLSCAM]. 67 Their names include the text "PWD" to refer to the client 68 authentication using passwords. An example is shown below. 70 CipherSuite Key Exchange Cipher Hash 72 TLS_PWD_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA 74 Currently, a set of password authentication modes are available, 75 such as One-time password, pin mode, Token. Some of these modes 76 require multiple exchanges (round-trips) between the client and the 77 server. This document treats currently password authentication modes 78 which don't require more than one round-trip. 80 2.1. Extending the client key exchange message 82 TLS defines the client key exchange message, which is used to convey 83 the premaster secret. This secret is usually set; either through a 84 direct transmission of the RSA-encrypted secret, or by the 85 transmission of Diffie-Hellman parameters which will allow each side 86 to agree upon the same premaster secret. The structure of this 87 message depends on which key exchange method has been selected. The 88 actual TLS specifications define several methods using usually RSA, 89 Diffie_Hellman or PSK algorithms. 91 This document extends the client key exchange message with three new 92 key exchange methods as following. It is described as following: 94 struct { 95 select (KeyExchangeAlgorithm) { 96 /* cases rsa, DH [TLS], ec_diffie_hellman [TLSECC]) */ 97 case pwd_rsa: /* NEW */ 98 EncryptedPreMasterSecret; 99 EncryptedPWD; 100 case pwd_dh: /* NEW */ 101 ClientDiffieHellmanPublic; 102 EncryptedPWD; 103 case pwd_ec_diffie_hellman: /* NEW */ 104 ClientECDiffieHellmanPublic; 105 EncryptedPWD; 106 } exchange_keys; 107 } ClientKeyExchange; 109 2.1.1. Cases pwd_rsa, pwd_dh and pwd_ec_diffie_hellman 111 If pwd_rsa is being used for key agreement, the client generates a 112 48-byte random value (premaster secret), encrypts it using the 113 server public key sent in the server key exchange message or in the 114 server certificate. This is the same as in the RSA key exchange 115 method. In the case of stream cipher encryption, the client 116 generates a fresh random value and concatenates it to its username 117 and password. Therefore, the client symmetrically encrypts the 118 result using the client_write_key. The cipher algorithm is the same 119 selected by the server in the ServerHello.cipher_suite. The result 120 of the above operations called the EncryptedPWD, structured as 121 follow. In the case of block cipher encryption, the client uses an 122 explicit IV and adds padding value to force the length of the 123 plaintext to be an integral multiple of the block cipher's block 124 length, as it is described in section 6.2.3.2 of [TLS1.1]. 126 struct { 127 uint16 length; 128 select (CipherSpec.cipher_type) { 129 case stream: 130 stream-ciphered struct { 131 opaque fresh_random<16..2^16-1>; 132 opaque login<1..2^16-1>; 133 opaque password<1..2^16-1>; 134 }; 135 case block: 136 block-ciphered struct { 137 opaque IV[CipherSpec.block_length]; 138 opaque login<1..2^16-1>; 139 opaque password<1..2^16-1>; 140 uint8 padding[EncryptedPWD.padding_length]; 141 uint8 padding_length; 142 }; 143 } EncryptedPWD; 145 fresh_random 146 A vector contains at least 16 bytes. 148 length 149 The length (in bytes) of the EncryptedPWD structure. 151 padding 152 Padding that is added to force the length of the EncryptedPWD 153 structure to be an integral multiple of the block cipher's block 154 length. The padding MAY be any length up to 255 bytes, as long as 155 it results in the EncryptedPWD.length being an integral 156 multiple of the block length. Lengths longer than necessary might 157 be desirable to frustrate attacks on a protocol that are based on 158 analysis of the lengths of exchanged messages. Each uint8 in the 159 padding data vector MUST be filled with the padding length value. 160 The receiver MUST check this padding and SHOULD use the 161 bad_record_mac alert to indicate padding errors. 163 padding_length 164 The padding length MUST be such that the total size of the 165 EncryptedPWD structure is a multiple of the cipher's block 166 length. Legal values range from zero to 255, inclusive. This 167 length specifies the length of the padding field exclusive of the 168 padding_length field itself. 170 Implementations of this document MUST ensure that all policies being 171 applied on the PSK encoding (section 5 of [PSK]) are applied on the 172 password encoding as well. 174 Editor note: is it more secure to don't send the password on the 175 wire and instead of that, mix it with the premaster secret, and use 176 the result as an input for the key derivation function to implicitly 177 authenticate the client? 179 The client concatenates the EncryptedPreMasterSecret and the 180 EncryptedPWD values before sending the result to the server through 181 the client key exchange message. 183 Upon receipt of this message, the server decrypts the 184 EncryptedPreMasterSecret using its private key and therefore 185 computes the master_secret and derives the same client_write_key. 186 Next, the server symmetrically decrypts the EncryptedPWD to retrieve 187 the client username and the password in clear text. The server then 188 checks its database for a match. If a match is found, the server 189 sends its change cipher spec message and proceeds directly to 190 finished message. If no match is found, the server MUST send a fatal 191 alert, results in the immediate termination of the connection. 193 If the server does not recognize the login, it MAY respond with an 194 "unknown_login" alert message. Alternatively, if the server wishes 195 to hide the fact that the login was not known, it MAY continue the 196 protocol as if the login existed but the key was incorrect: that is, 197 respond with a "decrypt_error" alert. 199 Client Server 200 ------ ------ 202 ClientHello --------> 203 ServerHello 204 Certificate* 205 ServerKeyExchange* 206 <-------- ServerHelloDone 207 ClientKeyExchange 208 ChangeCipherSpec 209 Finished --------> 210 ChangeCipherSpec 211 <-------- Finished 212 Application Data Application Data 213 Attribute Value Pairs Attribute Value Pairs 214 Type Length Value <=======> Type Length Value 216 The pwd_dh case is similar to pwd_rsa, except that the 217 EncryptedPreMasterSecret is replaced with the parameter 218 ClientDiffieHellmanPublic. 220 The pwd_ec_diffie_hellman case is similar to pwd_rsa, except that 221 the EncryptedPreMasterSecret is replaced with the parameter 222 ClientECDiffieHellmanPublic. 224 3. Security Considerations 226 The security considerations described throughout [TLS], [DTLS], and 227 [TLS1.1] apply here as well. 229 4. IANA Considerations 231 This section provides guidance to the IANA regarding registration of 232 values related to the client based-password authentication. 234 Note: For implementation and deployment facilities, it is helpful to 235 reserve a specific registry sub-range (minor, major) for identity 236 protection ciphersuites. 238 CipherSuite TLS_PWD_ITH_RC4_128_MD5 ={ 0xXX,0xXX }; 239 CipherSuite TLS PWD_RSA WITH_RC4_128_SHA ={ 0xXX,0xXX }; 240 CipherSuite TLS_PWD_RSA_WITH_IDEA_CBC_SHA ={ 0xXX,0xXX }; 241 CipherSuite TLS_PWD_RSA_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; 242 CipherSuite TLS_PWD_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; 243 CipherSuite TLS_PWD_DH_DSS_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; 244 CipherSuite TLS_PWD_DH_DSS_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; 245 CipherSuite TLS_PWD_DH_RSA_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; 246 CipherSuite TLS_PWD_DH_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; 247 CipherSuite TLS_PWD_DHE_DSS_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; 248 CipherSuite TLS_PWD_DHE_DSS_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; 249 CipherSuite TLS_PWD_DHE_RSA_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; 250 CipherSuite TLS_PWD_DHE_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; 251 CipherSuite TLS_PWD_RSA_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; 252 CipherSuite TLS_PWD_DH_DSS_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; 253 CipherSuite TLS_PWD_DH_RSA_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; 254 CipherSuite TLS_PWD_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA={ 0xXX,0xXX }; 255 CipherSuite TLS_PWD_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA={ 0xXX,0xXX }; 256 CipherSuite TLS_PWD_RSA_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; 257 CipherSuite TLS_PWD_DH_DSS_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; 258 CipherSuite TLS_PWD_DH_RSA_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; 259 CipherSuite TLS_PWD_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA={ 0xXX,0xXX }; 260 CipherSuite TLS_PWD_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA={ 0xXX,0xXX }; 261 CipherSuite TLS_PWD_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; 262 CipherSuite TLS_PWD_DH_DSS_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; 263 CipherSuite TLS PWD_DH_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; 264 CipherSuite TLS_PWD_DHE_DSS_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; 265 CipherSuite TLS_PWD_DHE_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; 266 CipherSuite TLS_PWD_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; 267 CipherSuite TLS_PWD_DH_DSS_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; 268 CipherSuite TLS_PWD_DH_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; 269 CipherSuite TLS_PWD_DHE_DSS_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; 270 CipherSuite TLS_PWD_DHE_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; 271 CipherSuite TLS_PWD_ECDH_ECDSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; 272 CipherSuite TLS_PWD_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; 273 CipherSuite TLS_PWD_ECDH_ECDSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; 274 CipherSuite TLS_PWD_ECDH_ECDSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; 275 CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; 276 CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA={ 0xXX,0xXX }; 277 CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; 278 CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; 279 CipherSuite TLS_PWD_ECDH_RSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; 280 CipherSuite TLS_PWD_ECDH_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; 281 CipherSuite TLS_PWD_ECDH_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; 282 CipherSuite TLS_PWD_ECDH_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; 283 CipherSuite TLS_PWD_ECDHE_RSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; 284 CipherSuite TLS_PWD_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; 285 CipherSuite TLS_PWD_ECDHE_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; 286 CipherSuite TLS_PWD_ECDHE_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; 288 This document also defines a new TLS alert message, 289 unknown_login(TBD). 291 5. References 293 5.1. Normative References 295 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 296 RFC 2246, January 1999. 298 [TLS1.1] Dierks, T. and E. Rescorla, "The TLS Protocol Version 299 1.1", RFC 4346, April 2006. 301 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", RFC 2119, March 1997. 304 [PSK] Eronen, P. (Ed.) and H. Tschofenig (Ed.), "Pre-Shared Key 305 Ciphersuites for Transport Layer Security (TLS)", 306 RFC 4279, December 2005. 308 [TLSCAM] Moriai, S., Kato, A., Kanda M., "Addition of Camellia 309 Cipher Suites to Transport Layer Security (TLS)", 310 RFC 4132, July 2005. 312 [TLSAES] Chown, P., "Advanced Encryption Standard (AES) 313 Ciphersuites for Transport Layer Security (TLS)", 314 RFC 3268, June 2002. 316 [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., 317 Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher 318 Suites for Transport Layer Security (TLS)", RFC 4492, May 319 2006 321 [TLSCTR] Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher 322 Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work 323 in progress), June 2006. 325 5.2. Informative References 327 [KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 328 Suites to Transport Layer Security (TLS)", RFC 2712, 329 October 1999. 331 Author's Addresses 333 Mohamad Badra 334 LIMOS Laboratory - UMR (6158), CNRS 335 France Email: badra@isima.fr 337 Full Copyright Statement 339 Copyright (C) The IETF Trust (2007). 341 This document is subject to the rights, licenses and restrictions 342 contained in BCP 78, and except as set forth therein, the authors 343 retain all their rights. 345 This document and the information contained herein are provided on 346 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 347 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 348 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 349 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 350 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 351 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 352 FOR A PARTICULAR PURPOSE. 354 Intellectual Property 356 The IETF takes no position regarding the validity or scope of any 357 Intellectual Property Rights or other rights that might be claimed 358 to pertain to the implementation or use of the technology described 359 in this document or the extent to which any license under such 360 rights might or might not be available; nor does it represent that 361 it has made any independent effort to identify any such rights. 362 Information on the procedures with respect to rights in RFC 363 documents can be found in BCP 78 and BCP 79. 365 Copies of IPR disclosures made to the IETF Secretariat and any 366 assurances of licenses to be made available, or the result of an 367 attempt made to obtain a general license or permission for the use 368 of such proprietary rights by implementers or users of this 369 specification can be obtained from the IETF on-line IPR repository 370 at http://www.ietf.org/ipr. 372 The IETF invites any interested party to bring to its attention any 373 copyrights, patents or patent applications, or other proprietary 374 rights that may cover technology that may be required to implement 375 this standard. Please address the information to the IETF at ietf- 376 ipr@ietf.org. 378 Acknowledgment 379 Funding for the RFC Editor function is provided by the IETF 380 Administrative Support Activity (IASA).