--- /dev/null
+TLS Working Group Mohamad Badra
+Internet Draft LIMOS Laboratory
+Intended status: Standards Track February 24, 2008
+Expires: August 2008
+
+
+
+ Password Extension for the TLS Client Authentication
+ draft-badra-tls-password-ext-01.txt
+
+
+Status of this Memo
+
+ 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 August 24, 2008.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2008).
+
+Abstract
+
+ This document specifies a new Transport Layer Security (TLS)
+ extension and a new TLS message providing TLS client authentication
+ using passwords. It provides client credential protection.
+
+
+
+
+
+
+Badra Expires August 24, 2008 [Page 1]
+\f
+Internet-Draft Password Extension for TLS February 2008
+
+
+Table of Contents
+
+
+ 1. Introduction...................................................3
+ 1.1. Conventions used in this document.........................3
+ 2. Password Extension.............................................3
+ 2.1. Encrypted Password........................................3
+ 3. Conformance Requirements.......................................6
+ 3.1. Requirements for Management Interfaces....................6
+ 4. Security Considerations........................................6
+ 5. IANA Considerations............................................6
+ 6. References.....................................................7
+ 6.1. Normative References......................................7
+ 6.2. Informative References....................................7
+ Author's Addresses................................................7
+ Intellectual Property Statement...................................7
+ Disclaimer of Validity............................................8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Badra Expires August 24, 2008 [Page 2]
+\f
+Internet-Draft Password Extension for TLS February 2008
+
+
+1. Introduction
+
+ This document defines a new extension and a new TLS message to the
+ Transport Layer Security (TLS) protocol to enable TLS client
+ authentication using passwords. It provides client credential
+ protection.
+
+1.1. Conventions used in this document
+
+ 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 [RFC2119].
+
+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 August 24, 2008 [Page 3]
+\f
+Internet-Draft Password Extension for TLS February 2008
+
+
+ Structure of this message:
+
+ struct {
+ uint16 length;
+ select (CipherSpec.cipher_type) {
+ case stream:
+ stream-ciphered struct {
+ opaque fresh_random<16..2^16-1>;
+ opaque username<1..2^16-1>;
+ opaque password<1..2^16-1>;
+ };
+ case block:
+ block-ciphered struct {
+ opaque IV[CipherSpec.block_length];
+ opaque username<1..2^16-1>;
+ opaque password<1..2^16-1>;
+ uint8 adding[EncryptedPassword.padding_length];
+ uint8 padding_length;
+ };
+ } EncryptedPassword;
+
+ fresh_random
+
+ A vector contains at least 16 bytes random value. It is RECOMMENDED
+ that implementations provide functionality for generating this
+ random, taking [RFC4086] into account.
+
+ 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.
+
+
+
+
+
+
+Badra Expires August 24, 2008 [Page 4]
+\f
+Internet-Draft Password Extension for TLS February 2008
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ Next, the server will then check the authentication database to see
+ if the received username/password and those stored in the database
+ 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.
+
+ This documents doesn't specify how exactly the server checks the
+ username/password for a match. However, the server MAY consider
+ using of an AAA or RADIUS infrastructures. In this case, the server
+ calls into the local AAA client, which in turn contacts the AAA
+ server. The client's credentials (username and password) are
+ validated at the AAA server, which in turn responds to the AAA client
+ with an accept/reject message.
+
+ Client Server
+ ------ ------
+ ExtendedClientHello -------->
+ ExtendedServerHello
+ Certificate
+ ServerKeyExchange*
+ <-------- ServerHelloDone
+ ClientKeyExchange
+ EncryptedPassword
+ ChangeCipherSpec
+ Finished -------->
+ ChangeCipherSpec
+ <-------- Finished
+
+
+
+
+Badra Expires August 24, 2008 [Page 5]
+\f
+Internet-Draft Password Extension for TLS February 2008
+
+
+3. Conformance Requirements
+
+ This document does not specify how the server stores the password and
+ the username, or how exactly it verifies the password and the
+ username it receives. It is RECOMMENDED that before looking up the
+ password, the server processes the username with a SASLprep profile
+ [RFC4013] appropriate for the username in question.
+
+3.1. Requirements for Management Interfaces
+
+ In the absence of an application profile specification specifying
+ otherwise, a management interface for entering the password and/or
+ the username MUST support the following:
+
+ o Entering usernames consisting of up to 128 printable Unicode
+ characters.
+
+ o Entering passwords up to 64 octets in length as ASCII strings
+ and in hexadecimal encoding. The management interface MAY
+ accept other encodings if the algorithm for translating the
+ encoding to a binary string is specified.
+
+4. Security Considerations
+
+ The security considerations described throughout [RFC4346] and
+ [RFC4366] apply here as well.
+
+5. IANA Considerations
+
+ This document defines a new TLS extension "password", assigned the
+ value to be allocated from the TLS ExtensionType registry defined in
+ [RFC4366].
+
+ This document defines a new handshake message, encrypted password,
+ whose value is to be allocated from the TLS HandshakeType registry
+ defined in [RFC4346].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Badra Expires August 24, 2008 [Page 6]
+\f
+Internet-Draft Password Extension for TLS February 2008
+
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+ "Randomness Requirements for Security", BCP 106, RFC 4086,
+ June 2005.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol 1.1", RFC 4346, April 2006.
+
+ [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
+ and T. Wright, "Transport Layer Security (TLS) Extensions",
+ RFC 4366, April 2006.
+
+6.2. Informative References
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
+ and Passwords", RFC 4013, February 2005.
+
+
+
+Author's Addresses
+
+ Mohamad Badra
+ LIMOS Laboratory - UMR6158, CNRS
+ France
+
+ Email: badra@isima.fr
+
+
+Intellectual Property Statement
+
+ 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
+
+
+Badra Expires August 24, 2008 [Page 7]
+\f
+Internet-Draft Password Extension for TLS February 2008
+
+
+ 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.
+
+Disclaimer of Validity
+
+ 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.
+
+Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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.
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Badra Expires August 24, 2008 [Page 8]
+\f
projects / thirdparty / gnutls.git / commitdiff
