idnits 2.17.1 draft-hajjeh-tls-identity-protection-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 14, 2009) is 5267 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4132 (Obsoleted by RFC 5932) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TLS Working Group I. Hajjeh 2 Internet Draft INEOVATION 3 M. Badra 4 LIMOS Laboratory 5 Intended status: Experimental November 14, 2009 6 Expires: May 2010 8 Credential Protection Ciphersuites for Transport Layer Security 9 (TLS) 10 draft-hajjeh-tls-identity-protection-09.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 14, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 This document may contain material from IETF Documents or IETF 47 Contributions published or made publicly available before November 48 10, 2008. The person(s) controlling the copyright in some of this 49 material may not have granted the IETF Trust the right to allow 50 modifications of such material outside the IETF Standards Process. 51 Without obtaining an adequate license from the person(s) controlling 52 the copyright in such materials, this document may not be modified 53 outside the IETF Standards Process, and derivative works of it may 54 not be created outside the IETF Standards Process, except to format 55 it for publication as an RFC or to translate it into languages other 56 than English. 58 Abstract 60 This document defines a set of cipher suites to add client credential 61 protection to the Transport Layer Security (TLS) protocol. By 62 negotiating one of those ciphersuites, the TLS clients will be able 63 to determine for themselves when, how, to what extent and for what 64 purpose information about them is communicated to others. The 65 ciphersuites defined in this document can be used only when public 66 key certificates are used in the client authentication process. 68 Table of Contents 70 1. Introduction...................................................3 71 1.1. Conventions used in this document.........................5 72 2. TLS credential protection overview.............................5 73 2.1. Certificate and CertificateVerify protection..............6 74 2.1.1. Stream cipher encryption.............................6 75 2.1.2. Block cipher encryption..............................7 76 2.2. Key derivation............................................7 77 2.3. Structure of Certificate and CertificateVerify............8 78 2.3.1. Certificate structure................................9 79 2.3.1.1. Case TLS version 1.2............................9 80 2.3.1.2. Case TLS version 1.1...........................10 81 2.3.1.3. Case TLS version 1.0...........................11 82 2.3.2. CertificateVerify structure.........................11 83 2.3.2.1. Case TLS version 1.2...........................11 84 2.3.2.2. Case TLS version 1.1...........................12 85 2.3.2.3. Case TLS version 1.0...........................13 86 2.4. Message Flow.............................................14 87 2.5. New ciphersuites.........................................14 88 3. CP_RSA Key Exchange Algorithm.................................15 89 4. CP_DHE Key Exchange Algorithm.................................15 90 5. CP_ECDHE Key Exchange Algorithm...............................16 91 6. Security Considerations.......................................16 92 7. References....................................................18 93 7.1. Normative References.....................................18 94 7.2. Informative References...................................19 95 Author's Addresses...............................................19 97 1. Introduction 99 The Transport Layer Security (TLS) protocol (TLS v1.0 [RFC2246], TLS 100 v1.1 [RFC4346], and TLS v1.2 [RFC5246]), is the most deployed 101 security protocol for securing exchanges. It provides end-to-end 102 secure communications between two entities with authentication and 103 data protection. 105 TLS supports three authentication modes: authentication of both 106 parties, only server-side authentication, and anonymous key exchange. 107 For each mode, TLS specifies a set of cipher suites. However, 108 anonymous cipher suites are strongly discouraged because they cannot 109 prevent man-in-the-middle (MITM) attacks. 111 The TLS authentication is usually based on either preshared keys or 112 public key certificates. If a public key certificate is used to 113 authenticate the TLS client, the TLS client credentials are sent in 114 clear text over the wire. Thus, any observer can determine the 115 credentials used by the client; learn who is reaching the network, 116 when, and from where, and hence correlate the client credentials to 117 the connection location. 119 Credentials protection and privacy are the right to informational 120 self-determination, i.e., individuals must be able to determine for 121 themselves when, how, to what extent and for what purpose information 122 about them is communicated to others. 124 TLS client credential protection may be established by changing the 125 order of the messages that the client sends after receiving 126 ServerHelloDone [CORELLA]. It consists of sending the 127 ChangeCipherSpec message before the Certificate and the 128 CertificateVerify messages and after the ClientKeyExchange message. 129 The ChangeCipherSpec message is sent to notify the receiving party 130 that subsequent messages will be protected under the cipher suite and 131 keys negotiated during the TLS Handshake. However, this solution 132 requires a major change to the TLS state machine as well as a new TLS 133 version. 135 TLS client credential protection may also be done through a DHE 136 exchange before establishing an ordinary handshake with identity 137 information [SSLTLS]. This wouldn't however be secure enough against 138 active attackers, which will be able to disclose the client's 139 credentials. Moreover, it wouldn't be favorable for some environments 140 (e.g., performance-constrained environments with limited CPU power), 141 due to the additional cryptographic computations and round trips. 143 TLS client credential protection may also be possible, assuming that 144 the client permits renegotiation after the first server 145 authentication [RFC5246]: The client and the server establish a TLS 146 session with only server-side authentication and then perform a new 147 full TLS Handshake with mutual authentication; the client credentials 148 transferred in this stage thus are protected by the secure channel 149 established in the first TLS Handshake. This solution doesn't 150 require a change to TLS. However, this solution requires more 151 asymmetric cryptographic computations, which in many environments (in 152 particular for less powerful mobile nodes) are the rate limiting step 153 in TLS, and therefore, the renegotiation has negative performance 154 consequences. In fact, renegotiation requires another round of an 155 asymmetric encryption/decryption, which means the double number of 156 asymmetric en-/decryption operations (e.g., with an RSA key) for TLS 157 Handshake message processing, for both server and client. Moreover, 158 renegotiation requires twice the number of messages and roundtrips 159 than a single TLS handshake, thus significantly increasing the 160 overall delay in the session setup. Additionally, the server is 161 forced to complete a full first TLS handshake before it becomes able 162 to confirm whether the client has a valid certificate or not. This 163 increased misbalance in processing load in the failure case might 164 open an opportunity for misbehaving clients to perform resource 165 exhaustion attacks against such servers. 167 TLS client credential protection may as well be done by allowing the 168 client and the server to add a TLS extension to their Hello messages 169 in order to negotiate specific crypto algorithms, and use these to 170 protect the client certificate [EAPIP]. This solution may suffer 171 from interoperability issues related to TLS Extensions, TLS 1.0 and 172 TLS 1.1 implementations, as described in [INTEROP]. Moreover, it 173 provides imperfect privacy guarantees. In fact, the 174 CertificateVerify message is sent in clear text over the wire. As a 175 consequence, if an attacker ever obtains a client's certificate it 176 can do trial verification to determine whether a new handshake uses 177 that certificate. 179 This document defines a set of cipher suites to add client credential 180 protection to the TLS protocol. When one of the cipher suites 181 defined through this document is negotiated, a symmetric encryption 182 is used to encrypt the TLS client Certificate and the 183 CertificateVerify messages as following: 185 o The keys for the symmetric encryption and MAC are generated 186 uniquely for each TLS Handshake and are based on a secret 187 negotiated during the TLS Handshake. These keys don't replace 188 the other keys and secrets (master_secret and key_block). 190 o Each encrypted message includes a message integrity check using 191 a keyed MAC. Secure hash functions (e.g., SHA, etc.) are used 192 for MAC computations. 194 o The encryption and MAC algorithms are determined by the 195 cipher_suite selected by the server and revealed in the 196 ServerHello message. 198 o Any key generated by this document should be deleted from 199 memory once the CertificateVerify message has been encrypted or 200 decrypted. 202 The reader is expected to become familiar with the TLS standards 203 ([RFC5246] and, if needed, [RFC4346] and [RFC2246] for its 204 predecessors) prior to studying this document. 206 1.1. Conventions used in this document 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in [RFC2119]. 212 2. TLS credential protection overview 214 This document specifies a set of cipher suites for TLS. These cipher 215 suites reuse existing key exchange algorithms with certificate-based 216 authentication, and reuse existing cipher and MAC algorithms from 217 [RFC5246], [RFC4492], and [RFC4132]. 219 The name of cipher suites defined in this document includes the text 220 "CP" to refer to the client credential protection. An example is 221 shown below. 223 CipherSuite Key Exchange Cipher Hash 224 TLS_CP_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA1 225 TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA DHE AES_128_CBC SHA1 227 If no certificates are available, the client MUST NOT include any 228 credential protection cipher suite in the ClientHello.cipher_suites. 230 If the server selects a cipher suite with client credential 231 protection, the server MUST send a certificate appropriate for the 232 negotiated cipher suite's key exchange algorithm, and MUST request a 233 certificate from the client. If the server, agreeing on using a 234 credential protection cipher suite, does not receive a client 235 certificate in response to the subsequent certificate request, then 236 it MUST abort the session by sending a fatal handshake failure alert. 238 The client certificate MUST be appropriate for the negotiated cipher 239 suite's key exchange algorithm, and any negotiated extensions. 241 2.1. Certificate and CertificateVerify protection 243 If the server selects one of the cipher suites defined in this 244 document, the client MUST symmetrically encrypt and integrity-protect 245 the Certificate and the CertificateVerify messages. 247 The encryption and MAC algorithms are determined by the cipher_suite 248 selected by the server and revealed in the ServerHello message. 250 The keys for the symmetric encryption and MAC are derived from the 251 pre_master_secret. 253 This document reuses the hash algorithm and the two symmetric 254 encryption modes defined by TLS: stream cipher encryption and block 255 cipher encryption, in a manner dependent on the negotiated TLS 256 version. 258 2.1.1. Stream cipher encryption 260 In stream cipher encryption, the client symmetrically encrypts the 261 Certificate and the CertificateVerify messages without any padding 262 byte. The encryption key cp_client_write_key is computed as 263 described in Section 2.2. 265 The MAC notation slightly varies with the TLS version being employed. 266 Symbolically, the MAC in this document is generated as follow: 268 In TLS version 1.2: 270 MAC(cp_client_write_MAC_key, plaintext) 272 The cp_client_write_MAC_key is generated as described in Section 273 2.2. 275 In TLS versions prior to 1.2: 277 HMAC_hash(cp_client_write_MAC_secret, plaintext) 279 The cp_client_write_MAC_secret is generated as described in 280 Section 2.2. 282 Note that the MAC is computed before encryption. The stream cipher 283 encrypts the entire block, including the MAC. 285 2.1.2. Block cipher encryption 287 In block cipher encryption, every block of plaintext encrypts to a 288 block of ciphertext. All block cipher encryption is done in CBC 289 (Cipher Block Chaining) mode, and all items that are block-ciphered 290 will be an exact multiple of the cipher block length. 292 In block cipher encryption, the client uses an explicit 293 initialization vector, generated as described through this document. 294 The client adds a padding value to force the structure's length of 295 each the Certificate and the CertificateVerify messages to be an 296 integral multiple of the block cipher's block length, as it is 297 described later through this document. 299 2.2. Key derivation 301 For all key exchange methods, the same algorithm is used to convert 302 the pre_master_secret into the cp_key_block (credential protection 303 key block). The cp_key_block MUST be deleted from memory as soon as 304 possible during the TLS handshake, i.e. 306 o on the client: after encoding the CertificateVerify message; 307 o on the server: after decoding and verifying this message. 309 All the keys and parameters generated in this section are used only 310 to encrypt and compute the MAC of the client Certificate and the 311 CertificateVerify messages. The name of these keys includes the text 312 "cp" to refer to this use. 314 The pending premaster secret is used as an entropy source. To 315 generate the CP encryption and MAC keys, compute using the pending 316 connection state (see Section 6.1 of [RFC5246]) 318 cp_key_block = PRF(pre_master_secret, "cp key block", 319 SecurityParameters.server_random + 320 SecurityParameters.client_random); 322 until enough output has been generated. Then the cp_key_block is 323 partitioned as follows: 325 Case TLS version 1.2: 327 cp_client_write_MAC_key[SecurityParameters.mac_key_length] 328 cp_client_write_key[SecurityParameters.enc_key_length] 330 Case TLS version 1.1: 332 cp_client_write_MAC_secret[SecurityParameters.hash_size] 333 cp_client_write_key[SecurityParameters.key_material_length] 335 Case TLS version 1.0: 337 cp_client_write_MAC_secret[SecurityParameters.hash_size] 338 cp_client_write_key[SecurityParameters.key_material_length] 339 cp_client_write_IV[SecurityParameters.IV_size] 341 Note 1: There are always four TLS connection states outstanding 342 [RFC5246]: the current read and write states, and the pending read 343 and write states. All records (conveying the Handshake messages) 344 are processed under the current read and write states per standard 345 TLS rules (i.e., usually no encryption or MAC will be used unless 346 renegotiation is in progress). 348 When one of the ciphersuites described in this document is 349 negotiated, the encryption and MAC keys generated above are used 350 to encrypt the content of the Certificate and the 351 CertificateVerify messages in the ciphersuite specific part of the 352 TLS Handshake Layer, independent of the current processing in the 353 TLS Record Layer. 355 Note 2: During the handshake, the client MUST send the Certificate 356 message before the ClientKeyExchange message. Because the 357 ClientKeyExchange message conveys the encrypted pre_master_secret, 359 o the client has to use the pre_master_secret before sending 360 the ClientKeyExchange message in order to perform the 361 credential protection key derivation necessary to encrypt 362 the Certificate and the CertificateVerify messages; 364 o the server cannot decrypt and verify the content of the 365 Certificate and the CertificateVerify messages until it has 366 received the ClientKeyExchange message, which allows the 367 server to assemble the pre_master_secret needed to perform 368 the credential protection key derivation necessary to this 369 end. 371 2.3. Structure of Certificate and CertificateVerify 373 The stream-ciphered, block-ciphered and digitally-signed structures 374 vary with the TLS version being employed. 376 2.3.1. Certificate structure 378 2.3.1.1. Case TLS version 1.2 380 opaque ASN.1Cert<1..2^24-1>; 382 struct { 383 select (SecurityParameters.cipher_type) { 384 case stream: 385 stream-ciphered struct { 386 ASN.1Cert certificate_list<0..2^24-1>; 387 opaque MAC[SecurityParameters.mac_length]; 388 }; 390 case block: 391 opaque IV[SecurityParameters.record_iv_length]; 392 block-ciphered struct { 393 ASN.1Cert certificate_list<0..2^24-1>; 394 opaque MAC[SecurityParameters.mac_length]; 395 uint8 padding[Certificate.padding_length]; 396 uint8 padding_length; 397 }; 399 }; 400 } Certificate; 402 The MAC is generated as described in Section 2.1.1 (the plaintext is 403 the certificate_list). 405 IV 406 As part of the TLS Handshake, the standard TLS IV (Initialization 407 Vector) is generated and therefore used by the TLS Record protocol. 408 This document uses a second IV, generated in the same way as 409 described in Section 6.2.3.2 of [RFC5246]. This IV is only used 410 during the encryption/decryption of the content of the Certificate 411 message (concatenation of certificate_list and MAC). 413 The IV SHOULD be chosen at random, and MUST be unpredictable. For 414 block ciphers, the IV length is SecurityParameters.record_iv_length 415 which is equal to the SecurityParameters.block_size. 417 padding 418 Padding that is added to force the length of the Certificate 419 structure to be an integral multiple of the block cipher's block 420 length. The padding MAY be any length up to 255 bytes, as long as 421 it results in the length of the encrypted Certificate being an 422 integral multiple of the block length. Lengths longer than 423 necessary might be desirable to frustrate attacks on a protocol 424 that are based on analysis of the lengths of exchanged messages. 425 Each uint8 in the padding data vector MUST be filled with the 426 padding length value. The receiver MUST check this padding and 427 SHOULD use the bad_record_mac alert to indicate padding errors. 429 padding_length 430 The padding length MUST be such that the total size of the 431 Certificate structure is a multiple of the cipher's block length. 432 Legal values range from zero to 255, inclusive. This length 433 specifies the length of the padding field exclusive of the 434 padding_length field itself. 436 2.3.1.2. Case TLS version 1.1 438 opaque ASN.1Cert<1..2^24-1>; 440 struct { 441 select (SecurityParameters.cipher_type) { 442 case stream: 443 stream-ciphered struct { 444 ASN.1Cert certificate_list<0..2^24-1>; 445 opaque MAC[SecurityParameters.hash_size]; 446 }; 448 case block: 449 block-ciphered struct { 450 opaque IV[SecurityParameters.block_length]; 451 ASN.1Cert certificate_list<0..2^24-1>; 452 opaque MAC[SecurityParameters.hash_size]; 453 uint8 padding[Certificate.padding_length]; 454 uint8 padding_length; 455 }; 457 }; 458 } Certificate; 460 The MAC is generated as described in Section 2.1.1 (the plaintext is 461 the certificate_list). For the generation and handling of the IV see 462 [RFC4346], Section 6.2.3.2; this document supports both sample 463 algorithms described there. The padding and padding_length are 464 generated and handled as described in Section 2.3.1.1. 466 2.3.1.3. Case TLS version 1.0 468 opaque ASN.1Cert<1..2^24-1>; 470 struct { 471 select (SecurityParameters.cipher_type) { 472 case stream: 473 stream-ciphered struct { 474 ASN.1Cert certificate_list<0..2^24-1>; 475 opaque MAC[SecurityParameters.hash_size]; 476 }; 478 case block: 479 block-ciphered struct { 480 ASN.1Cert certificate_list<0..2^24-1>; 481 opaque MAC[SecurityParameters.hash_size]; 482 uint8 padding[Certificate.padding_length]; 483 uint8 padding_length; 484 }; 486 }; 487 } Certificate; 489 The MAC is generated as described in Section 2.1.1 (the plaintext is 490 the certificate_list). 492 The padding is generated as described in Section 2.3.1.1. 494 Note: With block ciphers in CBC mode (Cipher Block Chaining), the IV 495 for the Certificate content is generated with the other keys and 496 secrets, as described in Section 2.2. The IV for CertificateVerify 497 content (Section 2.3.2.3) is the last ciphertext block from the 498 Certificate content. For more details of TLS 1.0 IV handling, see 499 Sections 6.1, 6.2.3.2, and 6.3, of [RFC2246]. 501 2.3.2. CertificateVerify structure 503 2.3.2.1. Case TLS version 1.2 505 digitally-signed struct { 506 opaque handshake_messages[handshake_messages_length]; 507 } Signature; 509 The digitally-signed type is described in Sections 4.7 of [RFC5246]. 510 We use the above shorthand type notation 'Signature' for the standard 511 content of the CertificateVerify struct (Section 7.4.8 of [RFC4346]) 512 in a similar manner as a variant of it was defined for TLS versions 513 1.1 and 1.0 (Section 7.4.3 in [RFC4346] and [RFC2246] -- see below). 515 struct { 516 select (SecurityParameters.cipher_type) { 517 case stream: 518 stream-ciphered struct { 519 Signature signature; 520 opaque MAC[SecurityParameters.mac_length]; 521 }; 523 case block: 524 opaque IV[SecurityParameters.record_iv_length]; 525 block-ciphered struct { 526 Signature signature; 527 opaque MAC[SecurityParameters.mac_length]; 528 uint8 padding[CertificateVerify.padding_length]; 529 uint8 padding_length; 530 }; 532 }; 533 } CertificateVerify; 535 The padding, IV and the MAC are described in Section 2.3.1.1, 536 replacing Certificate with CertificateVerify and the certificate_list 537 with the signature. Semantically, the CertificateVerify content is 538 the signature and the MAC of the certificate_list. The basic 539 Certificate Verify handshake message is described in Section 7.4.8 of 540 [RFC5246]. 542 2.3.2.2. Case TLS version 1.1 544 struct { 545 select (SecurityParameters.cipher_type) { 546 case stream: 547 stream-ciphered struct { 548 Signature signature; 549 opaque MAC[SecurityParameters.hash_size]; 550 }; 552 case block: 553 block-ciphered struct { 554 opaque IV[SecurityParameters.block_length]; 555 Signature signature; 556 opaque MAC[SecurityParameters.hash_size]; 557 uint8 padding[CertificateVerify.padding_length]; 558 uint8 padding_length; 560 }; 562 }; 563 } CertificateVerify; 565 The padding, IV and the MAC are described in Section 2.3.1.2, 566 replacing Certificate with CertificateVerify and the certificate_list 567 with the signature. Semantically, the CertificateVerify content is 568 the signature and the MAC of the certificate_list. The Signature 569 type and the basic Certificate Verify message structure for TLS 570 version 1.1 are described in Sections 7.4.3 and 7.4.8 of [RFC4346]. 572 2.3.2.3. Case TLS version 1.0 574 struct { 575 select (SecurityParameters.cipher_type) { 576 case stream: 577 stream-ciphered struct { 578 Signature signature; 579 opaque MAC[SecurityParameters.hash_size]; 580 }; 582 case block: 583 block-ciphered struct { 584 Signature signature; 585 opaque MAC[SecurityParameters.hash_size]; 586 uint8 padding[CertificateVerify.padding_length]; 587 uint8 padding_length; 588 }; 590 }; 591 } CertificateVerify; 593 The Signature type and the basic CertificateVerify message structure 594 for TLS version 1.0 are described in Sections 7.4.3 and 7.4.8 of 595 [RFC2246]. 597 With block ciphers in CBC mode, the IV is the last ciphertext block 598 from the Certificate content. The padding and the MAC are generated 599 as described in Section 2.3.1.3, replacing Certificate with 600 CertificateVerify and the certificate_list with the signature. 602 2.4. Message Flow 604 Client Server 606 ClientHello --------> 607 ServerHello 608 Certificate 609 ServerKeyExchange* 610 <-------- CertificateRequest 611 {Certificate} 612 ClientKeyExchange 613 {CertificateVerify} 614 ChangeCipherSpec 615 Finished --------> 616 ChangeCipherSpec 617 <-------- Finished 618 Application Data <-------> Application Data 620 * Indicates optional or situation-dependent messages that are not 621 always sent. 623 {} Indicates messages with symmetrically encrypted and integrity- 624 protected body. 626 For the DHE key exchange algorithm, the client always sends the 627 ClientKeyExchange message conveying its ephemeral DH public key Yc. 629 For the ECDHE key exchange algorithm, the client always sends the 630 ClientKeyExchange message conveying its ephemeral ECDH public key Yc. 632 Current TLS specifications note that if the client certificate 633 already contains a suitable DH or ECDH public key, then Yc is 634 implicit and does not need to be sent again and consequently, the 635 client key exchange message will be sent, but it MUST be empty. Even 636 if the client key exchange message is used to carry the Yc, using the 637 same Yc will allow traceability. Consequently, static Diffie-Hellman 638 SHOULD NOT be used with this document. 640 2.5. New ciphersuites 642 The cipher suites in Section 3 (CP_RSA Key Exchange Algorithm) use 643 RSA based certificates to mutually authenticate an RSA exchange with 644 client credential protection. 646 The cipher suites in Section 4 (CP_DHE Key Exchange Algorithm) use 647 DHE_RSA or DHE_DSS to mutually authenticate an Ephemeral Diffie- 648 Hellman (DHE) exchange. 650 The cipher suites in Section 5 (CP_ECDHE Key Exchange Algorithm) use 651 ECDHE_RSA or ECDHE_ECDSA to mutually authenticate an Ephemeral 652 Elliptic Curve Diffie-Hellman (ECDHE) exchange. 654 3. CP_RSA Key Exchange Algorithm 656 This section defines additional cipher suites that use RSA based 657 certificates to authenticate an RSA exchange. These cipher suites 658 give client credential protection. 660 CipherSuite Key Cipher Hash 661 Exchange 663 TLS_CP_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 664 TLS_CP_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA1 665 TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE SHA1 666 TLS_CP_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA1 667 TLS_CP_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA1 668 TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA RSA CAMELLIA_128_CBC SHA1 669 TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA RSA CAMELLIA_256_CBC SHA1 670 TLS_CP_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256 671 TLS_CP_RSA_WITH_AES_256_CBC_SHA384 RSA AES_256_CBC SHA384 673 4. CP_DHE Key Exchange Algorithm 675 This section defines additional cipher suites that use DHE as key 676 exchange algorithm, with RSA or DSS based certificates to 677 authenticate an Ephemeral Diffie-Hellman exchange. These cipher 678 suites provide client credential protection and Perfect Forward 679 Secrecy (PFS). 681 CipherSuite Key Cipher Hash 682 Exchange 684 TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA1 685 TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA1 686 TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA1 687 TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA1 688 TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA1 689 TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA1 690 TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256 691 TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 692 TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA384 DHE_DSS AES_256_CBC SHA384 693 TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA384 DHE_RSA AES_256_CBC SHA384 694 TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE_DSS CAMELLIA_128_CBC SHA1 695 TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE_RSA CAMELLIA_128_CBC SHA1 696 TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE_DSS CAMELLIA_256_CBC SHA1 697 TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE_RSA CAMELLIA_256_CBC SHA1 699 5. CP_ECDHE Key Exchange Algorithm 701 This section defines additional cipher suites that use ECDHE as key 702 exchange algorithm, with RSA or ECDSA based certificates to 703 authenticate an Ephemeral ECDH exchange. These cipher suites provide 704 client credential protection and PFS. 706 CipherSuite Key Exchange Cipher Hash 708 TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA ECDHE_ECDSA RC4_128 SHA1 709 TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA ECDHE_RSA RC4_128 SHA1 710 TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ECDHE_ECDSA 3DES_EDE_CBC SHA1 711 TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ECDHE_RSA 3DES_EDE_CBC SHA1 712 TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ECDHE_ECDSA AES_128_CBC SHA1 713 TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ECDHE_RSA AES_256_CBC SHA1 714 TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA ECDHE_RSA AES_256_CBC SHA1 715 TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA ECDHE_RSA AES_256_CBC SHA1 717 6. Security Considerations 719 The security considerations described throughout [RFC2246], 720 [RFC4346], [RFC5246], [RFC4347], and [RFC4492] apply here as well. 722 In order for the client to be protected against man-in-the-middle 723 attacks, the client SHOULD verify that the server provided a valid 724 certificate and that the received public key belongs to the server. 726 Because the question of whether this is the correct certificate is 727 outside of TLS, applications that do implement credential protection 728 cipher suites SHOULD enable the client to carefully examine the 729 certificate presented by the server to determine if it meets its 730 expectations. Particularly, the client MUST check its understanding 731 of the server hostname against the server's identity as presented in 732 the server Certificate message. 734 In the absence of an application profile specifying otherwise, the 735 matching is performed according to the following rules, as described 736 in [RFC4642]: 738 - The client MUST use the server hostname it used to open the 739 connection (or the hostname specified in the TLS "server_name" 740 extension [RFC4366]) as the value to compare against the server 741 name as expressed in the server certificate. The client MUST 742 NOT use any form of the server hostname derived from an 743 insecure remote source (e.g., insecure DNS lookup). CNAME 744 canonicalization is not done. 746 - If a subjectAltName extension of type dNSName is present in the 747 certificate, it MUST be used as the source of the server's 748 identity. 750 - Matching is case-insensitive. 752 - A "*" wildcard character MAY be used as the left-most name 753 component in the certificate. For example, *.example.com would 754 match a.example.com, foo.example.com, etc., but would not match 755 example.com. 757 - If the certificate contains multiple names (e.g., more than one 758 dNSName field), then a match with any one of the fields is 759 considered acceptable. 761 If the match fails, the client MUST either ask for explicit user 762 confirmation or terminate the connection and indicate the server's 763 identity is suspect. 765 Additionally, the client MUST verify the binding between the identity 766 of the server to which it connects and the public key presented by 767 this server. The client SHOULD implement the algorithm in Section 6 768 of [RFC5280] for general certificate validation, but MAY supplement 769 that algorithm with other validation methods that achieve equivalent 770 levels of verification (such as comparing the server certificate 771 against a local store of already-verified certificates and identity 772 bindings). 774 If the client has external information as to the expected identity of 775 the server, the hostname check MAY be omitted. 777 It will depend on the application whether or not the server will have 778 external knowledge of what the client's identity ought to be and what 779 degree of assurance it needs to obtain of it. In any case, the 780 server typically will have to check that the client has a valid 781 certificate chained to an application-specific trust anchor it is 782 configured with, following the rules of [RFC5280], before it 783 successfully finishes the TLS handshake. 785 One widely accepted layering principle is to decouple service 786 authorization from client authentication on access. We therefore 787 recommend that authorization decisions be performed and communicated 788 at the application layer after the TLS handshake has been completed. 789 Acknowledgment 790 People who should be acknowledged include Alfred Hoenes, Pasi Eronen 791 and Eric Rescorla. Listing their names here does not mean that they 792 endorse this document, but that they have reviewed it and have 793 contributed to its improvement. 795 7. References 797 7.1. Normative References 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 803 RFC 2246, January 1999. 805 [RFC4132] Moriai, S., Kato, A., Kanda M., "Addition of Camellia 806 Cipher Suites to Transport Layer Security (TLS)", RFC 4132, 807 July 2005. 809 [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 810 RFC 4346, April 2005. 812 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 813 Security", RFC 4347, April 2006. 815 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 816 and T. Wright, "Transport Layer Security (TLS) Extensions", 817 RFC 4366, April 2006. 819 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., 820 Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher 821 Suites for Transport Layer Security (TLS)", RFC 4492, May 822 2006. 824 [RFC4642] Murchison, K., Vinocur, J., Newman, C., "Using Transport 825 Layer Security (TLS) with Network News Transfer Protocol 826 (NNTP)", RFC 4642, October 2006. 828 [RFC5246] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2", 829 RFC 5246, August 2008. 831 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 832 Housley, R., and W. Polk, "Internet X.509 Public Key 833 Infrastructure Certificate and Certificate Revocation List 834 (CRL) Profile", RFC 5280, May 2008. 836 7.2. Informative References 838 [SSLTLS] Rescorla, E., "SSL and TLS: Designing and Building Secure 839 Systems", Addison-Wesley, March 2001. 841 [CORELLA] Corella, F., "adding client identity protection to TLS", 842 message on ietf-tls@lists.certicom.com mailing list, 843 http://www.imc.org/ietf-tls/mail-archive/msg02004.html, 844 August 2000. 846 [INTEROP] Pettersen, Y., "Clientside interoperability experiences for 847 the SSL and TLS protocols", 848 draft-ietf-tls-interoperability-00 (expired work in 849 progress), October 2006. 851 [EAPIP] Urien, P. and M. Badra, "Identity Protection within EAP- 852 TLS", draft-urien-badra-eap-tls-identity-protection-01.txt 853 (expired work in progress), October 2006. 855 Author's Addresses 857 Ibrahim Hajjeh 858 INEOVATION 859 France 861 Email: hajjeh@ineovation.fr 863 Mohamad Badra 864 LIMOS Laboratory - UMR6158, CNRS 865 France 867 Email: mbadra@gmail.com