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