path: root/doc/protocol/draft-hajjeh-tls-identity-protection-02.txt

Working Group Name                                          I. Hajjeh 
Internet Draft                                             INEOVATION 
                                                             M. Badra 
                                                     LIMOS Laboratory 
Intended status: Experimental                       December 13, 2007 
Expires: June 2008 
                                   
 
                                      
      Credential Protection Ciphersuites for Transport Layer Security 
                draft-hajjeh-tls-identity-protection-02.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 June 13, 2007. 

Copyright Notice 

   Copyright (C) The IETF Trust (2007). 

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. 
 
 
 
Hajjeh & Badra            Expires June 2008                   [Page 1] 

Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
    

   However, they are vulnerable to man-in-the-middle attacks and are 
   therefore deprecated.  

   This document defines a set of ciphersuites to add client credential 
   protection to the Transport Layer Security (TLS) protocol.  

Table of Contents 

    
   1. Introduction................................................2 
   2. TLS credential protection overview..........................3 
   3. CP_RSA Key Exchange Algorithm...............................5 
   4. CP_DHE and CP_DH Key Exchange Algorithms....................6 
   5. CP_ECDH and CP_ECDHE Key Exchange Algorithm.................6 
   6. Security Considerations.....................................7 
   7. IANA Considerations.........................................7 
   8. References..................................................9 
      8.1. Normative References...................................9 
      8.2. Informative References.................................9 
   Author's Addresses............................................10 
   Intellectual Property Statement...............................10 
   Disclaimer of Validity........................................10 
    
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 credential 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 credential protection may also be done through a DHE exchange 
   before establishing an ordinary handshake with identity information 
   [SSLTLS]. This wouldn't however be secure enough against active 
   attackers, which will be able to disclose the client's credentials 

 
 
Hajjeh & Badra            Expires June 2008                   [Page 2] 

Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
    

   and wouldn't be favorable for some environments (e.g. mobile), due to 
   the additional cryptographic computations.  

   Client credential protection may also be possible, assuming that the 
   client permits renegotiation after the first server authentication 
   [TLS]. However, this requires more cryptographic computations and 
   augments significantly the number of rounds trips. In fact, 
   renegotiation refers back to an asymmetric encryption/decryption and 
   to a full previously certificate chain verified public key, whose 
   chain was verified properly during the first handshake and stored in 
   the client session context. In addition, computation overhead 
   increases due to all second handshake messages encryption/decryption. 
   Where for round trips, their number increases dramatically when small 
   data packets are used to convey TLS messages. Furthermore, it is 
   mandatory for the server to complete a first TLS handshake before it 
   becomes able to confirm if the client has a certificate or not.  

   Client credential protection may as well be realized by exchanging a 
   TLS extension that negotiates the symmetric encryption algorithm to 
   be used for client certificate encrypting/decrypting [EAPIP]. 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 credential 
   protection to TLS protocol. Client credential 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.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 RFC-2119 [RFC2119]. 

2. TLS credential 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, and 
   bloc ciphers algorithms from [TLS] and [TLSCTR], [TLSECC], [TLSAES] 
   and [TLSCAM]. Their names include the text "CP" to refer to the 
   client credential protection. An example is shown below.  

 
 
Hajjeh & Badra            Expires June 2008                   [Page 3] 

Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
    

   CipherSuite                         Key Exchange   Cipher        Hash 
   TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5   RSA            RC4_40        MD5 
   TLS_CP_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, the client MUST NOT include 
   any credential protection ciphersuite in the 
   ClientHello.cipher_suites.  

   If the server selects a ciphersuite with client credential 
   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 the Certificate and the 
   CertificateVerify messages using the symmetric algorithm selected by 
   the server from the list in ClientHello.cipher_suites and a key 
   derived from the SecurityParameters.master_secret. This key is the 
   same key used to encrypt data written by the client. 

   If a stream cipher encryption algorithm has been selected, the client 
   symmetrically encrypts Certificate and CertificateVerify messages 
   without any padding byte. 

   If a block cipher encryption algorithm has been selected, 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 [TLS]. 

   For DHE key exchange algorithm, the client always sends the 
   ClientKeyExchange message conveying its ephemeral DH public key Yc. 

   For ECDHE key exchange algorithm, the client always sends the 
   ClientKeyExchange message conveying its ephemeral ECDH public key Yc.  

   Current TLS specifications note that if the client certificate 
   already contains a suitable DH or ECDH public key, then Yc is  
   implicit and does not need to be sent again and consequently, the  
   client key exchange message will be sent, but it MUST be empty. 
   Implementations of this document MUST send ClientKeyExchange message 
   but always carrying the client Yc, whatever the PublicValueEncoding 
   is implicit or explicit. Note that it is possible to correlate 
   sessions by the same client when DH or ECDH are in use.  

    

    
 
 
