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

   1
   2
   3
   4 Internet Engineering Task Force                               I. Hajjeh
   5                                                               ESRGroups
   6                                                                M. Badra
   7                                                        LIMOS Laboratory
   8
   9 Expires: November 2007                                       June, 2007
  10
  11        Credential Protection Ciphersuites for Transport Layer Security
  12                 <draft-hajjeh-tls-identity-protection-01.txt>
  13
  14
  15 Status of this Memo
  16
  17    By submitting this Internet-Draft, each author represents that any
  18    applicable patent or other IPR claims of which he or she is aware
  19    have been or will be disclosed, and any of which he or she becomes
  20    aware will be disclosed, in accordance with Section 6 of BCP 79.
  21
  22    Internet-Drafts are working documents of the Internet Engineering
  23    Task Force (IETF), its areas, and its working groups. Note that
  24    other groups may also distribute working documents as Internet-
  25    Drafts.
  26
  27    Internet-Drafts are draft documents valid for a maximum of six
  28    months and may be updated, replaced, or obsoleted by other documents
  29    at any time. It is inappropriate to use Internet-Drafts as reference
  30    material or to cite them other than as "work in progress."
  31
  32    The list of current Internet-Drafts can be accessed at
  33    http://www.ietf.org/ietf/1id-abstracts.txt
  34
  35    The list of Internet-Draft Shadow Directories can be accessed at
  36    http://www.ietf.org/shadow.html
  37
  38    This Internet-Draft will expire on November 2007.
  39
  40 Copyright Notice
  41
  42   Copyright (C) The IETF Trust (2007).
  43
  44 Abstract
  45
  46    TLS defines several ciphersuites providing authentication, data
  47    protection and session key exchange between two communicating
  48    entities. Some of these ciphersuites are used for completely
  49    anonymous key exchange, in which neither party is authenticated.
  50    However, they are vulnerable to man-in-the-middle attacks and are
  51    therefore deprecated.
  52
  53    This document defines a set of ciphersuites to add client credential
  54    protection to the Transport Layer Security (TLS) protocol.
  55
  56
  57 Hajjeh & Badra          Expires November 2007                  [Page 1] \f
  58
  59 Internet-draft  Credential protection Ciphersuites for TLS    June 2007
  60
  61 1. Introduction
  62
  63    TLS is the most deployed security protocol for securing exchanges.
  64    It provides end-to-end secure communications between two entities
  65    with authentication and data protection.
  66
  67    TLS supports three authentication modes: authentication of both
  68    parties, only server-side authentication, and anonymous key
  69    exchange. For each mode, TLS specifies a set of ciphersuites.
  70    However, anonymous ciphersuites are strongly discouraged because
  71    they cannot prevent man-in-the-middle attacks.
  72
  73    Client credential protection may be established by changing the
  74    order of the messages that the client sends after receiving
  75    ServerHelloDone [CORELLA]. This is done by sending the
  76    ChangeCipherSpec message before the Certificate and the
  77    CertificateVerify messages and after the ClientKeyExchange message.
  78    However, it requires a major change to TLS machine state as long as
  79    a new TLS version.
  80
  81    Client credential protection may also be done through a DHE exchange
  82    before establishing an ordinary handshake with identity information
  83    [RESCORLA]. This wouldn't however be secure enough against active
  84    attackers, which will be able to disclose the client's credentials
  85    and wouldn't be favorable for some environments (e.g. mobile), due
  86    to the additional cryptographic computations.
  87
  88    Client credential protection may be also possible, assuming that the
  89    client permits renegotiation after the first server authentication.
  90    However, this requires more cryptographic computations and augments
  91    significantly the number of rounds trips.
  92
  93    Client credential protection may as well be realized by exchanging a
  94    TLS extension that negotiates the symmetric encryption algorithm to
  95    be used for client certificate encrypting/decrypting [EAPTLSIP].
  96    This solution may suffer from interoperability issues related to TLS
  97    Extensions, TLS 1.0 and TLS 1.1 implementations, as described in
  98    [INTEROP].
  99
 100    This document defines a set of ciphersuites to add client credential
 101    protection to TLS protocol. Client credential protection is provided
 102    by symmetrically encrypting the client certificate with a key
 103    derived from the SecurityParameters.master_secret,
 104    SecurityParameters.server_random and
 105    SecurityParameters.client_random. The symmetric encryption algorithm
 106    is set to the cipher algorithm of the ServerHello.cipher_suite.
 107
 108 1.2. Requirements language
 109
 110
 111
 112
 113 Hajjeh & Badra          Expires November 2007                  [Page 2] \f
 114
 115 Internet-draft  Credential protection Ciphersuites for TLS    June 2007
 116
 117    The key words "MUST", "MUST NOT" and "MAY" in this document are to
 118    be interpreted as described in RFC-2119.
 119
 120 2. TLS credential protection overview
 121
 122    This document specifies a set of ciphersuites for TLS. These
 123    ciphersuites reuse existing key exchange algorithms that require
 124    based-certificates authentication, and reuse also existing MAC,
 125    stream and bloc ciphers algorithms from [TLS] and [TLSCTR],
 126    [TLSECC], [TLSAES] and [TLSCAM]. Their names include the text "CP"
 127    to refer to the client credential protection. An example is shown
 128    below.
 129
 130    CipherSuite                          Key Exchange  Cipher       Hash
 131
 132    TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5    RSA           RC4_40       MD5
 133    TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA  DHE           AES_128_CBC  SHA
 134
 135    If the client has not a certificate with a type appropriate for one
 136    of the supported cipher key exchange algorithms or if the client
 137    will not be able to send such a certificate, it MUST NOT include any
 138    ciphersuite with client credential protection in the
 139    ClientHello.cipher_suites.
 140
 141    If the server selects a ciphersuite with client credential
 142    protection, the server MUST request a certificate from the client.
 143
 144    If the server selects one of the ciphersuites defined in this
 145    document, the client MUST encrypt the Certificate and the
 146    CertificateVerify messages using the symmetric algorithm selected by
 147    the server from the list in ClientHello.cipher_suites and a key
 148    derived from the SecurityParameters.master_secret. This key is the
 149    same key used to encrypt data written by the client.
 150
 151    If a stream cipher encryption algorithm has been selected, the
 152    client symmetrically encrypts Certificate and CertificateVerify
 153    messages without any padding byte.
 154
 155    If a block cipher encryption algorithm has been selected, the client
 156    uses an explicit IV and adds padding value to force the length of
 157    the plaintext to be an integral multiple of the block cipher's block
 158    length, as it is described in section 6.2.3.2 of [TLS1.1].
 159
 160    For DHE key exchange algorithm, the client always sends the
 161    ClientKeyExchange message conveying its ephemeral DH public key Yc.
 162
 163    For ECDHE key exchange algorithm, the client always sends the
 164    ClientKeyExchange message conveying its ephemeral ECDH public key
 165    Yc.
 166
 167
 168
 169 Hajjeh & Badra          Expires November 2007                  [Page 3] \f
 170
 171 Internet-draft  Credential protection Ciphersuites for TLS    June 2007
 172
 173    Current TLS specifications note that if the client certificate
 174    already contains a suitable DH or ECDH public key, then Yc is
 175    implicit and does not need to be sent again and consequently, the
 176    client key exchange message will be sent, but it MUST be empty.
 177    Implementations of this document MUST send ClientKeyExchange message
 178    but always carrying the client Yc, whatever the PublicValueEncoding
 179    is implicit or explicit. Note that it is possible to correlate
 180    sessions by the same client when DH or ECDH are in use.
 181
 182          Client                                        Server
 183
 184          ClientHello          -------->
 185                                                   ServerHello
 186                                                   Certificate
 187                                             ServerKeyExchange*
 188                                            CertificateRequest
 189                               <--------       ServerHelloDone
 190         {Certificate}
 191          ClientKeyExchange
 192         {CertificateVerify}
 193         [ChangeCipherSpec]
 194          Finished             -------->
 195                                             [ChangeCipherSpec]
 196                               <--------              Finished
 197          Application Data     <------->      Application Data
 198
 199    * Indicates optional or situation-dependent messages that are not
 200    always sent.
 201    {} Indicates messages that are symmetrically encrypted.
 202
 203    The ciphersuites in Section 3 (CP_RSA Key Exchange Algorithm) use
 204    RSA based certificates to mutually authenticate a RSA exchange with
 205    the client credential protection.
 206
 207    The ciphersuites in Section 4 (CP_DHE and CP_DH Key Exchange
 208    Algorithm) use DHE_RSA, DH_RSA, DHE_DSS or DH_DSS to mutually
 209    authenticate a (Ephemeral) Diffie-Hellman exchange.
 210
 211    The ciphersuites in Section 5 (CP_ECDH and CP_ECDHE Key Exchange
 212    Algorithms) use ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA or ECDHE_RSA to
 213    mutually authenticate a (Ephemeral) EC Diffie-Hellman exchange.
 214
 215 3. CP_RSA Key Exchange Algorithm
 216
 217    This section defines additional ciphersuites that use RSA based
 218    certificates to authenticate a RSA exchange. These ciphersuites give
 219    client credential protection.
 220
 221    CipherSuite                      Key Exchange  Cipher           Hash
 222
 223
 224
 225 Hajjeh & Badra          Expires November 2007                  [Page 4] \f
 226
 227 Internet-draft  Credential protection Ciphersuites for TLS    June 2007
 228
 229    TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5     RSA      RC4_40            MD5
 230    TLS_CP_RSA_WITH_RC4_128_MD5           RSA      RC4_128           MD5
 231    TLS_CP_RSA_WITH_RC4_128_SHA           RSA      RC4_128           SHA
 232    TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RSA      RC2_CBC_40        MD5
 233    TLS_CP_RSA_WITH_IDEA_CBC_SHA          RSA      IDEA_CBC          SHA
 234    TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA  RSA      DES40_CBC_        SHA
 235    TLS_CP_RSA_WITH_DES_CBC_SHA           RSA      DES_CBC           SHA
 236    TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA      RSA      3DES_EDE          SHA
 237    TLS_CP_RSA_WITH_AES_128_CBC_SHA       RSA      AES_128_CBC       SHA
 238    TLS_CP_RSA_WITH_AES_256_CBC_SHA       RSA      AES_256_CBC       SHA
 239    TLS_CP_RSA_WITH_AES_128_CTR_SHA       RSA      AES_128_CTR       SHA
 240    TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA  RSA      CAMELLIA_128_CBC  SHA
 241    TLS_CP_RSA_WITH_AES_256_CTR_SHA       RSA      AES_256_CTR       SHA
 242    TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA  RSA      CAMELLIA_256_CBC  SHA
 243
 244 4. CP_DHE and CP_DH Key Exchange Algorithms
 245
 246    This section defines additional ciphersuites that use DH and DHE as
 247    key exchange algorithms, with RSA or DSS based certificates to
 248    authenticate a (Ephemeral) Diffie-Hellman exchange. These
 249    ciphersuites give client credential protection.
 250
 251    CipherSuite                      Key Exchange  Cipher           Hash
 252
 253    TLS_CP_DHE_DSS_WITH_DES_CBC_SHA          DHE   DES_CBC           SHA
 254    TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA     DHE   3DES_EDE_CBC      SHA
 255    TLS_CP_DHE_RSA_WITH_DES_CBC_SHA          DHE   DES_CBC           SHA
 256    TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA     DHE   3DES_EDE_CBC      SHA
 257    TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA      DHE   AES_128_CBC       SHA
 258    TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA      DHE   AES_128_CBC       SHA
 259    TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA      DHE   AES_256_CBC       SHA
 260    TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA      DHE   AES_256_CBC       SHA
 261    TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE   CAMELLIA_128_CBC  SHA
 262    TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE   CAMELLIA_128_CBC  SHA
 263    TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE   CAMELLIA_256_CBC  SHA
 264    TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE   CAMELLIA_256_CBC  SHA
 265    TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA      DHE   AES_128_CTR       SHA
 266    TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA      DHE   AES_128_CTR       SHA
 267    TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA      DHE   AES_256_CTR       SHA
 268    TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA      DHE   AES_256_CTR       SHA
 269    TLS_CP_DH_DSS_WITH_DES_CBC_SHA           DH    DES_CBC           SHA
 270    TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA      DH    3DES_EDE_CBC      SHA
 271    TLS_CP_DH_RSA_WITH_DES_CBC_SHA           DH    DES_CBC           SHA
 272    TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA      DH    3DES_EDE_CBC      SHA
 273    TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA       DH    AES_128_CBC       SHA
 274    TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA       DH    AES_128_CBC       SHA
 275    TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA       DH    AES_256_CBC       SHA
 276    TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA       DH    AES_256_CBC       SHA
 277
 278
 279
 280
 281 Hajjeh & Badra          Expires November 2007                  [Page 5] \f
 282
 283 Internet-draft  Credential protection Ciphersuites for TLS    June 2007
 284
 285 5. CP_ECDH and CP_ECDHE Key Exchange Algorithm
 286
 287    This section defines additional ciphersuites that use ECDH and ECDHE
 288    as key exchange algorithms, with RSA or ECDSA based certificates to
 289    authenticate a (Ephemeral) ECDH exchange. These ciphersuites give
 290    client credential protection.
 291
 292    CipherSuite                          Key Exchange Cipher        Hash
 293
 294    TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA        ECDH    RC4_128_      SHA
 295    TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   ECDH    3DES_EDE_CBC  SHA
 296    TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA    ECDH    AES_128_CBC   SHA
 297    TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA    ECDHE   AES_256_CBC   SHA
 298    TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA       ECDHE   RC4_128       SHA
 299    TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  ECDHE   3DES_EDE_CBC  SHA
 300    TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   ECDHE   AES_128_CBC   SHA
 301    TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDHE   AES_256_CBC   SHA
 302    TLS_CP_ECDH_RSA_WITH_RC4_128_SHA          ECDH    RC4_128       SHA
 303    TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     ECDH    3DES_EDE_CBC  SHA
 304    TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA      ECDH    AES_256_CBC   SHA
 305    TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA      ECDH    AES_256_CBC   SHA
 306    TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA         ECDHE   RC4_128       SHA
 307    TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    ECDHE   3DES_EDE_CBC  SHA
 308    TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA     ECDHE   AES_256_CBC   SHA
 309    TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA     ECDHE   AES_256_CBC   SHA
 310
 311 6. Security Considerations
 312
 313    The security considerations described throughout [TLS], [DTLS],
 314    [TLS1.1], [TLSAES], [TLSECC] and [TLSAES] apply here as well.
 315
 316 7. IANA Considerations
 317
 318    This section provides guidance to the IANA regarding registration of
 319    values related to the credential protection ciphersuites.
 320
 321    CipherSuite TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5       = { 0xXX,0xXX };
 322    CipherSuite TLS_CP_RSA_WITH_RC4_128_MD5             = { 0xXX,0xXX };
 323    CipherSuite TLS_CP_RSA_WITH_RC4_128_SHA             = { 0xXX,0xXX };
 324    CipherSuite TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5   = { 0xXX,0xXX };
 325    CipherSuite TLS_CP_RSA_WITH_IDEA_CBC_SHA            = { 0xXX,0xXX };
 326    CipherSuite TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA    = { 0xXX,0xXX };
 327    CipherSuite TLS_CP_RSA_WITH_DES_CBC_SHA             = { 0xXX,0xXX };
 328    CipherSuite TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA        = { 0xXX,0xXX };
 329    CipherSuite TLS_CP_RSA_WITH_AES_128_CBC_SHA         = { 0xXX,0xXX };
 330    CipherSuite TLS_CP_RSA_WITH_AES_256_CBC_SHA         = { 0xXX,0xXX };
 331    CipherSuite TLS_CP_RSA_WITH_AES_128_CTR_SHA         = { 0xXX,0xXX };
 332    CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA    = { 0xXX,0xXX };
 333    CipherSuite TLS_CP_RSA_WITH_AES_256_CTR_SHA         = { 0xXX,0xXX };
 334    CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA    = { 0xXX,0xXX };
 335
 336
 337 Hajjeh & Badra          Expires November 2007                  [Page 6] \f
 338
 339 Internet-draft  Credential protection Ciphersuites for TLS    June 2007
 340
 341    CipherSuite TLS_CP_DHE_DSS_WITH_DES_CBC_SHA         = { 0xXX,0xXX };
 342    CipherSuite TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA    = { 0xXX,0xXX };
 343    CipherSuite TLS_CP_DHE_RSA_WITH_DES_CBC_SHA         = { 0xXX,0xXX };
 344    CipherSuite TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0xXX,0xXX };
 345    CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA     = { 0xXX,0xXX };
 346    CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA     = { 0xXX,0xXX };
 347    CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA     = { 0xXX,0xXX };
 348    CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA     = { 0xXX,0xXX };
 349    CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX };
 350    CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX };
 351    CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX };
 352    CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX };
 353    CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA     = { 0xXX,0xXX };
 354    CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA     = { 0xXX,0xXX };
 355    CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA     = { 0xXX,0xXX };
 356    CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA     = { 0xXX,0xXX };
 357    CipherSuite TLS_CP_DH_DSS_WITH_DES_CBC_SHA          = { 0xXX,0xXX };
 358    CipherSuite TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA     = { 0xXX,0xXX };
 359    CipherSuite TLS_CP_DH_RSA_WITH_DES_CBC_SHA          = { 0xXX,0xXX };
 360    CipherSuite TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA     = { 0xXX,0xXX };
 361    CipherSuite TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA      = { 0xXX,0xXX };
 362    CipherSuite TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA      = { 0xXX,0xXX };
 363    CipherSuite TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA      = { 0xXX,0xXX };
 364    CipherSuite TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA      = { 0xXX,0xXX };
 365    CipherSuite TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA      = { 0xXX,0xXX };
 366    CipherSuite TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX };
 367    CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA  = { 0xXX,0xXX };
 368    CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA  = { 0xXX,0xXX };
 369    CipherSuite TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA     = { 0xXX,0xXX };
 370    CipherSuite TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA= { 0xXX,0xXX };
 371    CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX };
 372    CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX };
 373    CipherSuite TLS_CP_ECDH_RSA_WITH_RC4_128_SHA        = { 0xXX,0xXX };
 374    CipherSuite TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA   = { 0xXX,0xXX };
 375    CipherSuite TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA    = { 0xXX,0xXX };
 376    CipherSuite TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA    = { 0xXX,0xXX };
 377    CipherSuite TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA       = { 0xXX,0xXX };
 378    CipherSuite TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA  = { 0xXX,0xXX };
 379    CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA   = { 0xXX,0xXX };
 380    CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA   = { 0xXX,0xXX };
 381
 382    Note: For implementation and deployment facilities, it is helpful to
 383    reserve a specific registry sub-range (minor, major) for credential
 384    protection ciphersuites.
 385
 386 8. References
 387
 388 8.1. Normative References
 389
 390    [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 391
 392
 393 Hajjeh & Badra          Expires November 2007                  [Page 7] \f
 394
 395 Internet-draft  Credential protection Ciphersuites for TLS    June 2007
 396
 397               RFC 2246, January 1999.
 398
 399    [TLS1.1]   Dierks, T. and E. Rescorla, "The TLS Protocol Version
 400               1.1", RFC 4346, April 2005.
 401
 402    [DTLS]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer
 403               Security", RFC 4347, April 2006.
 404
 405    [TLSCAM]   Moriai, S., Kato, A., Kanda M., "Addition of Camellia
 406               Cipher Suites to Transport Layer Security (TLS)",
 407               RFC 4132, July 2005.
 408
 409    [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)
 410               Ciphersuites for Transport Layer Security (TLS)",
 411               RFC 3268, June 2002.
 412
 413    [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,
 414               Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
 415               Suites for Transport Layer Security (TLS)", RFC 4492, May
 416               2006
 417
 418    [TLSCTR]   Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher
 419               Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work
 420
 421 8.1. Informative References
 422
 423    [RESCORLA] Rescorla, E., "SSL and TLS: Designing and Building Secure
 424               Systems", Addison-Wesley, March 2001.
 425
 426    [CORELLA]  Corella, F., "adding client identity protection to TLS",
 427               message on ietf-tls@lists.certicom.com mailing list,
 428               http://www.imc.org/ietf-tls/mail-archive/msg02004.html,
 429               August 2000.
 430
 431    [INTEROP]  Pettersen, Y., "Clientside interoperability
 432               experiences for the SSL and TLS protocols", draft-ietf-
 433               tls-interoperability-00 (work in progress), October 2006.
 434               in progress), June 2006.
 435
 436    [EAPTLSIP] Urien, P. and M. Badra, "Identity Protection within EAP-
 437               TLS",
 438               draft-urien-badra-eap-tls-identity-protection-01.txt
 439               (work in progress), October 2006.
 440
 441 Author's Addresses
 442
 443    Ibrahim Hajjeh
 444    ESRGroups, Security WG
 445    France                    Email: Ibrahim.Hajjeh@esrgroups.org
 446
 447
 448
 449 Hajjeh & Badra          Expires November 2007                  [Page 8] \f
 450
 451 Internet-draft  Credential protection Ciphersuites for TLS    June 2007
 452
 453    Mohamad Badra
 454    LIMOS Laboratory - UMR (6158), CNRS
 455    France                    Email: badra@isima.fr
 456
 457    Full Copyright Statement
 458
 459    Copyright (C) The IETF Trust (2007).
 460
 461    This document is subject to the rights, licenses and restrictions
 462    contained in BCP 78, and except as set forth therein, the authors
 463    retain all their rights.
 464
 465    This document and the information contained herein are provided on
 466    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 467    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
 468    IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
 469    WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
 470    WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
 471    ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
 472    FOR A PARTICULAR PURPOSE.
 473
 474    Intellectual Property
 475
 476    The IETF takes no position regarding the validity or scope of any
 477    Intellectual Property Rights or other rights that might be claimed
 478    to pertain to the implementation or use of the technology described
 479    in this document or the extent to which any license under such
 480    rights might or might not be available; nor does it represent that
 481    it has made any independent effort to identify any such rights.
 482    Information on the procedures with respect to rights in RFC
 483    documents can be found in BCP 78 and BCP 79.
 484
 485    Copies of IPR disclosures made to the IETF Secretariat and any
 486    assurances of licenses to be made available, or the result of an
 487    attempt made to obtain a general license or permission for the use
 488    of such proprietary rights by implementers or users of this
 489    specification can be obtained from the IETF on-line IPR repository
 490    at http://www.ietf.org/ipr.
 491
 492    The IETF invites any interested party to bring to its attention any
 493    copyrights, patents or patent applications, or other proprietary
 494    rights that may cover technology that may be required to implement
 495    this standard.  Please address the information to the IETF at ietf-
 496    ipr@ietf.org.
 497
 498    Acknowledgement
 499
 500    Funding for the RFC Editor function is provided by the IETF
 501    Administrative Support Activity (IASA).
 502
 503
 504
 505
 506 Hajjeh & Badra          Expires November 2007                  [Page 9] \f