
 

Internet Engineering Task Force                               I. Hajjeh 
                                                              ESRGroups 
                                                               M. Badra 
                                                       ISIMA Laboratory 
    
Expires: April 2007                                      November, 2006 
    
       Identity Protection Ciphersuites for Transport Layer Security 
                <draft-hajjeh-tls-identity-protection-00.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 April 2007. 
    
   Copyright Notice 
    
   Copyright (C) The Internet Society (2006). All Rights Reserved. 
    
Abstract 
    
   TLS defines several ciphersuites providing authentication, data 
   protection and session key exchange between two communicating 
   entities. Some of these ciphersuites are used for completely 
   anonymous key exchange, in which neither party is authenticated. 
   However, they are vulnerable to man-in-the-middle attacks and are 
   therefore deprecated. 
    
   This document defines a set of ciphersuites to add client identity 
   protection to the Transport Layer Security (TLS) protection. 

 
Hajjeh & Badra             Expires April 2007                  [Page 1] 
 
Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
 
1. Introduction 
    
   TLS is the most deployed security protocol for securing exchanges. 
   It provides end-to-end secure communications between two entities 
   with authentication and data protection. 
    
   TLS supports three authentication modes: authentication of both 
   parties, only server-side authentication, and anonymous key 
   exchange. For each mode, TLS specifies a set of ciphersuites. 
   However, anonymous ciphersuites are strongly discouraged because 
   they cannot prevent man-in-the-middle attacks. 
    
   Client identity protection may be established by changing the order 
   of the messages that the client sends after receiving 
   ServerHelloDone [CORELLA]. This is done by sending the 
   ChangeCipherSpec message before the Certificate and the 
   CertificateVerify messages and after the ClientKeyExchange message. 
   However, it requires a major change to TLS machine state as long as 
   a new TLS version. 
    
   Client identity protection may also be done through a EDH exchange 
   before establishing an ordinary handshake with identity information 
   [RESCORLA]. This wouldn't however be secure enough against active 
   attackers and wouldn't be favorable for some environments (e.g. 
   mobile), due to the additional cryptographic computations. 
    
   Client identity protection may be also possible, assuming that the 
   client permits renegotiation after the first server authentication. 
   However, this requires more cryptographic computations and augments 
   significantly the number of rounds trips. 
    
   Finally, client identity protection may be realized by exchanging a 
   TLS extension that negotiates the symmetric encryption algorithm to 
   be used for client certificate encrypting/decrypting [EAPTLSIP]. 
   This solution may suffer from interoperability issues related to TLS 
   Extensions, TLS 1.0 and TLS 1.1 implementations, as described in 
   [INTEROP]. 
    
   This document defines a set of ciphersuites to add client identity 
   protection to TLS protocol. Client identity protection is provided 
   by symmetrically encrypting the client certificate with a key 
   derived from the SecurityParameters.master_secret, 
   SecurityParameters.server_random and 
   SecurityParameters.client_random. The symmetric encryption algorithm 
   is set to the cipher algorithm of the ServerHello.cipher_suite. 
    
1.2. Requirements language 
    
   The key words "MUST", "MUST NOT" and "MAY" in this document are to 
   be interpreted as described in RFC-2119. 

 
Hajjeh & Badra             Expires April 2007                  [Page 2] 
 
Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
 
2. TLS Identity Protection overview 
    
   This document specifies a set of ciphersuites for TLS. These 
   ciphersuites reuse existing key exchange algorithms that require 
   based-certificates authentication, and reuse also existing MAC, 
   stream and bloc ciphers algorithms from [TLS] and [TLSCTR], 
   [TLSECC], [TLSAES] and [TLSCAM]. Their names include the text "IP" 
   to refer to the client identity protection. An example is shown 
   below. 
    
   CipherSuite                          Key Exchange  Cipher       Hash 
    
   TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5    RSA           RC4 40       MD5 
   TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA  DHE           AES 128_CBC  SHA 
    
   If the client has not a certificate with a type appropriate for one 
   of the supported cipher key exchange algorithms or if the client 
   will not be able to send such a certificate, it MUST NOT include any 
   ciphersuite with client identity protection in the 
   ClientHello.cipher_suites. 
    
   If the server selects a ciphersuite with client identity protection, 
   the server MUST request a certificate from the client. 
    
   If the server selects one of the ciphersuites defined in this 
   document, the client MUST encrypt its certificate using the 
   symmetric algorithm selected by the server from the list in 
   ClientHello.cipher_suites and a key derived from the 
   SecurityParameters.master_secret (see section 3 for the key 
   computation). 
    
   In the case of DH_DSS and DH_RSA ciphersuites with client 
   authentication, the ClientKeyExchange message always contains 
   explicit Diffie-Hellman public value and it is possible to correlate 
   sessions by the same client. Consequently, DH_DSS and DH_RSA are not 
   currently omitted from this document. 
    
   For EDH, the client MUST explicitly send its EDH public value in the 
   ClientKeyExchange message. 












 
