From: Simon Josefsson Date: Sat, 21 Apr 2007 08:06:36 +0000 (+0000) Subject: Add. X-Git-Tag: gnutls_1_7_9~23 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=bb2be4eb07bdf07b5bf811a801f8d059bc57d475;p=thirdparty%2Fgnutls.git Add. --- diff --git a/doc/protocol/draft-badra-tls-password-00.txt b/doc/protocol/draft-badra-tls-password-00.txt new file mode 100644 index 0000000000..3900bf6335 --- /dev/null +++ b/doc/protocol/draft-badra-tls-password-00.txt @@ -0,0 +1,505 @@ + + + +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] + \ No newline at end of file diff --git a/doc/protocol/draft-badra-tls-password-ext-00.txt b/doc/protocol/draft-badra-tls-password-ext-00.txt new file mode 100644 index 0000000000..a33aee974a --- /dev/null +++ b/doc/protocol/draft-badra-tls-password-ext-00.txt @@ -0,0 +1,393 @@ + + + +Internet Engineering Task Force M. Badra +INTERNET DRAFT LIMOS Laboratory +April 19, 2007 Expires: October 2007 + + + Password Extension for TLS Client Authentication + + + +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 new TLS extension and a new TLS message + providing TLS client authentication using passwords. It provides + client credential protection. + + + + + + + + + +Badra Expires October 2007 [Page 1] + +Internet-draft Password Ciphersuites for TLS April 2007 + + +1 Introduction + + This document defines a new extension and a new TLS message to the + TLS protocol to enable TLS client authentication using passwords. It + provides client credential protection. + +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 Extension + + In order to negotiate the use of client password-based + authentication, clients MAY include an extension of type "password" + in the extended client hello. The "extension_data" field of this + extension SHALL be empty. The extension_type field is to be assigned + by IANA. + + For servers aware of the password extension but not wishing to use + it, it will gracefully revert to an ordinary TLS handshake or stop + the negotiation. + + Servers that receive an extended hello containing a "password" + extension MAY agree to authenticate the client using passwords by + including an extension of type "password", with empty + "extension_data", in the extended server hello. The + CertificateRequest payload is omitted from the server response. + + Clients return a response along with their credentials by sending a + "EncryptedPassword" message immediately after the + "ClientKeyExchange" message. The encrypted password message is sent + symmetrically encrypted with the key client_write_key and the cipher + algorithm selected by the server in the ServerHello.cipher_suite. + The Certificate and CertificateVerify payloads are omitted from the + client response. + +2.1. Encrypted Password + + When this message will be sent: + + The client MUST send this message immediately after the client key + exchange message. + + + + + + + +Badra Expires October 2007 [Page 2] + +Internet-draft Password Ciphersuites for TLS April 2007 + + + + Structure of this message: + + 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[EncryptedPassword.padding_length]; + uint8 padding_length; + }; + } EncryptedPassword; + + fresh_random + A vector contains at least 16 bytes. + + length + The length (in bytes) of the EncryptedPassword structure. + + padding + Padding that is added to force the length of the EncryptedPassword + 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 EncryptedPassword.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 + EncryptedPassword 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. + + + + + +Badra Expires October 2007 [Page 3] + +Internet-draft Password Ciphersuites for TLS April 2007 + + + BulkCipherAlgorithm.null (e.g. TLS_RSA_WITH_NULL_MD5 and + RSA_WITH_NULL_SHA) MUST NOT be negotiated when password extension is + deployed, as it provides no more protection than an unsecured + connection. + + 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? + + Upon receipt of this message, the server symmetrically decrypts the + EncryptedPassword using the same key as the client to retrieve the + username and the password in clear text. The server then checks its + database for a match. If a match is found, the server 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 + EncryptedPassword + ChangeCipherSpec + Finished --------> + ChangeCipherSpec + <-------- Finished + Application Data Application Data + Attribute Value Pairs Attribute Value Pairs + Type Length Value <=======> Type Length Value + +3. Security Considerations + + + + +Badra Expires October 2007 [Page 4] + +Internet-draft Password Ciphersuites for TLS April 2007 + + + The security considerations described throughout [TLS], [DTLS], and + [TLS1.1] apply here as well. + +4. IANA Considerations + + This document defines a new TLS extension "password", assigned the + value TBD from the TLS ExtensionType registry defined in [TLSEXT]. + + This document also defines a new TLS alert message, + unknown_login(TBD). + + This document defines a new handshake message, encrypted password, + whose value is to be allocated from the TLS HandshakeType registry + defined in [TLS]. + +5. References + +5.1. Normative References + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [TLSExt] Blake-Wilson, S., et. al., "Transport Layer Security TLS) + Extensions", 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. + + + +Badra Expires October 2007 [Page 5] + +Internet-draft Password Ciphersuites for TLS April 2007 + + + +5.2. Informative References + + [KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher + Suites to Transport Layer Security (TLS)", RFC 2712, + October 1999. + +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. + + + + +Badra Expires October 2007 [Page 6] + +Internet-draft Password Ciphersuites for TLS April 2007 + + + 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 + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Badra Expires October 2007 [Page 7] + \ No newline at end of file