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]
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]