Hajjeh & Badra             Expires April 2007                  [Page 3] 
 
Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
 
         Client                                        Server 
    
         ClientHello          --------> 
                                                  ServerHello 
                                                  Certificate 
                                            ServerKeyExchange* 
                                           CertificateRequest 
                              <--------       ServerHelloDone 
         ClientKeyExchange 
        {Certificate} 
         CertificateVerify 
        [ChangeCipherSpec] 
         Finished             --------> 
                                            [ChangeCipherSpec] 
                              <--------              Finished 
         Application Data     <------->      Application Data 
    
   * Indicates optional or situation-dependent messages that are not 
   always sent. 
   {} Indicates messages that are symmetrically encrypted. 
    
   The ciphersuites in Section 4 (IP_RSA Key Exchange Algorithm) use 
   RSA based certificates to mutually authenticate a RSA exchange with 
   the client identity protection. 
   The ciphersuites in Section 5 (IP_EDH Key Exchange Algorithm) use 
   EDH_RSA or EDH_DSS to mutually authenticate a Diffie-Hellman 
   exchange with the client identity protection. 
    
   The ciphersuites in Section 6 (IP_ECC Key Exchange Algorithm) are 
   TBC. 
    
3. Key computation to encrypt/decrypt client's certificate 
    
   Before sending its certificate, the client is able to compute the 
   master secret and then the key_block. Thus, the client and the 
   server derive from the key_block a key called 
   identity_protection_key. This key is deployed by the client 
   (respectively the server) to encrypt (respectively decrypt) the 
   client's certificate. 
    
   The identity_protection_key is set to the low order bits of the 
   key_block, and its length is set appropriately to 
   ServerHello.cipher_suite. For example, if the client and the server 
   have agreed on using a ciphersuite with RC4_128 as symmetric 
   cryptography, they therefore set their key to the low order 128-bits 
   of the key_block. 
    
   Exportable encryption algorithms (for which CipherSpec.is_exportable 
   is true) require additional processing as follows to derive their 
   final identity_protection_key: 

 
Hajjeh & Badra             Expires April 2007                  [Page 4] 
 
Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
 
    
          final_identity_protection_key = 
          PRF(SecurityParameters.identity_protection_key, 
                                     "identity_protection_key", 
                                     SecurityParameters.client_random + 
                                     SecurityParameters.server_random); 
    
4. IP_RSA Key Exchange Algorithm 
    
   This section defines additional ciphersuites that use RSA based 
   certificates to authenticate a RSA exchange. These ciphersuites give 
   client identity protection. 
    
   CipherSuite                      Key Exchange  Cipher           Hash 
    
   TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5     RSA      RC4_40            MD5 
   TLS_IP_RSA_WITH_RC4_128_MD5           RSA      RC4_128           MD5 
   TLS_IP_RSA_WITH_RC4_128_SHA           RSA      RC4_128           SHA 
   TLS_IP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RSA      RC2_CBC_40        MD5 
   TLS_IP_RSA_WITH_IDEA_CBC_SHA          RSA      IDEA_CBC          SHA 
   TLS_IP_RSA_EXPORT_WITH_DES40_CBC_SHA  RSA      DES40_CBC_        SHA 
   TLS_IP_RSA_WITH_DES_CBC_SHA           RSA      DES_CBC           SHA 
   TLS_IP_RSA_WITH_3DES_EDE_CBC_SHA      RSA      3DES_EDE          SHA 
   TLS_IP_RSA_WITH_AES_128_CBC_SHA       RSA      AES_128_CBC       SHA 
   TLS_IP_RSA_WITH_AES_256_CBC_SHA       RSA      AES_256_CBC       SHA 
   TLS_IP_RSA_WITH_AES_128_CTR_SHA       RSA      AES_128_CTR       SHA 
   TLS_IP_RSA_WITH_CAMELLIA_128_CBC_SHA  RSA      CAMELLIA_128_CBC  SHA 
   TLS_IP_RSA_WITH_AES_256_CTR_SHA       RSA      AES_256_CTR       SHA 
   TLS_IP_RSA_WITH_CAMELLIA_256_CBC_SHA  RSA      CAMELLIA_256_CBC  SHA 
    
5. IP_EDH Key Exchange Algorithm 
    
   This section defines additional ciphersuites that use EDH with RSA 
   or DSS based certificates to authenticate a Diffie-Hellman exchange. 
   These ciphersuites give client identity protection. 
    
   The client MUST explicitly send its EDH public value in the 
   ClientKeyExchange message. 
    
   Note that this document does not specify any CipherSpec that uses DH 
   RSA or DSS based certificates. 
    
   CipherSuite                      Key Exchange  Cipher           Hash 
    
   TLS_IP_DHE_DSS_WITH_DES_CBC_SHA          DHE   DES_CBC           SHA 
   TLS_IP_DHE_DSS_WITH_3DES_EDE_CBC_SHA     DHE   3DES_EDE_CBC      SHA 
   TLS_IP_DHE_RSA_WITH_DES_CBC_SHA          DHE   DES_CBC           SHA 
   TLS_IP_DHE_RSA_WITH_3DES_EDE_CBC_SHA     DHE   3DES_EDE_CBC      SHA 
   TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA      DHE   AES_128_CBC       SHA 
   TLS_IP_DHE_RSA_WITH_AES_128_CBC_SHA      DHE   AES_128_CBC       SHA 

 
