idnits 2.17.1 draft-mglt-lurk-tls-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 19, 2016) is 3017 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 209, but not defined -- Looks like a reference, but probably isn't: '28' on line 236 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Migault 3 Internet-Draft K. Ma 4 Intended status: Standards Track Ericsson 5 Expires: July 22, 2016 January 19, 2016 7 Authentication Model and Security Requirements for the TLS/DTLS Content 8 Provider Edge Server Split Use Case 9 draft-mglt-lurk-tls-requirements-00 11 Abstract 13 In the TLS/DTLS Content provider Edge Server Split use case, a TLS 14 Client uses TLS/DTLS to authenticates the Content Provider while 15 establishing a TLS/DTLS session with the Edge Server. Such 16 authentication scheme is designated as Split Authentication in this 17 document. 19 In most cases, the Edge Server does not even belong to the Content 20 Provider, but instead to a third party like, for example, a Content 21 Delivery Network. As a result, the Content Provider and the Edge 22 Server must be able to interact and/or share some information. 23 Interactions and shared information constitutes a split 24 authentication model varies with the authentication method involved 25 in the TLS session. 27 For each TLS/DTLS authentication method, the document provides the 28 associated split authentication model that makes possible a split 29 authentication. The split authentication model is associated to 30 security requirements and an analysis to show it does not introduce 31 any weakness compared to the standard TLS authentication model. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 22, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Handshake Authentication Methods for DTLS1.2 / TLS1.2 . . . . 4 71 4.1. RSA Authentication . . . . . . . . . . . . . . . . . . . 6 72 4.1.1. Standard TLS Authentication Description . . . . . . . 6 73 4.1.2. Split Authentication Model . . . . . . . . . . . . . 7 74 4.1.3. Security Analysis . . . . . . . . . . . . . . . . . . 7 75 4.2. DH_DSS, DH_RSA, ECDH_ECDSA, ECDH_RSA . . . . . . . . . . 8 76 4.2.1. Standard TLS Authentication Description . . . . . . . 9 77 4.2.2. Split Authentication Model . . . . . . . . . . . . . 9 78 4.2.3. Security Analysis . . . . . . . . . . . . . . . . . . 10 79 4.3. DH_anon, ECDH_anon . . . . . . . . . . . . . . . . . . . 11 80 4.3.1. Standard TLS Authentication Description . . . . . . . 11 81 4.3.2. Split Authentication Model . . . . . . . . . . . . . 11 82 4.3.3. Security Analysis . . . . . . . . . . . . . . . . . . 11 83 4.4. DHE_DSS, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA . . . . . . . . 12 84 4.4.1. Standard TLS Authentication Description . . . . . . . 12 85 4.4.2. Split Authentication Model . . . . . . . . . . . . . 13 86 4.4.3. Security Analysis . . . . . . . . . . . . . . . . . . 14 87 4.5. PSK, DHE_PSK, RSA_PSK . . . . . . . . . . . . . . . . . . 16 88 4.5.1. Standard TLS Authentication Description . . . . . . . 16 89 4.5.2. Split Authentication Model . . . . . . . . . . . . . 17 90 4.5.3. Security Analysis . . . . . . . . . . . . . . . . . . 19 91 4.6. Client Hash and Signature . . . . . . . . . . . . . . . . 20 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 94 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 97 8.2. Informative References . . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 TLS is commonly used by applications to authenticate their counter 104 part. Although the client part of the application and the TLS Client 105 are likely to be hosted on the same node, this is no longer true on 106 the server endpoints. As presented in [draft-mglt-tls-session-key- 107 interface-use-cases], split scenarios considers that the TLS endpoint 108 (Edge Server) and the application endpoint (Content Provider) may be 109 hosted on different nodes that may not even share a common 110 administrative domain. 112 Authentication of the Content Provider while establishing a TLS/DTLS 113 session with the Edge Server is designated in this document as a 114 split authentication. How split authentication can be performed 115 varies on the TLS authentication method involved between the TLS 116 Client and the Edge Server. The requirements on the information that 117 can be shared between the Content Provider and the Edge Server, as 118 well as the interactions between these two entities constitute a 119 split authentication model. 121 This document provides a split authentication model for each TLS 122 method. The model is often expresses as a list of requirements. 123 These split authentication models are designed to avoid the leak of 124 secret authentication credentials of the Content Provider, and 125 matched against the standard TLS/DTLS authentication model. More 126 especially, the split authentication models are designed not to 127 introduce vulnerabilities or weakness compared to the standard TLS 128 authentication model. 130 2. Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Terminology 138 In addition to the terminology used in [draft-mglt-tls-session-key- 139 interface-use-cases], the current document defines 141 Split Authentication : designates the case when a TLS Client 142 authenticates the Content Provider, while establishing a TLS 143 session with a Edge Server. This is a three party 144 authentication as the Edge Server may not necessarily belong to 145 the Content Provider, nor share authentication credentials - 146 like private keys for example - with the Content Provider. Use 147 cases can be found in [draft-mglt-tls-session-key-interface- 148 use-cases] 150 Split Authentication Model : designates the information that can be 151 shared as well as the interactions between the Edge Server and 152 the Content Provider in order to enable the split 153 authentication. In most cases, each TLS authentication method 154 comes with a specific authentication model. 156 Standard TLS Authentication Model : designates the standard 157 authentication model for TLS, i.e. between the TLS Client and 158 the TLS Server. 160 DH: Diffie Hellman 162 ECDH Elliptical Diffie Hellman 164 4. Handshake Authentication Methods for DTLS1.2 / TLS1.2 166 TLS has been designed for end-to-end security. This means that the 167 TLS Client is expected to authenticate and set up a secure channel 168 with the other end point of the communication designated as TLS 169 Server. 171 TLS provides multiple KeyExchangeAlgorithm to authenticate the TLS 172 Server by the TLS Client. Current authentication methods for DTLS 173 1.2 [RFC6347] TLS 1.2 [RFC5246] are dhe_dss, dhe_rsa, dh_anon, rsa, 174 dh_dss and dh_rsa. [RFC4492] defines the additional ecdh_ecdsa, 175 ecdhe_ecdsa, ecdh_rsa, ecdhe_rsa and ecdh_anon. In addition, 176 [RFC4279] defines psk, dhe_psk and rsa_psk. 178 For each authentication method, this section provides a brief 179 description of the authentication method. The authentication 180 involves multiple credentials usually associated to the Content 181 Provider. For each of these credential this section specifies 182 whether it can be shared with the Edge Servers or not, and if not 183 what information the Content Provider needs to provide to the Edge 184 Server so the TLS session can be agreed between the TLS Client and 185 the Edge Server. 187 Authentication in TLS1.2 is performed during the Handshake Protocol 188 -- see section 7.3 in [RFC5246]. The messages involved in the 189 authentication are Certificate, the ServerKeyExchange, the client 190 Certificate, and the ClientKeyExchange message. Not all of them are 191 always involved, and the following sections provides a high level 192 description on how authentication is performed with the different 193 methods. Figure 1 illustrates the various messages exchanges during 194 a full handshake protocol in TLS1.2. 196 Client Server 198 ClientHello --------> 199 ServerHello 200 Certificate* 201 ServerKeyExchange* 202 CertificateRequest* 203 <-------- ServerHelloDone 204 Certificate* 205 ClientKeyExchange 206 CertificateVerify* 207 [ChangeCipherSpec] 208 Finished --------> 209 [ChangeCipherSpec] 210 <-------- Finished 211 Application Data <-------> Application Data 213 * Indicates optional or situation-dependent messages that 214 are not always sent. 216 Figure 1: TLS1.2 Full Handshake 218 The purpose of the authentication in TLS is that the TLS Client and 219 the TLS Server can agree on a master_secret that will be used to 220 derive all necessary keys to secure the channel between the TLS 221 Client and the TLS Server. This master_secret is derived from a 222 pre_master agreed between the TLS Client and the TLS Server. 223 [RFC5246] and [RFC7627] define different ways to generate the 224 master_secret from the pre_master. 226 For information, in [RFC5246], the master_secret is generated as 227 follows: 229 master_secret = PRF(pre_master_secret, "master secret", 230 ClientHello.random + ServerHello.random) 231 [0..47]; 233 where: 234 struct { 235 uint32 gmt_unix_time; # 4 bytes 236 opaque random_bytes[28]; 237 } Random; 239 master_secret 241 [RFC7627] defines the Extended Master Secret Extension where the 242 "master_secret" is defined as follows: 244 master_secret = PRF(pre_master_secret, "extended master secret", 245 session_hash) 246 [0..47]; 247 where: 248 - session_hash = Hash(handshake_messages) 249 - handshake_messages is the concatenation of all the exchanged 250 Handshake structures, as defined in Section 7.4 of [RFC5246]. 251 - Hash is as defined in Section 7.4.9 of [RFC5246] 253 Note that in TLS1.2 section 5 mentions "New cipher suites MUST 254 explicitly specify a PRF and, in general, SHOULD use the TLS PRF with 255 SHA-256 or a stronger standard hash function." This means that 256 TLS1.2 provides the necessary cryptographic agility that allow the 257 use of different hash function to generate the master secret from the 258 premaster secret is collision free. 260 4.1. RSA Authentication 262 4.1.1. Standard TLS Authentication Description 264 When key exchange method chosen by the TLS Server is rsa, the TLS 265 Server provides a ServerCertificate message that contains the public 266 RSA key. This RSA key will be used for encryption. The TLS Client 267 checks the public key provided by the certificate is associated to 268 the requested entity, and then checks the binding between the RSA 269 public key and the Content provider is certified by a trusted 270 Certification Authority. This later operation requires that the TLS 271 Client and the TLS Server share a common trusted Certification 272 Authority as well as the TLS Client is able to check the signature 273 embedded in the certificate. More specifically, the TLS must support 274 the necessary hash and signature algorithms to check the certificate. 275 The TLS Client does not inform the TLS Server what are the TLS 276 Client's trusted CA, on the other hand, it provides the supported 277 hash and signature - see Section 4.6. 279 The TLS Client sends the EncryptedPreMasterSecret, a premaster 280 encrypted with the RSA public key of the TLS Server - provided in the 281 Certificate - in a ClientKeyExchange message. The TLS Client does 282 not provide any Certificate message. 284 The TLS Server is considered authenticated, if it can provide a proof 285 of ownership of the private key associated to the public key provided 286 in the certificate. In the case of the rsa key exchange algorithm, 287 the TLS Server, needs the private key to decrypt the premaster secret 288 in order to derive the master secret and all session keys, and have 289 the same sessions keys as the TLS Client. Without the private key 290 the TLS Server will not be able to decrypt the premaster secret and 291 thus not be able to agree with the TLS Client the session keys. In 292 other words, the TLS session cannot be established. 294 4.1.2. Split Authentication Model 296 This section lists the requirements to use the RSA authentication in 297 a split authentication model. The requirements regarding the 298 credential information shared between the Content Provider and the 299 Edge Server are: 301 REQ1: The Content Provider SHOULD share the RSA public key with the 302 Edge Server. The RSA public key is public information and is 303 conveyed in the ServerCertificate message. 305 REQ2: The Content Provider MUST NOT share the private RSA key with 306 the Edge Server. The RSA private key is associated to the 307 Content Provider and SHOULD be kept in a secure place. 309 The RSA private key is necessary to the Edge Server to decrypt the 310 premaster secret so the TLS Server and the TLS Client can set the 311 session keys. These operations can only be performed by the owner of 312 the private key, that is in our case the Content Provider. Thus, the 313 requirements regarding interactions between the Content Provider and 314 the Edge Server are: 316 REQ3: The Content Provider MUST provide RSA decryption facilities to 317 the Edge Servers. The Edge Server SHOULD be able to provide 318 the EncryptedPremasterSecret - as well as additional necessary 319 parameters - and be returned the clear text premaster or the 320 master secret so the Edge Server and the TLS Client can agree 321 and set the TLS channel. 323 4.1.3. Security Analysis 325 This section provides a security analysis of the split authentication 326 model versus the standard TLS authentication model with RSA used as 327 an authentication method. The purpose of this section is to show 328 that the Content Provider in the split authentication model does not 329 leak more information on its secret credential than the TLS Server 330 does in the standard TLS model. 332 In the split authentication model, the Content Provider receives the 333 EncryptedPremasterSecret and returns the cleartext premaster. This 334 is exactly the information provided by the TLS Server to the TLS 335 Client in the TLS standard authentication model. 337 The Edge Server can perform a chosen cipher text attack as it can 338 send ciphered text to the Content Provider and get the corresponding 339 clear text. Such attack cannot be performed by the TLS Client in the 340 standard TLS authentication model as the TLS Client generate the 341 premaster and does not get the clear text premaster from the TLS 342 Server, and retrieving the premaster from the session key is believe 343 to be unfeasible. 345 Another difference between the split authentication model and the 346 standard TLS model is that unlike the TLS Server, the Content 347 Provider cannot check whether the computation of the premaster leads 348 to an effective TLS session. This may be detected by the Edge Server 349 and not by the Content Provider. On the other hand, the Content 350 Provider centralizes the operations of all TLS Servers, which 351 provides the ability to detect orchestrated or cipher text attacks. 352 Also some of the discussion are discussed in the architecture 353 document, on a model comparison, one can say that the split 354 authentication model exposes the Content Provider to a cipher text 355 attack, which can be prevented by the appropriated choice of the RSA 356 parameters: 358 REQ4: RSA parameters MUST be chosen to make cipher text attack 359 infeasible. 361 REQ5: The Content Provider MUST be able to provide the master secret 362 or the extended master secret instead of the premaster. This 363 could mitigate the cipher text attack as it is believe to be 364 infeasible to retrieve the premaster secret from the master or 365 extended master secret. 367 REQ6: The Content Provider SHOULD be able to provide the premaster 368 secret. 370 In order to protect the TLS session between the TLS Client and the 371 Edge Server, the master secret or the premaster secret must not be 372 disclosed. Follows the security requirements on the Content Provider 373 / Edge Server channel: 375 REQ7: The communication between the Edge Server and the Content 376 Provider MUST be authenticated and encrypted. 378 As a result, the split authentication model is not expected to leak 379 more information than the standard TLS authentication model as long 380 as RSA parameters are appropriately chosen. 382 4.2. DH_DSS, DH_RSA, ECDH_ECDSA, ECDH_RSA 383 4.2.1. Standard TLS Authentication Description 385 With Diffie Hellman fixed values, the TLS Server provides a 386 ServerCertificate which contains a certificate that contains the 387 fixed DH or ECDH value. The DH or ECDH fix value is authenticated by 388 the Certification Authority with a specific signature algorithm - 389 RSA, DSS or ECDSA for example. As the DH or ECDH keys are used to 390 establish a shared secret from public values, the purpose of the key 391 is limited to the key agreement and the certificate is expected to 392 have the key usage set to key agreement - e.g. the key is not used 393 for signing or encrypting. 395 In order to compute the shared secret, the TLS Server expects to 396 receive the TLS Client DH / ECDH counter part fix value. Optionally, 397 the TLS Server can send a Certificate Request with the type 398 corresponding to the key agreement method: rsa_fixed_dh, 399 dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh. 401 Upon receiving the ServerCertificate message and optionally the 402 CertificateRequest from the TLS Server, the TLS Client sends back a 403 ClientCertificate with the same type as the ServerCertificate 404 (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh). 406 Once the TLS Client and the TLS Server have exchanged their fixed DH 407 / ECDH value, the pre_master can be derived by both the TLS Client 408 and the TLS Server by combining the public and private DH / ECDH key. 409 The premaster is then agreed between the TLS Server and the TLS 410 Client and session keys can be derived from both the TLS Server and 411 TLS Client. 413 4.2.2. Split Authentication Model 415 This section lists the requirements to use the DH_DSS, DH_RSA, 416 ECDH_ECDSA, ECDH_RSA authentication in a split authentication model. 417 The requirements regarding the credential information shared between 418 the Content Provider and the Edge Server are: 420 REQ8: The Content Provider SHOULD share the DH or ECDH public key 421 with the Edge Server. The DH or ECDH public key is public 422 information and is conveyed in the ServerCertificate message. 424 REQ9: The Content Provider MUST NOT share the private DH or ECDH key 425 with the Edge Servers. The DH or ECDH private key is 426 associated to the Content Provider and SHOULD be kept in a 427 secure place. 429 The DH or ECDH private key is necessary to the Edge Server to decrypt 430 the premaster secret so the TLS Server and the TLS Client can set the 431 session keys. These operations can only be performed by the owner of 432 the private key, that is in our case the Content Provider. Thus, the 433 requirements regarding interactions between the Content Provider and 434 the Edge Server are: 436 REQ10: The Content Provider SHOULD provide the Edge Server facilities 437 to compute the DH or ECDH shared secret, the premaster, the 438 premaster or the extended master to the Edge Server. 440 4.2.3. Security Analysis 442 This section provides a security analysis of the split authentication 443 model versus the standard TLS authentication model with DH_DSS, 444 DH_RSA, ECDH_ECDSA, ECDH_RSA used as an authentication method. The 445 purpose of this section is to show that the Content Provider in the 446 split authentication model does not leak more information on its 447 secret credential than the TLS Server does in the standard TLS model. 449 When the Content Provider receives the public key of the TLS Client, 450 it may return the shared DH / ECDH secret to the Edge Server. In 451 that case, the Edge Server is exactly aware of the shared secret as 452 well as the respective public keys of the Content Provider and the 453 TLS Client. The situation differs from a node intercepting the DH / 454 ECDH exchange as this node never gets the resulting secret. On the 455 other hand, such information are also exchanged between the TLS 456 Server and the TLS Client in the TLS standard authentication model. 458 As a result, interactions between the Edge Server and the Content 459 Provider is not expected to leak more information then the TLS Server 460 leak information to the TLS Client in [RFC5246]. 462 Similarly to Section 4.1.3 the Content Provider can hardly 463 distinguish the premaster that are being requested in order to 464 perform an attack to the premasters that ends up into a TLS session. 465 As a result, 467 REQ11: DH / ECDH parameters MUST be chosen to make guessing attacks 468 infeasible. 470 REQ12: The Content Provider MAY provide the master secret or the 471 extended master secret instead of the premaster. This could 472 mitigate the cipher text attack as it is believe to be 473 infeasible to retrieve the premaster secret from the master or 474 extended master secret. 476 In order to protect the TLS session between the TLS Client and the 477 Edge Server, the master secret or the premaster secret must not be 478 disclosed. Follows the security requirements on the Content Provider 479 / Edge Server channel: 481 REQ13: The communication between the Edge Server and the Content 482 Provider MUST be authenticated and encrypted. 484 As a result, the split authentication model is not expected to leak 485 more information than the standard TLS authentication model as long 486 as DH / ECDH parameters are appropriately chosen. 488 4.3. DH_anon, ECDH_anon 490 4.3.1. Standard TLS Authentication Description 492 With anonymous DH or ECDH - as opposed to fixed DH - the Certificate 493 message is not appropriated to carry the DH or ECDH parameters, as 494 they are not expected to be signed by a CA. As a result, the TLS 495 Server provides the DH / ECDH parameters in a ServerDHParams 496 structure or a ECParameters carried by a ServerKeyExchange message. 498 Upon receipt of the ServerKeyExchange, the TLS Client responds with a 499 ClientKeyExchange with the associated DH / ECDH parameters. 501 Once the TLS Client and the TLS Server have exchanged the fixed DH / 502 ECDH value, the pre_master is agreed between the TLS Server and the 503 TLS Client and session keys can be derived from both the TLS Server 504 and TLS Client. 506 4.3.2. Split Authentication Model 508 This section lists the requirements to use the DH_anon or ECDH_anon 509 authentication in a split authentication model. The requirements 510 regarding the credential information shared between the Content 511 Provider and the Edge Server are: 513 REQ14: The DH or ECDH public and private keys SHOULD be generated by 514 the Edge Servers. In other words, the DH or ECDH keys used 515 SHOULD NOT be generated and associated to the Content 516 Provider. As no authentication is provided to the TLS Client, 517 there is no need to use private information of the Content 518 provider. 520 4.3.3. Security Analysis 522 This section provides a security analysis of the split authentication 523 model versus the standard TLS authentication model with DH_anon or 524 ECDH_anon used as an authentication method. The purpose of this 525 section is to show that the Content Provider in the split 526 authentication model does not leak more information on its secret 527 credential than the TLS Server does in the standard TLS model. 529 The DH_anon and ECDH_anon authentication methods do not involve any 530 authentication credentials from the Content Provider, so the risks of 531 leakage of Content Provider authentication are not considered in this 532 case. 534 As a result, the split authentication model is not expected to leak 535 more information than the standard TLS authentication model. 537 4.4. DHE_DSS, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA 539 4.4.1. Standard TLS Authentication Description 541 With ephemeral DH or ECDH - as opposed to fixed DH - the Certificate 542 message is not appropriated to carry the DH / ECDH parameters. In 543 fact, with ephemeral DH / ECDH, the DH / ECDH parameters are not 544 signed by a CA. Instead, they are signed by a signature-capable 545 certificate, which has been signed by the CA. 547 Since Certificate messages are not appropriated to carry the DH / 548 ECDH parameters, the TLS Server provides the DH / ECDH parameters in 549 a ServerDHParams structure or a ECParameters carried by a 550 ServerKeyExchange message. This is the same structure as for 551 anonymous DH / ECDH. In order to authenticate, a proof of ownership 552 is added. This proof of ownership takes the form of a signature of a 553 combination of the DH / ECDH parameters associated with the 554 ClientHello.random and the ServerHello.random. The exact structure 555 signed_params for DHE_RSA or ECDHE_RSA is defined in section 7.4.3 of 556 [RFC5246], or Signature for ECDSA_ECDSA is defined in section 5.4 of 557 [RFC4492]. In order to check the signature associated to the DH / 558 ECDH parameters, the TLS Server provides the necessary public key 559 associated to the TLS Server. These keys are carried in a 560 ServerCertificate signed by a CA. These certificates are used to 561 check the signature only. 563 Upon receipt of the ServerKeyExchange and the ServerCertificate, the 564 TLS Client provides the DH / ECDH parameters to the TLS Server via 565 the ClientDiffieHellmanPublic defined in section 7.4.7.2 of [RFC5246] 566 or ClientECDiffieHellmanPublic structure defined in section 5.7 of 567 [RFC4492]. Both structures are conveyed by the ClientKeyExchange 568 message. This message does not carry any signatures that enable the 569 TLS Server to authenticate the TLS Client. The TLS Client can be 570 authenticated by providing a signing key in a ClientCertificate. The 571 key is signed by a CA. On the other hand, the proof of ownership of 572 the key by the TLS Client is provided by sending a CertificateVerify. 574 The CertificateVerify message is the generic mechanism to 575 authenticate the TLS Client over the global TLS exchange. 577 4.4.2. Split Authentication Model 579 This section lists the requirements to use the DHE_DSS, DHE_RSA, 580 ECDHE_RSA, ECDHE_ECDSA authentication in a split authentication 581 model. The requirements regarding the credential information shared 582 between the Content Provider and the Edge Server are: 584 REQ15: The Content Provider SHOULD share the public key with the Edge 585 Server. The public key is used for signing the DH ECDH 586 parameters. The public key is respectively a DSS public key 587 when DHE_DSS is selected, a RSA public key when ECDHE_RSA is 588 selected or a ECDSA public key when ECDHE_ECDSA is selected. 589 The public key is public information and is conveyed in the 590 ServerCertificate message. 592 REQ16: The Content Provider MUST NOT share the private RSA DSS or 593 ECDSA key with the Edge Server. The private key is associated 594 to the Content Provider and SHOULD be kept in a secure place. 596 The DSA, RSA or ECDSA private key is necessary to the Edge Server to 597 sign the DH or ECDH parameters sent by the Edge Servers to the TLS 598 Clients. These operations can only be performed by the owner of the 599 private key, that is in our case the Content Provider. Thus, the 600 requirements regarding interactions between the Content Provider and 601 the Edge Server are: 603 REQ17: The Content Provider MUST provide DSS, RSA or ECDSA signing 604 facilities to the Edge Servers. The Edge Server SHOULD be 605 able to provide the extended parameters to be signed (that is 606 the signed_params ClientHello.random, ServerHello.random and 607 ServerKeyExchange.params) or their hash - as well as 608 additional necessary parameters - and be returned the signed 609 value so the Edge Server can send the ServerKeyExchange 610 message to the TLS Client and the TLS Client. 612 [DISCUSSION: the DHE_DSS / DH_DSS are mentioned for TLS1.2 but do not 613 seems to have specific actions associated to. I expected similar 614 behavior for dhe_dss as for dhe_rsa, but section A.4.2. "Server 615 Authentication and Key Exchange Messages" specifies no specific 616 payload when dhe_dss is selected. I would like to clarify how 617 DHE_DSS should be considered.] 619 4.4.3. Security Analysis 621 This section provides a security analysis of the split authentication 622 model versus the standard TLS authentication model with DHE_DSS, 623 DHE_RSA, ECDHE_RSA, ECDHE_ECDSA used as an authentication method. 624 The purpose of this section is to show that the Content Provider in 625 the split authentication model does not leak more information on its 626 secret credential than the TLS Server does in the standard TLS model. 628 The Content provider is expected to provide some signatures 629 associated to a given clear text. Such information provided by the 630 Content Provider to the Edge Server and the TLS Client in the split 631 authentication model are exactly the same information provided by the 632 TLS Server to the TLS Client in the standard TLS authentication 633 model. 635 The main difference between the two models is that the Content 636 Provider does not have any means to check whether the corresponding 637 signature effectively result in a running session or is part of an 638 attack. In order to mitigate the surface of such attacks: 640 REQ18: Signature scheme and associated parameters MUST be chosen to 641 be resistant to adaptive chosen cleartext attacks, i.e. the 642 computation of signatures MUST NOT reveal information of the 643 private key during the lifetime of the private key. 645 REQ19: The Edge Server SHOULD provide the complete clear text instead 646 of the hash to be signed. In fact, providing the complete 647 clear text provide the opportunity of the Content Provider to 648 check what is being signed. With secure signature scheme it 649 is believe that a collision with another clear text content 650 has a very low probability. On the other hand, if the Edge 651 Server simply provides the hash of the clear text, the Content 652 Provider does not have any means to check what it is signing. 653 In this case, the Content Provider relies on the Edge Server 654 to provide appropriated content and legitimated content, which 655 implies a strong trust relationship between the Content 656 Provider and the Edge Server. 658 The Edge Server can provide the complete cleartext or a hash of the 659 cleartext. An attacker may want to usurpate the Content Provider's 660 identity and provides content associated with the signature of the 661 content provider. In this case, the attacker may generate the 662 malicious content and hash it. By submitting the hash to the Content 663 Provider for signing, the Content Provider has no ways to check the 664 content that is expected to be signed by the Content Provider. In 665 other words, when hashes are submitted for signing, the content check 666 and validation is expected to be left to the Edge Server. On the 667 other hand, when the whole content is provided to the Content 668 Provider, the Content Provider is able to approve the content before 669 signing it. In this case, the Edge Server is not assigned the role 670 of checking the content. Instead, this role is left to the Content 671 Provider, thus limiting the trust in the Edge Server. This limits 672 the surface of attacks. 674 When the Edge Server provides the complete content to the Content 675 Provider, an attacker that wants to usurpate the Content Provider's 676 identity has the following possibilities: 678 a) It can provide a malicious content that is not detected as 679 malicious by the Content Provider, and so get signed by the 680 Content Provider. In order to address such vector of attack, the 681 Content Provider should be provided some means to control the 682 content that are signed. Otherwise, this function is delegated 683 to the Edge Server, and the model implies the Edge Server is a 684 trusted entity. When the clear text is provide instead of hash, 685 the Content Provider has means to check the content its signs. 686 On the other hand the Content Provider cannot check the signed 687 clear text corresponds to an effective and legitimate TLS 688 session. 690 b) It can generate the malicious content such that its hash matches 691 an already known hash. Such attack is known as a hash collision. 692 To address this vector of attack, the hash function is expected 693 to be resistant to pre-image, second pre-image and collision 694 attack. 696 c) It can guess the signature given the corresponding between 697 cleartext and their corresponding signatures. In order to 698 address this vector of attack, the signature is expected to be 699 resistant to the adaptive chosen message attack. 701 Only a) is introduced by the split model. In fact, in the TLS model, 702 the TLS Server signs content it generates and so assumes it is 703 legitimate. As explained, this is not anymore always true in the 704 split model where the Content Provider is not supposed to trust the 705 Edge Server. Vector of attack mentioned in b) and c) are common in 706 the split model and the standard TLS model, as an Edge Server in the 707 split model does not have any additional information than a TLS 708 Client in the TLS model. As a result: 710 REQ20: The Content Provider MUST be able to sign cleartext content 711 rather than the resulting hash. In addition, the Content 712 Provider MUST verify the cleartext content provided as input 713 to avoid signature usurpation. 715 REQ21: The Content Provider SHOULD enable hash signature. When the 716 Content Provider chose to sign hashes, the Edge Server MUST be 717 a trusted node. 719 The signature is not expected to be secret. As a result, the 720 information exchanged between the Content Provider and the Edge 721 Server does not require confidentiality. In addition, the 722 information provided to the Content Provider is not protected so 723 confidentiality is not mandatory. On the other hand, it is of 724 primary importance that only the legitimate Edge Server have access 725 to the signing service. 727 REQ22: The communication between the Edge Server and the Content 728 Provider MUST be authenticated. 730 As a result, the split authentication model is not expected to leak 731 more information than the standard TLS authentication model. 733 4.5. PSK, DHE_PSK, RSA_PSK 735 4.5.1. Standard TLS Authentication Description 737 When PSK, DHE_PSK or RSA_PSK [RFC4279] are selected by the TLS Server 738 for authentication, the TLS Server sends the TLS Client 739 ServerKeyExchange message with a psk_identity_hint to indicate the 740 TLS Client the PSK to select. When PSK has been selected, no 741 additional information is provided by the TLS Server. When DHE_PSK 742 is selected, the TLS Server adds the ServerDHParams to the 743 ServerKeyExchange. When RSA_PSK is selected, the TLS Server provides 744 the RSA public key of the TLS Server in a ServerCertificate message. 745 The key will be used for encryption. 747 Upon receipt of the ServerKeyExchange message, the TLS Client 748 responds with a ClientKeyExchange that contains the psk_identity. 749 When PSK has been selected, no additional information is provided. 750 The premaster includes the PSK designated by the psk_identity, and 751 TLS session keys are derived based on the shared secret. In case the 752 PSK is not known by both the TLS Client and the TLS Server, the 753 premaster will not be agreed upon. 755 When DHE_PSK is selected, in addition to the psk_identity, the TLS 756 Client provides the DH parameters in a ClientDiffieHellmanPublic 757 structure that is added to the ClientKeyExchange message. The 758 premaster is derived by the TLS Client and the TLS Server and 759 includes both the DH shared secret as well as the PSK itself. Only 760 if the TLS Server and the TLS Client share the same PSK, the 761 premaster is not agreed upon. 763 When RSA_PSK is selected, in addition to the psk_identity, the TLS 764 Client provides and EncryptedPreMasterSecret structure conveyed by 765 the ClientKeyExchange message. The EncryptedPreMasterSecret contains 766 among other informations a 46-byte random value and the PSK. When 767 receiving this message, the TLS Server decrypts the premaster and 768 check the validity between the PSK and the claimed psk_identity 769 before the premaster is agreed. 771 To sum up PSK DHE_PSK key exchange methods requires up to five 772 messages to be exchanged: ServerKeyExchange and ClientKeyExchange. 773 RSA_PSK requires the TLS Server to provide an additional 774 ServerCertificate. 776 4.5.2. Split Authentication Model 778 This section lists the requirements to use the PSK, RSA_PSK or the 779 DHE_PSK authentication in a split authentication model. The 780 requirements regarding the credential information shared between the 781 Content Provider and the Edge Server are: 783 REQ23: The Content Provider MAY share the psk_identity_hints and 784 associated profile with the Edge Servers. This information 785 may be shared after an evaluation that they are public 786 information and that profiles do not leak confidential, 787 critical or privacy related information. In addition the 788 Content Provider must also evaluate how the distribution of 789 the hints profiles may be distributed and updated on the Edge 790 Servers. Hints is definitely public as opposed to the PSK 791 that is secret, so the list of psk_identity_hints associated 792 to profiles may be provided to the Edge Servers. On the other 793 hand, there might be privacy issues related to providing a 794 complete list of hints, as well as management issues 795 associated to maintaining up-to-date lists between multiple 796 Edge Servers. 798 REQ24: The Content Provider SHOULD be able to provide 799 psk_identity_hints on a per request basis. More especially, 800 the Edge Server SHOULD be able to send a ClientHello message 801 or specific parameters to the Content Provider in order to get 802 the corresponding psk_identity_hint. Such interaction is 803 necessary when privacy and management issues may require the 804 profiles and psk_identity_hints be kept in a safe and 805 centralized place. 807 REQ25: The Content Provider MUST NOT share the PSK with the Edge 808 Server. The PSK is associated to the Content Provider and 809 MUST be kept in a secure place. 811 When PSK is selected, the requirements regarding interactions between 812 the Content Provider and the Edge Server are: 814 REQ26: The Content Provider SHOULD provide the Edge Server master 815 secret generation from the psk_identity as well as additional 816 information. As the premaster conveys the PSK in cleartext, 817 the Content Provider MUST NOT provide the cleartext premaster, 818 but instead should compute the master in order to avoid 819 transmitting the PSK to the Edge Server. 821 When PSK_RSA is selected, the requirements regarding interactions 822 between the Content Provider and the Edge Server are similar as those 823 to the RSA case except that the PSK SHOULD NOT be returned by the 824 Content Provider. More especially: 826 REQ27: The Content Provider SHOULD share the RSA public key with the 827 Edge Server. The RSA public key is public information and is 828 conveyed in the ServerCertificate message. 830 REQ28: The Content Provider MUST NOT share the private RSA key with 831 the Edge Server. The RSA private key is associated to the 832 Content Provider and SHOULD be kept in a secure place. 834 REQ29: The Content Provider MUST provide RSA decryption facilities to 835 the Edge Servers. The Edge Server SHOULD be able to provide 836 the EncryptedPremasterSecret - as well as additional necessary 837 parameters - and be returned the clear master so the Edge 838 Server and the TLS Client can agree and set the TLS channel. 839 As the premaster conveys the PSK in cleartext, the Content 840 Provider MUST NOT provide the cleartext premaster, but instead 841 should compute the master in order to avoid transmitting the 842 PSK to the Edge Server. 844 When DHE_PSK is selected, the DH exchange may be performed by the 845 Edge Server or by the Content Provider. When the DH exchange is 846 performed between the Edge Server and the TLS Client, the Edge Server 847 needs to provide the DH share secret - and the psk_identity - to the 848 Content Provider which in turn generates the master secret with its 849 PSK. Note that performing the DH with the Edge Server requires the 850 Edge Server to provide a Certificate with a public key signed by a CA 851 trusted by the TLS Client. This key may also be associated to the 852 Content provider URL. When the exchange is performed between the 853 Content Provider and the TLS Client, the agreed DH shared secret as 854 well as the PSK are only known by the Content Provider, which limits 855 the possibilities for the Edge Server to guess the PSK for example. 857 When the DH exchange is performed by the Edge Server and the TLS 858 Client, the requirements regarding interactions between the Content 859 Provider and the Edge Server are: 861 REQ30: The Content Provider MUST be able to generate a master from 862 the shared secret agreed between the Edge Server and the TLS 863 Client and the psk_identity provided by the TLS Client. 865 REQ31: As the premaster conveys the PSK in cleartext, the Content 866 Provider MUST NOT provide the cleartext premaster, but instead 867 should compute the master in order to avoid transmitting the 868 PSK to the Edge Server. This requirement assumes that the 869 Edge Server is performing the DH exchange. 871 When the DH exchange is performed between the Content Provider and 872 the TLS Client, the requirements regarding interactions between the 873 Content Provider and the Edge Server are: 875 REQ32: The Content Provider SHOULD share the private DH key with the 876 Edge Server. These DHParams will be sent to the TLS Client by 877 the Edge Server in the ServerKeyExchange message. 879 REQ33: The Content Provider SHOULD be able to generate a master from 880 the psk_identity and TLS Client DHParams - in addition to 881 potential additional parameters. As the premaster conveys the 882 PSK in clear, the Content Provider MUST NOT provide the 883 cleartext premaster, but instead should compute the master in 884 order to avoid transmitting the PSK to the Edge Server. 886 4.5.3. Security Analysis 888 This section compares the PSK, DHE_PSK, RSA_PSK authentication method 889 as described in [RFC4279] in a standard TLS model to the split model 890 described in this document - that is when it is split between the 891 Edge Server and the Content Provider. The main question considered 892 is how the split model exposes the authentication credential compared 893 to the standard TLS model described in [RFC5246]. 895 All PSK, DHE_PSK, RSA_PSK assumes the PSK owned by the Content 896 Provider MUST NOT be provided to the Edge Server. The difference 897 between the split authentication model and the standard TLS 898 authentication model is that in the standard TLS model, the TLS 899 Server owns the PSK and derives the master secret from the PSK. On 900 the other hand, the split authentication model assumes that the Edge 901 Server is not aware of the PSK while being aware of the master 902 secret. The difference is that the TLS standard model assumes all 903 parties (TLS Server and TLS Client) share the PSK, whether the split 904 model assumes the PSK is not shared between all parties. As a 905 result, the PSK leakage analysis is out of scope of the standard TLS 906 model and is specific to the split model. 908 The PSK is used to generate the master secret using a hash function. 909 The leakage of the PSK information in the master depends on the 910 hashing function and its collision free properties. [RFC4279]. As a 911 result, we can assume that the master secret does not leak 912 information about the premaster to the Edge Server. 914 For PSK_RSA, the authentication credential of the Content provider 915 are a RSA key and a PSK. Section 4.1 addresses the requirements 916 associated to the leakage of the RSA credential. Similarly to the 917 RSA analyzed in Section 4.1.3: 919 REQ34: RSA parameters MUST be chosen to make cipher text attack 920 infeasible. 922 For DHE_PSK, the DH exchange may be performed between the TLS Client 923 and the Content Provider or between the TLS Client and the Edge 924 Server. When the DH exchange is performed between the TLS Client and 925 the Content provider, the Content Provider provides the public key 926 used to sign the DHparams structure. In this case the analysis is 927 similar to Section 4.4. When the DH exchange is performed between 928 the Edge Server and the TLS Client, the Content Provider does not 929 share any additional authentication credentials. Similarly to DH / 930 ECDH: 932 REQ35: DH parameters MUST be chosen to make guessing attacks 933 infeasible. 935 In order to protect the TLS session between the TLS Client and the 936 Edge Server, the master secret or the premaster secret must not be 937 disclosed. Follows the security requirements on the Content Provider 938 / Edge Server channel: 940 REQ36: The communication between the Edge Server and the Content 941 Provider MUST be authenticated and encrypted. 943 As a result, the split authentication model is not expected to leak 944 more information than the standard TLS authentication model. 946 4.6. Client Hash and Signature 948 These are provided in the SignatureAndHash which is an Hello 949 Extension. As detailed in [RFC5246], if this extension has not been 950 provided, and rsa has been chosen as KeyExchangeAlgorithm, than the 951 server behaves as if the TLS Client had provided sha1 for the hash 952 function and rsa for the supported signatures. If the TLS Client 953 does not support sha1, than it has to use the extension to indicate 954 it. 956 5. Security Considerations 958 The scope of this document is to avoid that secret information 959 information associated to authentication credentials is spread over 960 multiple Edge Servers. Such models would assume that all Edge Server 961 remain trusted and reliable over time while being exposed on the 962 Internet. Instead the secret information is kept in one secured 963 place own by the Content Provider. Authentication of the Content 964 Provider by the TLS Clients is performed through the Edge Servers. 965 Such model designated in this document as the split model requires 966 some interactions between the Edge Servers and the Content Provider. 967 This document described what are the necessary interactions between 968 the Edge Servers and the Content Provider as well as the information 969 that can be shared between the Edge Servers and the Content Provider 970 and the information that must not be shared and that must remain 971 secret. These interactions as well as the shared and non shared 972 information do not expose the split model to additional risks of 973 secret leakages than in the standard TLS model. 975 The security associated to the authentication relies on the 976 authentication protocols defined in [RFC5246], [RFC4279] and 977 [RFC4492] and practices provided by [RFC7525]. As a result, security 978 consideration of these document apply. 980 6. IANA Considerations 982 There is no IANA considerations in this document. 984 7. Acknowledgements 986 8. References 988 8.1. Normative References 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 992 RFC2119, March 1997, 993 . 995 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 996 Ciphersuites for Transport Layer Security (TLS)", RFC 997 4279, DOI 10.17487/RFC4279, December 2005, 998 . 1000 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1001 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1002 RFC5246, August 2008, 1003 . 1005 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1006 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1007 January 2012, . 1009 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1010 "Recommendations for Secure Use of Transport Layer 1011 Security (TLS) and Datagram Transport Layer Security 1012 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1013 2015, . 1015 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1016 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1017 Session Hash and Extended Master Secret Extension", RFC 1018 7627, DOI 10.17487/RFC7627, September 2015, 1019 . 1021 8.2. Informative References 1023 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1024 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1025 for Transport Layer Security (TLS)", RFC 4492, DOI 1026 10.17487/RFC4492, May 2006, 1027 . 1029 Authors' Addresses 1031 Daniel Migault 1032 Ericsson 1033 8400 boulevard Decarie 1034 Montreal, QC H4P 2N2 1035 Canada 1037 Phone: +1 514-452-2160 1038 Email: daniel.migault@ericsson.com 1039 Kevin Ma J 1040 Ericsson 1041 43 Nagog Park 1042 Acton, MA 01720 1043 USA 1045 Phone: +1 978-844-5100 1046 Email: kevin.j.ma@ericsson.com