Internet Engineering Task Force M. Badra INTERNET DRAFT LIMOS Laboratory April 19, 2007 Expires: October 2007 Password Ciphersuites for Transport Layer Security (TLS) Status 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 October 19, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies a set of new ciphersuites for the Transport Layer Security (TLS) protocol to support TLS client authentication based on passwords. These ciphersuites provide client credential protection. Badra Expires October 2007 [Page 1] Internet-draft Password Ciphersuites for TLS April 2007 1 Introduction TLS defines several ciphersuites providing authentication, data protection and session key exchange between two communicating entities. TLS uses public key certificates [TLS], Kerberos [KERB] or preshared key [PSK] for authentication. This document describes how to use passwords, shared in advance among the communicating parties, to authenticate the TLS clients. 1.2 Requirements language and Terminologies 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 [KEYWORDS]. 2. Password Key Exchange Algorithm This document specifies a set of ciphersuites for TLS to make use of existing password databases (e.g. AAA databases) to support client password-based authentication. These ciphersuites reuse existing key exchange algorithms as well as existing MAC, stream and bloc ciphers algorithms from [TLS] and [TLSCTR], [TLSECC], [TLSAES] and [TLSCAM]. Their names include the text "PWD" to refer to the client authentication using passwords. An example is shown below. CipherSuite Key Exchange Cipher Hash TLS_PWD_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA Currently, a set of password authentication modes are available, such as One-time password, pin mode, Token. Some of these modes require multiple exchanges (round-trips) between the client and the server. This document treats currently password authentication modes which don't require more than one round-trip. 2.1. Extending the client key exchange message TLS defines the client key exchange message, which is used to convey the premaster secret. This secret is usually set; either through a direct transmission of the RSA-encrypted secret, or by the transmission of Diffie-Hellman parameters which will allow each side to agree upon the same premaster secret. The structure of this message depends on which key exchange method has been selected. The actual TLS specifications define several methods using usually RSA, Diffie_Hellman or PSK algorithms. This document extends the client key exchange message with three new key exchange methods as following. It is described as following: Badra Expires October 2007 [Page 2] Internet-draft Password Ciphersuites for TLS April 2007 struct { select (KeyExchangeAlgorithm) { /* cases rsa, DH [TLS], ec_diffie_hellman [TLSECC]) */ case pwd_rsa: /* NEW */ EncryptedPreMasterSecret; EncryptedPWD; case pwd_dh: /* NEW */ ClientDiffieHellmanPublic; EncryptedPWD; case pwd_ec_diffie_hellman: /* NEW */ ClientECDiffieHellmanPublic; EncryptedPWD; } exchange_keys; } ClientKeyExchange; 2.1.1. Cases pwd_rsa, pwd_dh and pwd_ec_diffie_hellman If pwd_rsa is being used for key agreement, the client generates a 48-byte random value (premaster secret), encrypts it using the server public key sent in the server key exchange message or in the server certificate. This is the same as in the RSA key exchange method. In the case of stream cipher encryption, the client generates a fresh random value and concatenates it to its username and password. Therefore, the client symmetrically encrypts the result using the client_write_key. The cipher algorithm is the same selected by the server in the ServerHello.cipher_suite. The result of the above operations called the EncryptedPWD, structured as follow. In the case of block cipher encryption, the client uses an explicit IV and adds padding value to force the length of the plaintext to be an integral multiple of the block cipher's block length, as it is described in section 6.2.3.2 of [TLS1.1]. struct { uint16 length; select (CipherSpec.cipher_type) { case stream: stream-ciphered struct { opaque fresh_random<16..2^16-1>; opaque login<1..2^16-1>; opaque password<1..2^16-1>; }; case block: block-ciphered struct { opaque IV[CipherSpec.block_length]; opaque login<1..2^16-1>; opaque password<1..2^16-1>; uint8 padding[EncryptedPWD.padding_length]; Badra Expires October 2007 [Page 3] Internet-draft Password Ciphersuites for TLS April 2007 uint8 padding_length; }; } EncryptedPWD; fresh_random A vector contains at least 16 bytes. length The length (in bytes) of the EncryptedPWD structure. padding Padding that is added to force the length of the EncryptedPWD structure to be an integral multiple of the block cipher's block length. The padding MAY be any length up to 255 bytes, as long as it results in the EncryptedPWD.length being an integral multiple of the block length. Lengths longer than necessary might be desirable to frustrate attacks on a protocol that are based on analysis of the lengths of exchanged messages. Each uint8 in the padding data vector MUST be filled with the padding length value. The receiver MUST check this padding and SHOULD use the bad_record_mac alert to indicate padding errors. padding_length The padding length MUST be such that the total size of the EncryptedPWD structure is a multiple of the cipher's block length. Legal values range from zero to 255, inclusive. This length specifies the length of the padding field exclusive of the padding_length field itself. Implementations of this document MUST ensure that all policies being applied on the PSK encoding (section 5 of [PSK]) are applied on the password encoding as well. Editor note: is it more secure to don't send the password on the wire and instead of that, mix it with the premaster secret, and use the result as an input for the key derivation function to implicitly authenticate the client? The client concatenates the EncryptedPreMasterSecret and the EncryptedPWD values before sending the result to the server through the client key exchange message. Upon receipt of this message, the server decrypts the EncryptedPreMasterSecret using its private key and therefore computes the master_secret and derives the same client_write_key. Next, the server symmetrically decrypts the EncryptedPWD to retrieve the client username and the password in clear text. The server then checks its database for a match. If a match is found, the server Badra Expires October 2007 [Page 4] Internet-draft Password Ciphersuites for TLS April 2007 sends its change cipher spec message and proceeds directly to finished message. If no match is found, the server MUST send a fatal alert, results in the immediate termination of the connection. If the server does not recognize the login, it MAY respond with an "unknown_login" alert message. Alternatively, if the server wishes to hide the fact that the login was not known, it MAY continue the protocol as if the login existed but the key was incorrect: that is, respond with a "decrypt_error" alert. Client Server ------ ------ ClientHello --------> ServerHello Certificate* ServerKeyExchange* <-------- ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished --------> ChangeCipherSpec <-------- Finished Application Data Application Data Attribute Value Pairs Attribute Value Pairs Type Length Value <=======> Type Length Value The pwd_dh case is similar to pwd_rsa, except that the EncryptedPreMasterSecret is replaced with the parameter ClientDiffieHellmanPublic. The pwd_ec_diffie_hellman case is similar to pwd_rsa, except that the EncryptedPreMasterSecret is replaced with the parameter ClientECDiffieHellmanPublic. 3. Security Considerations The security considerations described throughout [TLS], [DTLS], and [TLS1.1] apply here as well. 4. IANA Considerations This section provides guidance to the IANA regarding registration of values related to the client based-password authentication. Note: For implementation and deployment facilities, it is helpful to reserve a specific registry sub-range (minor, major) for identity protection ciphersuites. Badra Expires October 2007 [Page 5] Internet-draft Password Ciphersuites for TLS April 2007 CipherSuite TLS_PWD_ITH_RC4_128_MD5 ={ 0xXX,0xXX }; CipherSuite TLS PWD_RSA WITH_RC4_128_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_RSA_WITH_IDEA_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_RSA_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_DSS_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_DSS_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_RSA_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_DSS_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_DSS_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_RSA_WITH_DES_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_RSA_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_DSS_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_RSA_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA={ 0xXX,0xXX }; CipherSuite TLS_PWD_RSA_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_DSS_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_RSA_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA={ 0xXX,0xXX }; CipherSuite TLS_PWD_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_DSS_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS PWD_DH_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_DSS_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_DSS_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DH_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_DSS_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_DHE_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDH_ECDSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDH_ECDSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDH_ECDSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDH_RSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDH_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDH_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDH_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDHE_RSA_WITH_RC4_128_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; Badra Expires October 2007 [Page 6] Internet-draft Password Ciphersuites for TLS April 2007 CipherSuite TLS_PWD_ECDHE_RSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; CipherSuite TLS_PWD_ECDHE_RSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; This document also defines a new TLS alert message, unknown_login(TBD). 5. References 5.1. Normative References [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [TLS1.1] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, April 2006. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [PSK] Eronen, P. (Ed.) and H. Tschofenig (Ed.), "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. [TLSCAM] Moriai, S., Kato, A., Kanda M., "Addition of Camellia Cipher Suites to Transport Layer Security (TLS)", RFC 4132, July 2005. [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006 [TLSCTR] Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work in progress), June 2006. 5.2. Informative References [KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. Badra Expires October 2007 [Page 7] Internet-draft Password Ciphersuites for TLS April 2007 Author's Addresses Mohamad Badra LIMOS Laboratory - UMR (6158), CNRS France Email: badra@isima.fr 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 Badra Expires October 2007 [Page 8] Internet-draft Password Ciphersuites for TLS April 2007 Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Badra Expires October 2007 [Page 9]