Hajjeh & Badra             Expires April 2007                  [Page 5] 
 
Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
 
   TLS_IP_DHE_DSS_WITH_AES_256_CBC_SHA      DHE   AES_256_CBC       SHA 
   TLS_IP_DHE_RSA_WITH_AES_256_CBC_SHA      DHE   AES_256_CBC       SHA 
   TLS_IP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE   CAMELLIA_128_CBC  SHA 
   TLS_IP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE   CAMELLIA_128_CBC  SHA 
   TLS_IP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE   CAMELLIA_256_CBC  SHA 
   TLS_IP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE   CAMELLIA_256_CBC  SHA 
   TLS_IP_DHE_DSS_WITH_AES_128_CTR_SHA      DHE   AES_128_CTR       SHA 
   TLS_IP_DHE_RSA_WITH_AES_128_CTR_SHA      DHE   AES_128_CTR       SHA 
   TLS_IP_DHE_DSS_WITH_AES_256_CTR_SHA      DHE   AES_256_CTR       SHA 
   TLS_IP_DHE_RSA_WITH_AES_256_CTR_SHA      DHE   AES_256_CTR       SHA 
    
6. IP_ECC Key Exchange Algorithm 
    
   TBC. 
 
7. Security Considerations 
    
   The security considerations described throughout [TLS], [DTLS], 
   [TLS1.1], [TLSAES] and [TLSAES] apply here as well. 
    
8. IANA Considerations 
    
   This section provides guidance to the IANA regarding registration of 
   values related to the identity protection ciphersuites. 
    
   CipherSuite TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5       = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_RC4_128_MD5             = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_RC4_128_SHA             = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_EXPORT_WITH_RC2_CBC_40_MD5   = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_IDEA_CBC_SHA            = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_EXPORT_WITH_DES40_CBC_SHA    = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_DES_CBC_SHA             = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_3DES_EDE_CBC_SHA        = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_AES_128_CBC_SHA         = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_AES_256_CBC_SHA         = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_AES_128_CTR_SHA         = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_CAMELLIA_128_CBC_SHA    = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_AES_256_CTR_SHA         = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_RSA_WITH_CAMELLIA_256_CBC_SHA    = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_DSS_WITH_DES_CBC_SHA         = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_DSS_WITH_3DES_EDE_CBC_SHA    = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_RSA_WITH_DES_CBC_SHA         = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA     = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_RSA_WITH_AES_128_CBC_SHA     = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_DSS_WITH_AES_256_CBC_SHA     = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_RSA_WITH_AES_256_CBC_SHA     = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX }; 

 
Hajjeh & Badra             Expires April 2007                  [Page 6] 
 
Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
 
   CipherSuite TLS_IP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_DSS_WITH_AES_128_CTR_SHA     = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_RSA_WITH_AES_128_CTR_SHA     = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_DSS_WITH_AES_256_CTR_SHA     = { 0xXX,0xXX }; 
   CipherSuite TLS_IP_DHE_RSA_WITH_AES_256_CTR_SHA     = { 0xXX,0xXX }; 
    
   Note: For implementation and deployment facilities, it is helpful to 
   reserve a specific registry sub-range (minor, major) for identity 
   protection ciphersuites. 
    
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 2005. 
    
   [DTLS]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer  
              Security", RFC 4347, April 2006. 
    
   [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. 
    
   [EAPTLSIP] Urien, P. and M. Badra, "Identity Protection within EAP- 
              TLS",  
              draft-urien-badra-eap-tls-identity-protection-01.txt  
              (work in progress), October 2006. 
    
   [INTEROP]  Pettersen, Y., "Clientside interoperability  
              experiences for the SSL and TLS protocols", draft-ietf- 
              tls-interoperability-00 (work in progress), October 2006. 
    
   [CORELLA]  Corella, F., "adding client identity protection to TLS",  
              message on ietf-tls@lists.certicom.com mailing list,  
              http://www.imc.org/ietf-tls/mail-archive/msg02004.html,  

 
Hajjeh & Badra             Expires April 2007                  [Page 7] 
 
Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
 
              August 2000. 
    
   [RESCORLA] Rescorla, E., "SSL and TLS: Designing and Building Secure  
              Systems", Addison-Wesley, March 2001. 
    
Author's Addresses 
    
   Ibrahim Hajjeh 
   ESRGroups, Security WG 
   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
    
   Mohamad Badra 
   LIMOS Laboratory - UMR (6158), 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 IETF's procedures with respect to rights in IETF 
   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. 
    
   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 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 

 
Hajjeh & Badra             Expires April 2007                  [Page 8] 
 
Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
 
    
   Copyright (C) The Internet Society (2006). 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. 










































 
Hajjeh & Badra             Expires April 2007                  [Page 9] 