path: root/doc/protocol/draft-badra-tls-password-ext-01.txt

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]