Hajjeh & Badra            Expires June 2008                   [Page 4] 

Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
    

         Client                           Server 

         ClientHello       --------> 
                                          ServerHello 
                                          Certificate 
                                          ServerKeyExchange* 
                           <--------      CertificateRequest 
         {Certificate} 
         ClientKeyExchange 
         {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 3 (CP_RSA Key Exchange Algorithm) use RSA 
   based certificates to mutually authenticate a RSA exchange with the 
   client credential protection.  

   The ciphersuites in Section 4 (CP_DHE and CP_DH Key Exchange 
   Algorithm) use DHE_RSA, DH_RSA, DHE_DSS or DH_DSS to mutually 
   authenticate a (Ephemeral) Diffie-Hellman exchange. 

   The ciphersuites in Section 5 (CP_ECDH and CP_ECDHE Key Exchange 
   Algorithms) use ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA or ECDHE_RSA to 
   mutually authenticate a (Ephemeral) EC Diffie-Hellman exchange. 

3. CP_RSA Key Exchange Algorithm 

   This section defines additional ciphersuites that use RSA based 
   certificates to authenticate a RSA exchange. These ciphersuites give 
   client credential protection.  

   CipherSuite                       Key Exchange  Cipher           Hash 

   TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5      RSA      RC4_40            MD5 
   TLS_CP_RSA_WITH_RC4_128_MD5            RSA      RC4_128           MD5 
   TLS_CP_RSA_WITH_RC4_128_SHA            RSA      RC4_128           SHA 
   TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5  RSA      RC2_CBC_40        MD5 
   TLS_CP_RSA_WITH_IDEA_CBC_SHA           RSA      IDEA_CBC          SHA 
   TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA   RSA      DES40_CBC         SHA 
 
 
Hajjeh & Badra            Expires June 2008                   [Page 5] 

Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
    

   TLS_CP_RSA_WITH_DES_CBC_SHA            RSA      DES_CBC           SHA 
   TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA       RSA      3DES_EDE          SHA 
   TLS_CP_RSA_WITH_AES_128_CBC_SHA        RSA      AES_128_CBC       SHA 
   TLS_CP_RSA_WITH_AES_256_CBC_SHA        RSA      AES_256_CBC       SHA 
   TLS_CP_RSA_WITH_AES_128_CTR_SHA        RSA      AES_128_CTR       SHA 
   TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA   RSA      CAMELLIA_128_CBC  SHA 
   TLS_CP_RSA_WITH_AES_256_CTR_SHA        RSA      AES_256_CTR       SHA 
   TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA   RSA      CAMELLIA_256_CBC  SHA  

4. CP_DHE and CP_DH Key Exchange Algorithms 

   This section defines additional ciphersuites that use DH and DHE as 
   key exchange algorithms, with RSA or DSS based certificates to 
   authenticate a (Ephemeral) Diffie-Hellman exchange. These 
   ciphersuites give client credential protection. 

   CipherSuite                      Key Exchange   Cipher           Hash  

   TLS_CP_DHE_DSS_WITH_DES_CBC_SHA           DHE   DES_CBC           SHA 
   TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA      DHE   3DES_EDE_CBC      SHA 
   TLS_CP_DHE_RSA_WITH_DES_CBC_SHA           DHE   DES_CBC           SHA 
   TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA      DHE   3DES_EDE_CBC      SHA 
   TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA       DHE   AES_128_CBC       SHA 
   TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA       DHE   AES_128_CBC       SHA 
   TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA       DHE   AES_256_CBC       SHA 
   TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA       DHE   AES_256_CBC       SHA 
   TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA  DHE   CAMELLIA_128_CBC  SHA 
   TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA  DHE   CAMELLIA_128_CBC  SHA 
   TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA  DHE   CAMELLIA_256_CBC  SHA 
   TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA  DHE   CAMELLIA_256_CBC  SHA 
   TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA       DHE   AES_128_CTR       SHA 
   TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA       DHE   AES_128_CTR       SHA 
   TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA       DHE   AES_256_CTR       SHA 
   TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA       DHE   AES_256_CTR       SHA 
   TLS_CP_DH_DSS_WITH_DES_CBC_SHA            DH    DES_CBC           SHA 
   TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA       DH    3DES_EDE_CBC      SHA 
   TLS_CP_DH_RSA_WITH_DES_CBC_SHA            DH    DES_CBC           SHA 
   TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA       DH    3DES_EDE_CBC      SHA 
   TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA        DH    AES_128_CBC       SHA 
   TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA        DH    AES_128_CBC       SHA 
   TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA        DH    AES_256_CBC       SHA 
   TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA        DH    AES_256_CBC       SHA  

5. CP_ECDH and CP_ECDHE Key Exchange Algorithm 

   This section defines additional ciphersuites that use ECDH and ECDHE 
   as key exchange algorithms, with RSA or ECDSA based certificates to 
 
 
Hajjeh & Badra            Expires June 2008                   [Page 6] 

Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
    

   authenticate a (Ephemeral) ECDH exchange. These ciphersuites give 
   client credential protection.  

   CipherSuite                         Key Exchange   Cipher        Hash  

   TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA        ECDH     RC4_128        SHA 
   TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   ECDH     3DES_EDE_CBC   SHA 
   TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA    ECDH     AES_128_CBC    SHA 
   TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA    ECDHE    AES_256_CBC    SHA 
   TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA       ECDHE    RC4_128        SHA 
   TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  ECDHE    3DES_EDE_CBC   SHA 
   TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   ECDHE    AES_128_CBC    SHA 
   TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDHE    AES_256_CBC    SHA 
   TLS_CP_ECDH_RSA_WITH_RC4_128_SHA          ECDH     RC4_128        SHA 
   TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     ECDH     3DES_EDE_CBC   SHA 
   TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA      ECDH     AES_256_CBC    SHA 
   TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA      ECDH     AES_256_CBC    SHA 
   TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA         ECDHE    RC4_128        SHA 
   TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    ECDHE    3DES_EDE_CBC   SHA 
   TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA     ECDHE    AES_256_CBC    SHA 
   TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA     ECDHE    AES_256_CBC    SHA 

6. Security Considerations 

   The security considerations described throughout [TLS], [DTLS], 
   [TLSAES], [TLSECC] and [TLSAES] apply here as well. 

7. IANA Considerations 

   This section provides guidance to the IANA regarding registration of 
   values related to the credential protection ciphersuites.  

   CipherSuite TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5         ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_RC4_128_MD5               ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_RC4_128_SHA               ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5     ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_IDEA_CBC_SHA              ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA      ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_DES_CBC_SHA               ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA          ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_AES_128_CBC_SHA           ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_AES_256_CBC_SHA           ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_AES_128_CTR_SHA           ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA      ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_AES_256_CTR_SHA           ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA      ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_DSS_WITH_DES_CBC_SHA           ={ 0xXX,0xXX }; 
 
 
Hajjeh & Badra            Expires June 2008                   [Page 7] 

Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
    

   CipherSuite TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA      ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_RSA_WITH_DES_CBC_SHA           ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA      ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA  ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA  ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA  ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA  ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DH_DSS_WITH_DES_CBC_SHA            ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DH_RSA_WITH_DES_CBC_SHA            ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA        ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA        ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA        ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA        ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA        ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA    ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA    ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA       ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDH_RSA_WITH_RC4_128_SHA          ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA      ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA      ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA         ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA     ={ 0xXX,0xXX }; 
   CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA     ={ 0xXX,0xXX };  

   Note: For implementation and deployment facilities, it is helpful to 
   reserve a specific registry sub-range (minor, major) for credential 
   protection ciphersuites. 




 
 
Hajjeh & Badra            Expires June 2008                   [Page 8] 

Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
    

8. References 

8.1. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [TLS]    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 
             (expired), June 2006. 

8.2. Informative References 

   [SSLTLS]  Rescorla, E., "SSL and TLS: Designing and Building Secure 
             Systems", Addison-Wesley, March 2001.  

   [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, 
             August 2000.  

   [INTEROP] Pettersen, Y., "Clientside interoperability experiences for 
             the SSL and TLS protocols",draft-ietf-tls-interoperability-
             00 (expired), October 2006.  

   [EAPIP]  Urien, P. and M. Badra, "Identity Protection within EAP-
             TLS", draft-urien-badra-eap-tls-identity-protection-01.txt 
             (expired), October 2006. 

 
 
Hajjeh & Badra            Expires June 2008                   [Page 9] 

Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
    

Author's Addresses 

   Ibrahim Hajjeh 
   INEOVATION 
   France 
      
   Email: hajjeh@ineovation.com 
    

   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 
   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 
 
 
Hajjeh & Badra            Expires June 2008                  [Page 10] 

Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
    

   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 (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. 

Acknowledgment 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 































 
 
Hajjeh & Badra            Expires June 2008                  [Page 11]