idnits 2.17.1 draft-mglt-lurk-tls-abstract-api-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 : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 188: '... returned it SHOULD provide some ind...' RFC 2119 keyword, line 542: '... version and MUST be the same value ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2016) is 2960 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'PreMaster' is mentioned on line 169, but not defined == Missing Reference: 'Master' is mentioned on line 169, but not defined == Missing Reference: 'Signature' is mentioned on line 169, but not defined == Missing Reference: 'Error' is mentioned on line 169, but not defined -- Looks like a reference, but probably isn't: '46' on line 588 ** Obsolete normative reference: RFC 2546 (Obsoleted by RFC 2772) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 8 errors (**), 0 flaws (~~), 5 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 Ericsson 4 Intended status: Standards Track February 19, 2016 5 Expires: August 22, 2016 7 TLS/DTLS Content Provider Edge Server Abstract API 8 draft-mglt-lurk-tls-abstract-api-00 10 Abstract 12 This document describes the interactions between the Edge Server and 13 the Content Provider in a split authentication scenario. 15 This document provides an abstract description of the information 16 exchanged between an Edge Server and a Content Provider. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 22, 2016. 35 Copyright Notice 37 Copyright (c) 2016 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 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Premaster Computation . . . . . . . . . . . . . . . . . . 5 56 3.2. Master Computation . . . . . . . . . . . . . . . . . . . 6 57 3.3. Signature Computation . . . . . . . . . . . . . . . . . . 8 58 4. Input Parameters Description . . . . . . . . . . . . . . . . 9 59 4.1. Static parameters . . . . . . . . . . . . . . . . . . . . 10 60 4.1.1. API Version . . . . . . . . . . . . . . . . . . . . . 10 61 4.1.2. TLSVersion . . . . . . . . . . . . . . . . . . . . . 10 62 4.1.3. ObjectRequest . . . . . . . . . . . . . . . . . . . . 10 63 4.1.4. AuthenticationMethod . . . . . . . . . . . . . . . . 10 64 4.1.5. MasterMethod . . . . . . . . . . . . . . . . . . . . 10 65 4.1.6. SignatureMethod . . . . . . . . . . . . . . . . . . . 10 66 4.1.7. PRF . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.2. TLS Hanshake parameters . . . . . . . . . . . . . . . . . 11 68 4.2.1. ClientHello.random, ClientServer.random . . . . . . . 11 69 4.2.2. session_hash, DataHash . . . . . . . . . . . . . . . 11 70 4.2.3. handshake_messages . . . . . . . . . . . . . . . . . 11 71 4.2.4. PSK_ID . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.3. Cryptographic Parameters . . . . . . . . . . . . . . . . 11 73 4.3.1. RSAEncryptedPreMaster . . . . . . . . . . . . . . . . 11 74 4.3.2. DHECDHTLSClientPublicDHECDHKey . . . . . . . . . . . 13 75 4.3.3. TLSClientEdgeServerDHSecret . . . . . . . . . . . . . 13 76 4.3.4. TLSClientEdgeServerDHECDHSecret . . . . . . . . . . . 13 77 5. Output Parameters Description . . . . . . . . . . . . . . . . 13 78 5.1. Premaster . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.3. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 This document assumes a TLS session is established between a TLS 89 Client authenticates a Content Provider while being connected with an 90 TLS Edge Server. 92 The architecture is defined more in details in [draft-cairns-tls- 93 session-key-interface], and the split authentication models are 94 described in [draft-mglt-tls-lurk-requirements]. 96 Motivation for providing an abstract API is to to provide a reference 97 that may be implemented in various ways. As a result, this document 98 does not consider the names of the procedures, their implementations, 99 nor how the informations are exchanged between the Edge Server and 100 the Content Provider. This document only describes the information 101 exchanged between the Edge Server and the Content Provider and the 102 associated treatment or verifications that may apply. 104 2. Terminology 106 3. Protocol Overview 108 In a split authentication scenario, the Edge Server and the Content 109 Provider needs to interact in order to set up the TLS/DTLS session 110 between the TLS Client and the Edge Server while the TLS Client 111 authenticates the Content Provider. 113 The current document considers the following authentication methods: 114 dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss and dh_rsa described in 115 [RFC6347], ecdh_ecdsa, ecdhe_ecdsa, ecdh_rsa, ecdhe_rsa and ecdh_anon 116 described in [RFC4492] as well as psk, dhe_psk and rsa_psk that are 117 described in [RFC4279]. These authentication methods are designated 118 in this document by the AuthenticationMethod variable. 120 AuthenticationMethod = [rsa, dh_dss, dh_rsa, dh_dss, dh_rsa, 121 ecdh_rsa, dh_anon, ecdh_anon, dhe_dss, 122 dhe_rsa, ecdhe_ecdsa, ecdhe_rsa, psk, 123 dhe_psk, rsa_psk] 125 AuthenticationMethod 127 The interactions between the Edge Server and the Content Provider 128 depend on the authentication method. First of all, the object 129 request, designated in this document as ObjectRequest, depends on the 130 authentication method. When the authentication methods is one of 131 rsa, dh_dss, dh_rsa rsa, dh_dss, dh_rsa, ecdh_rsa, the Content 132 Provider is likely to be requested by the Edge Server a premaster 133 secret or a master secret. When the authentication method is an 134 ephemeral Diffie Hellman or ephemeral Elliptic Diffie Hellman 135 authentication methods like dhe_dss, dhe_rsa, ecdhe_ecdsa, ecdhe_rsa, 136 the Content Provider is likely to be requested a signature. When the 137 authentication method is an anonymous authentication method like 138 dh_anon, ecdh_anon no interactions are expected from the Content 139 Provider and the Edge Server. Finally, when the authentication 140 method is PSK based, the Content provider is likely to be requested a 141 master secret but not the premaster secret as the premaster contains 142 the PSK in clear text. 144 Second, the object of the request like a master secret or the 145 signature may be generated with different inputs. For example, a 146 signature or a master secret may use the hash of some clear text. 147 The different inputs provided by the Edge Server are designated as 148 InputParameters. 150 Finally, the Content provider may have its own policies regarding the 151 TLS version, the authentication methods, the object request as well 152 as the associated inputs. This means that the Content Provider may 153 refuse some request defined in this document based on its own 154 policies. This should be indicated in an error message by the 155 Content provider in its response. 157 As a result, the basic scheme considered for this API adopts a Query 158 / Response pattern. The Query message provides all necessary 159 information for the Content Provider, to proceed to the Query, and 160 send the output result in the Response. 162 Query: 163 APIVersion = 1.0 164 TLSVersion = [1.2, 1.3] 165 ObjectRequest = [premaster, master, signature] 166 InputParameters 168 Response: 169 Output [PreMaster, Master, Signature, Error] 171 API Query / Response 173 The Query is associated with the following parameters: 175 (a) APIVersion: which designates the version of the API used. The 176 version is expected to be useful when the authentication methods 177 or TLS version will be added. 178 (b) TLSVersion: the associated version of the TLS. 179 (c) ObjectRequest: the requested output. Currently the requested 180 output can be one of the following: pre_master, master, 181 signature. 182 (d) InputParameters: the parameters provided by the Edge Server in 183 order to compute the ObjectRequest. These InputParameters will 184 be defined in the remaining of the document, and are very 185 specific to each Query. 187 The Response returns the ObjectRequest or an Error. When an Error is 188 returned it SHOULD provide some indication why the request have not 189 been proceeded. Note that the types of errors are: 191 (a) Input Format Parameter Errors: that is errors associated to the 192 format of a given parameter. For example a TLS version that is 193 out of bound, or a Client,random that does not have the expected 194 size would trigger such an error. 195 (b) Input Parameters Incompatibility Error: that is a combination of 196 input parameters that is not acceptable on a standard point of 197 view. This could be for example requesting a signature with an 198 authentication method that is expected to provide a master 199 secret. 200 (c) Not Permitted Input Parameters Error: that is a combination of 201 parameters that is either not accepted by the Content Provider, 202 or not implemented by the API. For example, the Content 203 Provider may only generate signature from the complete clear 204 text and refuse to generate it simply based on the hash of the 205 content. 207 InpuParameters depends on the ObjectRequest value, so the 208 InputParameters can be: 210 (a) PremasterInputParams: when the query requests a premaster, that 211 is ObjectRequest is set to premaster. 212 (b) MasterInputParams: when the query requests a master secret, that 213 is ObjectRequest is set to master. 214 (c) SignatureInputParams: when the query requests a signature, that 215 is the ObjectRequest is set to signature. 217 InputParameters: 218 select(ObjectRequest) 219 case pre_master: 220 PremasterInputParams 221 case master: 222 MasterInputParams 223 case signature: 224 SignatureInputParams 226 InpuParameters 228 3.1. Premaster Computation 230 A premaster may be requested only for a subset of authentication 231 methods, that is RSA and non anonymous Diffie Helmman based methods. 232 In the case of RSA, the encrypted premaster is provided whereas 233 Diffie Hellman based authentication provides the TLS Client public 234 key. 236 When another authentication method is associated to the premaster 237 request an Input Parameters Incompatibility Error must be sent 238 indicating that the authentication method is not compatible with the 239 premaster request. 241 (a) INCOMPATIBLE_INPUT_PARAMETERS_ERROR 243 In order to indicate the error is associated to the authentication 244 method the two following error message are added. Note that an 245 unacceptable error may occur when there is a incompatibility between 246 the parameters. This can occur due to local policies or due to an 247 incompatibility with the specification. It is the responsibility of 248 the Edge Server to implement the specification properly, and thus to 249 receive the error only when it results from a local policy. 251 AUTHENTICATION_METHOD_UNACCEPTABLE_ERROR 253 The description of the input parameters are provide by the figure 254 below: 256 PreMasterInputParams 257 - AuthenticationMethod 258 - PreMasterInputData 260 PreMasterInputData: 261 select(AuthenticationMethod) 262 case rsa: 263 RSAEncryptedPreMaster 264 case dh_dss, dh_rsa, dh_dss, dh_rsa, ecdh_rsa: 265 DHECDHTLSClientPublicDHECDHKey 266 case dhe_dss, dhe_rsa, ecdhe_ecdsa, 267 ecdhe_rsa, psk, dhe_psk and rsa_psk: 268 /* Input Parameters Incompatibility Error 269 INCOMPATIBLE_INPUT_PARAMETERS_ERROR 270 AUTHENTICATION_METHOD_UNACCEPTABLE_ERROR 271 is generated 272 */ 274 PreMasterInputParams 276 3.2. Master Computation 278 The computation of a master secret needs more information than the 279 computation of the premaster. Similarly to the premaster generation, 280 generation of a master secret is reserved to a subset of 281 authentication methods. Note that the PSK based authentication 282 methods are able to generate master secret but not to generate 283 premaster. The reason is that the premaster embeds the PSK in clear 284 text. 286 Similarly to the premaster generation, when an authentication method 287 is not permitted an Input Parameters Incompatibility Error 288 INCOMPATIBLE_INPUT_PARAMETERS_ERROR with and 289 AUTHENTICATION_METHOD_UNACCEPTABLE_ERROR are returned. 291 As premaster are used to compute the master, when a authentication 292 method enable the generation of the premaster the same input 293 parameters must be also provided to the Content Provider. 295 Master secret may be generated using different methods and using 296 different inputs. More specifically, the extended master secret may 297 be generated from the hash of the exchange messages, or the exchange 298 message themselves. The figure below represent a method by the type 299 of the master secret (that is the standard master secret or the 300 extended master secret) as well as the expected inputs. Such 301 representation is not normative and provided for illustration. As a 302 result, alternative representation may be used. 304 MasterInputParams 305 AuthenticationMethod 306 MasterMethod = [standard_master, 307 extended_master_from_session_hash, 308 extended_master_method_from_handshake_messages] 309 MasterInputData 311 MasterInputData 312 select(AuthenticationMethod) 313 case rsa: 314 MasterMethodParams 315 RSAEncryptedPreMaster 316 case dh-scdh: 317 MasterMethodParams 318 DHECDHTLSClientPublicDHECDHKey 319 case dhe_dss, dhe_rsa, ecdhe_ecdsa, dh_anon, ecdh_anon 320 ecdhe_rsa, psk 321 /* Input Parameters Incompatibility Error 322 INCOMPATIBLE_INPUT_PARAMETERS_ERROR 323 AUTHENTICATION_METHOD_UNACCEPTABLE_ERROR 324 is generated 325 */ 326 case psk, dhe_psk, rsa_psk: 327 PSKInputData 329 MasterMethodParams 330 select(MasterMethod) 331 case standard_master: 332 - ClientHello.random 333 - ClientServer.random 334 - PRF 335 case extended_master_from_session_hash 336 - session_hash 337 - PRF 338 case extended_master_method_from_handshake_messages 339 - handshake_messages 340 - PRF 342 PSKInputData 343 select(PSKSubAuthenticationMethod) 344 case psk: 345 - PSK_ID 346 case PSK_rsa: 347 - RSAEncryptedPreMaster 348 case psk_dhe: 349 - TLSClientEdgeServerDHSecret 350 - PSK_ID 352 MasterInputParams 354 3.3. Signature Computation 356 Similarly to the generation of the premaster and the generation of 357 the master, the signature is associated to restricted subset of 358 authentication methods, i.e. dhe_dss, dhe_rsa, ecdhe_ecdsa ecdhe_rsa. 359 When another authentication method is chosen an Input Parameters 360 Incompatibility Error INCOMPATIBLE_INPUT_PARAMETERS_ERROR with an 361 AUTHENTICATION_METHOD_UNACCEPTABLE_ERROR are returned. 363 Similarly to the generation of the master, different method may be 364 used to generate the signature and different parameters may be needed 365 to generate the signature. In some case, the hash is provided 366 whereas in some other case, the whole content to sign is provided. 368 The figure below provides a representation of the possible parameters 369 provided by the Edge Server. 371 SignatureInputParams 372 AuthenticationMethod 373 SignatureMethod = (CryptoAlgo = [dss, rsa, ecdsa], 374 DataType = [hash, content]) 375 SignatureInputData 377 SignatureInputData 378 select(AuthenticationMethod) 379 case dhe_dss, dhe_rsa, ecdhe_ecdsa ecdhe_rsa: 380 SignatureInputData 381 case rsa, dh_dss, dh_rsa, dh_dss, dh_rsa, ecdh_rsa, dh_anon, 382 ecdh_anon, psk, dhe_psk, rsa_psk: 383 /* Input Parameters Incompatibility Error 384 INCOMPATIBLE_INPUT_PARAMETERS_ERROR 385 AUTHENTICATION_METHOD_UNACCEPTABLE_ERROR 386 is generated 387 */ 389 SignatureInput 390 select(SignatureMethod.DataType) 391 case hash: 392 - DataHash 393 case content: 394 - ClientHello.random 395 - ClientServer.random 396 - TLSClientEdgeServerDHECDHSecret 398 MasterInputParams 400 4. Input Parameters Description 402 This section lists the possible parameters exchanged between the Edge 403 Server and the Content Provider. For each parameters, this section 404 determine what checks and error may be associated to them and 405 communicated to the Edge Server. 407 In order to address the different errors, for each input, there is an 408 associated Input Format Parameter Errors that indicates the input 409 does not follow the format expected in this document. In addition, 410 there is an Not Permitted Input Parameters Error that indicates the 411 API does not support the provided input. This is mostly due to local 412 policies. In addition, the local policies may also prevent a given 413 input value in combination with other input values. In this case, 414 the error returned by the Content Provider is an Input Parameters 415 Incompatibility Error INCOMPATIBLE_INPUT_PARAMETERS_ERROR with the 416 Not Permitted Input Parameters Error associated to the conflicting 417 parameters. 419 4.1. Static parameters 421 4.1.1. API Version 423 The Input Format Parameter Errors associated to the API version 424 output are: 426 API_VERSION_FORMAT_ERROR 428 4.1.2. TLSVersion 430 The Input Format Parameter Errors and Not Permitted Input Parameters 431 Error associated to the TLS version output are: 433 TLS_VERSION_FORMAT_ERROR 434 TLS_VERSION_UNACCEPTABLE_ERROR 436 4.1.3. ObjectRequest 438 The Input Format Parameter Errors and Not Permitted Input Parameters 439 Error associated to the requested output are: 441 REQUEST_OUTPUT_FORMAT_ERROR 442 REQUEST_OUTPUT_UNACCEPTABLE_ERROR 444 4.1.4. AuthenticationMethod 446 The Input Format Parameter Errors and Not Permitted Input Parameters 447 Error associated to the authentication method are: 449 AUTHENTICATION_METHOD_FORMAT_ERROR 450 AUTHENTICATION_METHOD_UNACCEPTABLE_ERROR 452 4.1.5. MasterMethod 454 The Input Format Parameter Errors and Not Permitted Input Parameters 455 Error associated to the master methods are: 457 MASTER_METHOD_FORMAT_ERROR 458 MASTER_METHOD_UNACCEPTABLE_ERROR 460 4.1.6. SignatureMethod 462 The Input Format Parameter Errors and Not Permitted Input Parameters 463 Error associated to the signature method are: 465 SIGNATURE_METHOD_FORMAT_ERROR 466 SIGNATURE_METHOD_UNACCEPTABLE_ERROR 468 4.1.7. PRF 470 The Input Format Parameter Errors and Not Permitted Input Parameters 471 Error associated to the pseudo random function are: 473 PRF_FUNCTION_FORMAT_ERROR 474 PRF_FUNCTION_UNACCEPTABLE_ERROR 476 4.2. TLS Hanshake parameters 478 4.2.1. ClientHello.random, ClientServer.random 480 The Input Format Parameter Error associated to the ClientHello 481 randoms is: 483 CLIENT_RANDOM_FORMAT_ERROR (most likely a length different from 32 484 bytes) 486 4.2.2. session_hash, DataHash 488 The Input Format Parameter Error associated to the hash is: 490 HASH_FORMAT_ERROR (most likely an unexpected length) 492 4.2.3. handshake_messages 494 The Input Format Parameter Error associated to the hash is: 496 HANDSHAKE_MESAGE_FORMAT_ERROR 498 4.2.4. PSK_ID 500 The Not Input Parameter Error associated to the hash is: 502 PSK_ID_UNACCEPTABLE_ERROR (unkown PSK id) 504 4.3. Cryptographic Parameters 506 4.3.1. RSAEncryptedPreMaster 508 Encrypted RSA values are expected to follow the PKCS#1 format. Upon 509 receipt of the parameter, the Content Provider checks the format of 510 encrypted parameters. If an error is detected, the Content Provider 511 can either respond with a randomly generated pre_master or master or 512 return a Input Format Parameter Error. The random value will result 513 in an aborted session, and so motivation for providing a random value 514 is to prevent notifying the Edge Server a format error has been 515 detected. This behavior is recommended when the Content provider 516 does not trust the Edge Server or suspect it is under attack. On the 517 other hand, sending a error may also notify the Edge Server an attack 518 is being suspected, so mitigating mechanisms may be activated by the 519 Edge Server. In any case, if an format error is detected the error 520 returned by the Content Provider may be: 522 RSA_ENCRYPTED_FORMAT_ERROR 524 If the parameters ar enot expected, the Content Provider may provide 525 in addition to an INCOMPATIBLE_INPUT_PARAMETERS_ERROR the following 526 message: 528 RSA_ENCRYPTED_UNACCEPTABLE_ERROR 530 4.3.1.1. Checking RSA Encrypted Premaster Format 532 The first two bytes must be 00 02 followed by non zero padding until 533 a 00 byte is found, followed by the two byte for the TLS version and 534 finally the 46 bytes of the pre master secret. If the format is 535 appropriated the premaster is returned, otherwise an 536 ERROR_UNVALID_ENCRYPTED_MASTER is returned, or a randomly generated 537 Premaster Secret which will silently discard the TLS session - see 538 Section 7.4.7.1 of [RFC5246]. 540 As defined in section 8.1.1 [RFC2546], the pre_master is 48-byte 541 generated by the TLS Client. The two first bytes indicates the TLS 542 version and MUST be the same value as the one provided by the 543 ClientHello.client_version, and the remaining 46 bytes are expected 544 to be random. 546 The pre_master is encrypted with the public key of the TLS Server as 547 a EncryptedPreMasterSecret structure sent in the Client Key Exchange 548 Message as described in section 7.4.7.1 [RFC5246]. The encryption 549 follows for compatibility with previous TLS version RSAES-PKCS1-v1_5 550 scheme described in [RFC3447], which results in a 256 byte encrypted 551 message for a 2048-bit RSA key or 128 byte encrypted message for a 552 1024 bit RSA key. 554 <---------- 256 bytes ------------------------------> 555 <-- 205 bytes --> <- 48 bytes -> 556 <- TLS -> 557 version 558 +----+----+------------------+----+-----+-----+--------+ 559 | 00 | 02 | non-zero padding | 00 | maj | min | random | 560 +----+----+------------------+----+-----+-----+--------+ 562 PKCS#1 padding for pre_master secret encrypted with 2048-bit RSA key 564 4.3.2. DHECDHTLSClientPublicDHECDHKey 566 TBD 568 4.3.3. TLSClientEdgeServerDHSecret 570 TBD 572 4.3.4. TLSClientEdgeServerDHECDHSecret 574 TBD 576 5. Output Parameters Description 578 5.1. Premaster 580 The premaster and master are an opaque number bytes. premaster are 46 581 byte length and master are 48 byte length. 583 Note that the PreMasterSecret structure of [RFC5246] includes the 584 protocol version. 586 struct { 587 ProtocolVersion client_version; 588 opaque random[46]; 589 } PreMasterSecret; 591 PreMasterSecret Structure 593 5.2. Signature 595 In order to identify the signature, the signature structure should 596 have the signature algorithm, the hash algorithm and the value of the 597 signature. 599 5.3. Error 601 In this document, the Error message can carry various messages. More 602 specifically, when a query is not accepted because of incompatibility 603 of parameters provided, the Content provider returns 604 INCOMPATIBLE_INPUT_PARAMETERS_ERROR. In order to provide more 605 indication to the Edge Server additional message as the convicting 606 parameters may be added. 608 6. Security Considerations 610 7. Acknowledgements 612 8. References 614 [RFC2546] Durand, A. and B. Buclin, "6Bone Routing Practice", RFC 615 2546, DOI 10.17487/RFC2546, March 1999, 616 . 618 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 619 Standards (PKCS) #1: RSA Cryptography Specifications 620 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 621 2003, . 623 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 624 Ciphersuites for Transport Layer Security (TLS)", RFC 625 4279, DOI 10.17487/RFC4279, December 2005, 626 . 628 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 629 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 630 for Transport Layer Security (TLS)", RFC 4492, DOI 631 10.17487/RFC4492, May 2006, 632 . 634 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 635 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 636 RFC5246, August 2008, 637 . 639 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 640 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 641 January 2012, . 643 Author's Address 645 Daniel Migault 646 Ericsson 647 8400 boulevard Decarie 648 Montreal, QC H4P 2N2 649 Canada 651 Phone: +1 514-452-2160 652 Email: daniel.migault@ericsson.com