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

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