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

 

Internet Engineering Task Force                               I. Hajjeh 
                                                              ESRGroups 
                                                               M. Badra 
                                                       LIMOS Laboratory 
    
Expires: November 2007                                       June, 2007 
    
       Credential Protection Ciphersuites for Transport Layer Security 
                <draft-hajjeh-tls-identity-protection-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 November 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. 
   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. 

 
Hajjeh & Badra          Expires November 2007                  [Page 1] 
 
Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
 
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 
   [RESCORLA]. This wouldn't however be secure enough against active 
   attackers, which will be able to disclose the client's credentials 
   and wouldn't be favorable for some environments (e.g. mobile), due 
   to the additional cryptographic computations. 
    
   Client credential 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. 
    
   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 [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 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.2. Requirements language 
    


 
Hajjeh & Badra          Expires November 2007                  [Page 2] 
 
Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
 
   The key words "MUST", "MUST NOT" and "MAY" in this document are to 
   be interpreted as described in RFC-2119. 
    
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, 
   stream 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. 
    
   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, it MUST NOT include any 
   ciphersuite with client credential protection 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 [TLS1.1].  
    
   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. 
    

 
Hajjeh & Badra          Expires November 2007                  [Page 3] 
 
Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
 
   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. 
    
         Client                                        Server 
    
         ClientHello          --------> 
                                                  ServerHello 
                                                  Certificate 
                                            ServerKeyExchange* 
                                           CertificateRequest 
                              <--------       ServerHelloDone 
        {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 
    

 
Hajjeh & Badra          Expires November 2007                  [Page 4] 
 
Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
 
   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 
   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 
    


 
Hajjeh & Badra          Expires November 2007                  [Page 5] 
 
Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
 
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 
   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], 
   [TLS1.1], [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 }; 

 
Hajjeh & Badra          Expires November 2007                  [Page 6] 
 
Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
 
   CipherSuite TLS_CP_DHE_DSS_WITH_DES_CBC_SHA         = { 0xXX,0xXX }; 
   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. 
    
8. References 
    
8.1. Normative References 
    
   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",  

 
Hajjeh & Badra          Expires November 2007                  [Page 7] 
 
Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
 
              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  
    
8.1. Informative References 
    
   [RESCORLA] 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 (work in progress), October 2006. 
              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. 
    
Author's Addresses 
    
   Ibrahim Hajjeh 
   ESRGroups, Security WG 
   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
    

 
Hajjeh & Badra          Expires November 2007                  [Page 8] 
 
Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
 
   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. 
    
   Acknowledgement 
    
   Funding for the RFC Editor function is provided by the IETF 
   Administrative Support Activity (IASA). 



 
Hajjeh & Badra          Expires November 2007                  [Page 9]