diff options
Diffstat (limited to 'doc/protocol/draft-badra-tls-password-ext-01.txt')
-rw-r--r-- | doc/protocol/draft-badra-tls-password-ext-01.txt | 431 |
1 files changed, 431 insertions, 0 deletions
diff --git a/doc/protocol/draft-badra-tls-password-ext-01.txt b/doc/protocol/draft-badra-tls-password-ext-01.txt new file mode 100644 index 0000000000..eb7c0e78b8 --- /dev/null +++ b/doc/protocol/draft-badra-tls-password-ext-01.txt @@ -0,0 +1,431 @@ +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + |