--- /dev/null
+
+
+
+Internet Engineering Task Force M. Badra
+INTERNET DRAFT LIMOS Laboratory
+April 19, 2007 Expires: October 2007
+
+
+ Password Ciphersuites for Transport Layer Security (TLS)
+ <draft-badra-tls-password-00.txt>
+
+
+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]
+ \f
+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]
+ \f
+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]
+ \f
+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]
+ \f
+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]
+ \f
+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]
+ \f
+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]
+ \f
+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]
+ \f
+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]
+ \f
\ No newline at end of file
--- /dev/null
+
+
+
+Internet Engineering Task Force M. Badra
+INTERNET DRAFT LIMOS Laboratory
+April 19, 2007 Expires: October 2007
+
+
+ Password Extension for TLS Client Authentication
+ <draft-badra-tls-password-ext-00.txt>
+
+
+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]
+ \f
+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]
+ \f
+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]
+ \f
+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]
+ \f
+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]
+ \f
+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]
+ \f
+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]
+ \f
\ No newline at end of file
projects / thirdparty / gnutls.git / commitdiff
