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

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]