idnits 2.17.1 draft-mglt-lurk-tls12-03.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 361: '... the latter SHOULD happen over a sec...' RFC 2119 keyword, line 380: '... The server_random MUST follow the structure of [RFC5246] section...' RFC 2119 keyword, line 389: '... The operation MUST be performed by ...' RFC 2119 keyword, line 410: '... A LURK Client MAY use the rsa_maste...' RFC 2119 keyword, line 415: '... The LURK Client MUST ensure that the ...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 284 has weird spacing: '...rSecret pre_m...' == Line 297 has weird spacing: '...s_funct the o...' == Line 300 has weird spacing: '...rf_hash the o...' == Line 304 has weird spacing: '..._random the r...' == Line 325 has weird spacing: '...essages provi...' == (17 more instances...) -- The document date (July 03, 2020) is 1364 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) -- Looks like a reference, but probably isn't: '16' on line 557 -- Looks like a reference, but probably isn't: '32' on line 560 == Missing Reference: 'RFD-TBD' is mentioned on line 987, but not defined == Missing Reference: 'RFC-TBD-LURK' is mentioned on line 995, but not defined == Missing Reference: 'RFC-TBD' is mentioned on line 1021, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1294, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 8017 == Outdated reference: A later version (-01) exists of draft-mglt-lurk-lurk-00 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LURK D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track I. Boureanu 5 Expires: January 4, 2021 University of Surrey 6 July 03, 2020 8 LURK Extension version 1 for (D)TLS 1.2 Authentication 9 draft-mglt-lurk-tls12-03 11 Abstract 13 This document describes the LURK Extension 'tls12' which enables 14 interactions between a LURK Client and a LURK Server in a context of 15 authentication with (D)TLS 1.2. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 4, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 53 3. LURK Header . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. rsa_master, rsa_master_with_poh . . . . . . . . . . . . . . . 6 55 4.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 6 56 4.1.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . 8 57 4.2. Response Payload . . . . . . . . . . . . . . . . . . . . 9 58 4.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 10 59 4.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 10 60 5. rsa_extended_master, rss_extended_master_with_poh . . . . . . 11 61 5.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 11 62 5.2. Response Payload . . . . . . . . . . . . . . . . . . . . 12 63 5.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 12 64 5.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 12 65 6. ecdhe" . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 13 67 6.2. Response Payload . . . . . . . . . . . . . . . . . . . . 15 68 6.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 15 69 6.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 15 70 7. capabilities . . . . . . . . . . . . . . . . . . . . . . . . 16 71 7.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 16 72 7.2. Response Payload . . . . . . . . . . . . . . . . . . . . 16 73 7.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 18 74 7.4. LURK Server Behavior" . . . . . . . . . . . . . . . . . . 18 75 8. ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 8.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 18 77 8.2. Response Payload . . . . . . . . . . . . . . . . . . . . 18 78 8.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 18 79 8.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 19 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 9.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9.2. ECDHE . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 9.3. Perfect Foward Secrecy . . . . . . . . . . . . . . . . . 21 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 12. Apendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 12.1. LURK Exchange for TLS RSA Master Secret with Proof of 88 Handshake . . . . . . . . . . . . . . . . . . . . . . . 25 89 12.2. LURK Exchange for TLS RSA Extended Master Secret . . . . 26 90 12.3. LURK Exchange for TLS RSA Extended Master Secret with 91 proof of handshake . . . . . . . . . . . . . . . . . . . 28 92 12.4. LURK Exchange for TLS ECDHE Signature . . . . . . . . . 30 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 95 13.2. Informative References . . . . . . . . . . . . . . . . . 32 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 98 1. Introduction 100 This document describes the LURK Extension for TLS 1.2 so the LURK 101 Server can implement a Cryptographic Service in a TLS 1.2 [RFC5246] 102 and DTLS 1.2 [RFC6347] context. 104 More specifically, the LURK Server will be in charge of performing 105 the cryptographic operations associated to the private key of the TLS 106 Server, while other aspects of the termination of the TLS session is 107 handled by other services in the same administrative domain or in a 108 different administrative domain. Most Cryptographic Operations are 109 related to the TLS authentication and the current document limits the 110 Cryptographic Operations to the following authentication methods: RSA 111 and ECDHE_RSA defined in [RFC5246], [RFC6347] as well as ECDHE_ECDSA 112 defined in [RFC8422]. 114 A more detailed description of some use cases foreseen in a TLS 115 context can be found in [I-D.mglt-lurk-tls-use-cases]. 117 HTTPS delegation has been the main concern of the Content Delivery 118 Networks Interconnection (cdni) Working Group and several mechanisms 119 have been designed to delegate the load from an upstream entity to a 120 downstream entity. Entities can be of different nature and may 121 designated differently according to the context. Typically 122 designations includes Content Owner, CDN Provider, Domain Name Owner 123 for example. [I-D.fieau-cdni-https-delegation] provides a details 124 comparison of the various mechanisms applies to the CDN 125 Interconnection, and the remaining of this section positions these 126 mechanisms at a very high level view. 128 STAR [I-D.ietf-acme-star], [I-D.sheffer-acme-star-request] describes 129 a methods where the domain name owner or the content owner 130 orchestrates the refreshing process between a CA and the CDN 131 (terminating the TLS session). The CDN refreshes regularly and 132 automatically its certificates using [I-D.ietf-acme-acme], which 133 allows the use of short term certificates. 135 Delegated credentials [I-D.rescorla-tls-subcerts] consists having a 136 certificate that enables the servers to generates some "delegated 137 credentials". 139 STAR and "delegated credentials" both require some changes performed 140 by the CA - new certificate type for the delegated credentials and 141 new interfaces for the delegated and delegating entity for STAR. In 142 both case the TLS Client authenticates the delegated entity. While 143 STAR does not require changes on the TLS Client, the "delegated 144 credential" solution does. In both cases, the delegation is 145 controlled by limiting in time (7 days), which is also the limit of 146 use of a stolen key or a rogue server. Such delegation provides a 147 high scalability of the architecture and prevents additional delays 148 when a TLS session is established. 150 The LURK Architecture [I-D.mglt-lurk-lurk] and the LURK Extension 151 'tls12' do not proceed to the delegation of the HTTPS delegation by 152 delegating the entire TLS termination. Instead, the TLS termination 153 is split into sub services, for example one associated to the 154 networking part and one associated to the cryptographic operation. 155 While micro services associated to the networking part are delegated, 156 the micro service associated to the cryptographic operation may not 157 be delegated. As a result, LURK Architecture is focused on the 158 protection of the Cryptographic Material and prevents leakage of the 159 Cryptographic Material for example by avoiding node exposed to the 160 Internet to host the Cryptographic Material. In addition, LURK 161 provides means to instantaneously suspend the delegation with a 162 suspicious node. On the other hand the LURK Extension 'tls12' 163 introduces some latency, and is not as scalable as STAR or delegated 164 credential solutions. 166 The LURK Extension 'tls12' is seen as a complementary to the STAR and 167 "delegated credentials". The LURK Extension 'tls12' is a backend 168 solution that does not require any modifications from TLS Client or 169 the CA. It is also aimed at protecting the Cryptographic Material. 171 LURK may also be deployed within an administrative domain in order to 172 to provide a more controlled deployment of TLS Servers. 174 2. Terminology and Acronyms 176 This document re-uses the terminology defined in 177 [I-D.mglt-lurk-lurk]. 179 3. LURK Header 181 LURK / TLS 1.2 is a LURK Extension that introduces a new designation 182 "tls12". This document assumes that Extension is defined with 183 designation set to "tls12" and version set to 1. The LURK Extension 184 extends the LURKHeader structure defined in [I-D.mglt-lurk-lurk] as 185 follows: 187 enum { 188 tls12 (1), (255) 189 } Designation; 191 enum { 192 capabilities (0), ping (1), rsa_master (2), 193 rsa_master_with_poh (3), rsa_extended_master (4), 194 rsa_extended_master_with_poh (5), ecdhe (6), (255) 195 }TLS12Type; 197 enum { 198 // generic values reserved or aligned with the 199 // LURK Protocol 200 request (0), success (1), undefined_error (2), 201 invalid_payload_format (3), 203 // code points for rsa authentication 204 invalid_key_id_type (4), invalid_key_id (5), 205 invalid_tls_random (6), invalid_freshness_funct (7), 206 invalid_encrypted_premaster (8), invalid_finished (9) 208 //code points for ecdhe authentication 209 invalid_ec_type (10), invalid_ec_curve (11), 210 invalid_poo_prf (12), invalid_poo (13), (255) 211 }TLS12Status 213 struct { 214 Designation designation = "tls12"; 215 int8 version = 1; 216 } Extension; 218 struct { 219 Extension extension; 220 select( Extension ){ 221 case ("tls12", 1): 222 TLS12Type; 223 } type; 224 select( Extension ){ 225 case ("tls12", 1): 226 TLS12Status; 227 } status; 228 uint64 id; 229 unint32 length; 230 } LURKHeader; 232 4. rsa_master, rsa_master_with_poh 234 An exchange of type "rsa_master" or "rsa_master_with_poh" enables the 235 LURK Client to delegate the RSA Key Exchange and authentication as 236 defined in [RFC5246]. The LURK Server returns the master secret. 238 "rsa_master" provides the necessary parameters and details to 239 generate the master secret, as well as to hinder replaying of old 240 handshake messages by a corrupt LURK Client. I.e., some attestation 241 of message-freshness is acquired by the LURK Server. 243 In addition, the"rsa_master_with_poh" provides a proof of handshake 244 (PoH). The proof of handshake consists in providing the Finished 245 message of the TLS Client to the LURK Server, so that latter can 246 perform more checks that in the "rsa_master" mode. Notably, herein, 247 the LURK Server also checks that the LURK request is performed in a 248 context of a TLS handshake. 250 While "rsa_master" and "rsa_master_with_poh" exchange have 251 respectively different requests, the response is the same. The 252 motivation for having different type is that the parameters provided 253 to the LURK Server are provided using different format. "rsa_master" 254 provides them explicitly, while "rsa_master_with_poh" provides them 255 via handshake messages. 257 4.1. Request Payload 259 A rsa_master request payload has the following structure: 261 enum { 262 sha256_32 (0), (255) 263 }KeyPairIdType; 265 struct { 266 KeyPairIdType type; 267 opaque data; // length defined by the type 268 } KeyPairID; 270 enum{ 271 sha256 (0), (255) 272 } FreshnessFunct 274 enum{ 275 sha256 (0), sha384(1), sha512(2), (255) 276 } PRFHash 278 struct { 279 KeyPairID key_id; 280 FreshnessFunct freshness_funct; 281 PRFHash prf_hash; 282 Random client_random; // see RFC5246 section 7.4.1.2 283 Random server_random; 284 EncryptedPreMasterSecret pre_master; 285 // see RFC5246 section 7.4.7.1 286 // Length depends on the key. 287 } 288 } TLS12RSAMasterRequestPayload; 290 key_id The identifier of the public key. This document defines 291 sha256_32 format which takes the 32 first bits of the hash of the 292 binary ASN.1 DER representation of the public key using sha256. 293 The binary representation of RSA keys is described in [RFC8017]. 294 The binary representation of ECC keys is the subjectPublicKeyInfo 295 structure defined in [RFC5480]. 297 freshness_funct the one-way hash function (OWHF) used by LURK to 298 implement Perfect Forward Secrecy. 300 prf_hash the one way hash function used by the Pseudo Random 301 Function (PRF) to generate the master secret. PRF and hash 302 function are defined in {!RFC5246}} Section 5. 304 client_random the random value associated to the TLS Client as 305 defined in [RFC5246] Section 7.4.1.2. 307 server_random: the random value associated to the TLS Server as 308 defined in [RFC5246] Section 7.4.1.2. 310 EncryptedPreMasterSecret : The encrypted master secret as defined in 311 [RFC5246] Section 7.4.7.1. 313 A rsa_master_with_poh request payload has the following structure: 315 struct { 316 KeyPairID key_id; 317 FreshnessFunct freshness_funct; 318 opaque handshake_messages<2...2^16-2> 319 // see RFC5246 section 7.4.9 320 Finished finished 321 } TLS12RSAMasterWithPoHRequestPayload; 323 key_id, freshness_funct are defined above 325 handshake_messages provides the necessary handshake messages to 326 compute the Finished message of the TLS Client as defined in 327 [RFC5246] section 7.4.9. 329 finished the TLS Client Finished message as defined by {{!RFC5246} 330 section 7.4.9. 332 4.1.1. Perfect Forward Secrecy 334 This document defines a mechanism which uses a function called 335 freshness_funct, to prevent an attacker to send a request to the LURK 336 Server in such a way that the said attacker can obtain back the 337 mastersecret for an old handshake. In other words, the use of this 338 function helps prevent a forward-secrecy attack on an old TLS 339 session, where the attack would make use that session's handshake- 340 data observed by the adversary. 342 This design achieves PFS with freshness_funct being a collision- 343 resistant hash function (CHRF). By CRHF, we mean a one-way hash 344 function (OWHF) which also has collision resistance; the latter means 345 that it is computationally infeasible to find any two inputs x1 and 346 x2 such that freshness_funct(x1) = freshness_funct(x2). By one-way 347 hash function (OWHF) we mean, as standard, a hash function 348 freshness_funct that satisfies preimage resistance and 2nd-preimage 349 resistance. That is, given a hash value y, it is computationally 350 infeasible to find an x such that freshness_funct(x) = y, and 351 respectively- given a value x1 and its hash freshness_funct(x1), it 352 is computationally infeasible to find another x2 such that 353 freshness_funct(x2) = freshness_funct(x1). 355 For the concrete use of our freshness_funct funtions, let S be a 356 fresh, randomly picked value generated by the LURK Client. The value 357 of server_random in the TLS exchange is then equal to 358 freshness_funct(S), i.e., server_random=freshness_funct(S). Between 359 the TLS Client and the LURK Server only server-random is exchanged. 360 The LURK Client sends S to the Key Server, in the query. Note that 361 the latter SHOULD happen over a secure channel. 363 A man-in-the-middle attacker observing the (plaintext) TLS handshake 364 between a TLS Client and the LURK Client does not see S, but only 365 server_random. The preimage resistance guaranted by the 366 freshness_funct makes it such that this man-in-the-middle cannot 367 retrieve S out of the observed server-random. As such, this man-in- 368 the-middle attacker cannot query the S corresponding to an (old) 369 observed handshake to the Key Server. Moreover, the collision 370 resistance guaranteed by the freshness_funct makes it such that if 371 the aforementioned man-in-the-middle cannot find S' such that 372 freshness_funct(S)=freshness_funct(S'). 374 As discussed in Section 9, PFS may be achieved in other ways (i.e., 375 not using a CRHF and the aforementioned exchanges but other 376 cryptographic primitives and other exchanges). These may offer 377 better computational efficiency. These may be standardized in future 378 versions of the LURK extension "tls12. 380 The server_random MUST follow the structure of [RFC5246] section 381 7.4.1.2, which carries the gmt_unix_time in the first four bytes. 382 So, the ServerHello.random of the TLS exchange is derived from the 383 server_random of the LURK exchange as defined below: 385 gmt_unix_time = server_random[0..3]; 386 ServerHello.random = freshness_funct( server_random + "tls12 pfs" ); 387 ServerHello.random[0..3] = gmt_unix_time; 389 The operation MUST be performed by the LURK Server as well as the TLS 390 Server, upon receiving the master secret or the signature of the 391 ecdhe_params from the LURK Client. 393 4.2. Response Payload 395 The "rsa_master" response payload contains the master secret and has 396 the following structure: 398 struct { 399 opaque master[0..47]; 400 } TLS12RSAMasterResponsePayload; 402 4.3. LURK Client Behavior 404 A LURK Client initiates an rsa_master or an rsa_master_with_poh 405 exchange in order to retrieve the master secret. The LURK exchange 406 happens on the TLS Server side (Edge Server). Upon receipt of the 407 master_secret the Edge Server generates the session keys and finish 408 the TLS key exchange protocol. 410 A LURK Client MAY use the rsa_master_with_poh to provide the LURK 411 Server evidences that the LURK exchange is performed in the context 412 of a TLS handshake. The Proof of TLS Hanshake (POH) helps the LURK 413 Server to audit the context associated to the query. 415 The LURK Client MUST ensure that the transmitted values for 416 server_random is S such as server_random = freshness_funct( S ). 418 4.4. LURK Server Behavior 420 Upon receipt of a rsa_master or a rsa_master_with_poh request, the 421 LURK Server proceeds according to the following steps: 423 1. The LURK Server checks the RSA key pair is available (key_id). 424 If the format of the key pair identifier is not understood, an 425 "invalid_key_id_type" error is returned. If the designated key 426 pair is not available an "invalid_key_id" error is returned. 428 2. The LURK Server checks the freshness_funct. If it does not 429 support the FreshnessFunct, an "invalid_freshness_funct" error 430 is returned. 432 3. The LURK Server collects the client_random, server_random and 433 pre_master parameters either provided explicitly (rsa_master) or 434 within the handshake (rsa_master_with_poh). 436 4. The LURK Server MUST check the format of the server_random and 437 more specifically checks the gmt_unix_time associated to the 438 random is acceptable. Otherwise it SHOULD return an 439 "invalid_tls_random" error. The value of the time window is 440 implementation dependent and SHOULD be a configurable 441 parameters. The LURK Server MAY also check the client_random. 442 This should be considered cautiously as such check may prevent 443 TLS Clients to set a TLS session. client_random is generated by 444 the TLS Client whose clock might not be synchronized with the 445 one of the LURK Server or that might have a TLS implementations 446 that does not generate random based on gmt_unix_time. 448 5. The LURK Server computes the necessary ServerHello.random from 449 the server_random when applicable as described in Section 4.1.1. 451 When option is set to "finished" the ServerHello.random in the 452 handshake is replaced by its new value. 454 6. The LURK Server checks the length of the encrypted premaster 455 secret and returns an "invalid_payload_format" error if the 456 length differs from the length of binary representation of the 457 RSA modulus. 459 7. The LURK Server decrypts the encrypted premaster secret as 460 described in [RFC5246] section 7.4.7.1. When a PKCS1.5 format 461 error is detected, or a mismatch between the TLS versions 462 provided as input and the one indicated in the encrypted 463 premaster secret, the Key Server returns a randomly generated 464 master secret. 466 8. The LURK Server generates the master secret as described in 467 [RFC5246] section 8.1 using the client_random, and the 468 server_random provided by the LURK Client. 470 9. With a rsa_master_with_poh, the LURK Server checks the Finished 471 message is checked as defined in [RFC5246] section 7.4.9. In 472 case of mismatch returns an "invalid_finished" error. 474 10. The LURK Server returns a master secret in a 475 TLS12RSAMasterResponsePayload. 477 11. Error are expected to provide the LURK Client an indication of 478 the cause that resulted in the error. When an error occurs the 479 LURK Server MAY ignore the request, or provide more generic 480 error codes such as "undefined_error" or "invalid_format". 482 5. rsa_extended_master, rss_extended_master_with_poh 484 A exchange of type "rsa_extended_master" enables the LURK Client to 485 delegate the RSA Key Exchange and authentication. The LURK Server 486 returns the extended master secret as defined in [RFC7627]. 488 5.1. Request Payload 490 The "rsa_extended_master" request has the following structure: 492 enum { sha256 (0), (255) } FreshnessFunct 494 enum { null(0), sha256_128(1), sha256_256(2), 495 (255) }POOPRF 497 struct { 498 KeyPairID key_id 499 FreshnessFunct freshness_funct // see RFC5246 section 6.1 500 opaque handshake_messages<2...2^16-2> // see RFC7627 section 4 501 }TLS12ExtendedMasterRSARequestPayload; 503 The "rsa_extended_master_with_poh" request has the following 504 structure: 506 struct { 507 KeyPairID key_id 508 FreshnessFunct freshness_funct // see RFC5246 section 6.1 509 opaque handshake_messages<2...2^16-2> 510 // see RFC5246 section 7.4.9 511 Finished finished 512 } 513 }TLS12ExtendedMasterRSAWithPoHRequestPayload; 515 key_id, freshness_funct, option, handshake, finished are defined in 516 Section 4.1. 518 handshake_messages With a the handshake message includes are those 519 necessary to generate a extended master secret as defined in 520 [RFC7627] section 4. 522 5.2. Response Payload 524 rsa_extended_master response payload has a similar structure as the 525 rsa_master response payload Section 4.2. 527 5.3. LURK Client Behavior 529 The LURK Client proceeds as described in {{sec-rsa-master-clt}. The 530 main difference is that the necessary element to generate the master 531 secret are included in the handshake and or not provided separately. 533 5.4. LURK Server Behavior 535 The LURK Server proceeds as described in Section 4.4 except that the 536 generation of the extended master is processed as described in 537 [RFC7627]. 539 6. ecdhe" 541 A exchange of type "ecdhe" enables the LURK Client to delegate the 542 ECDHE_RSA [RFC5246] or the ECDHE_ECDSA [RFC8422] authentication. 544 6.1. Request Payload 546 The "ecdhe" request payload has the following structure: 548 enum { null(0), sha256_128(1), sha256_256(2), 549 (255) }POOPRF 551 struct { 552 POOPRF poo_prf; 553 select( poo_prf ) { 554 case ( "null" ): 555 case ( "sha256_128" ) 556 ECPoint vG; //RFC8422 section 5.4 557 opaque R[16] r; 558 case ( "sha256_256" ): 559 ECPoint vG; //RFC8422 section 5.4 560 opaque R[32] r; 561 } 562 } TLS12POOParams; 564 struct { 565 KeyPairID key_id; 566 FreshnessFunct freshness_funct; 567 Random client_random; // see RFC5246 section 7.4.1.2 568 Random server_random; 569 SignatureAndHashAlgorithm sig_and_hash //RFC 5246 section 4.7 570 ServerECDHParams ecdhe_params; // RFC8422 section 5.4 571 POOParams poo_params; 572 } TLS12ECDHERequestPayload; 574 key_id, freshness_funct, client_random, server_random is defined in 575 Section 4.1. 577 ecdhe_params contains as defined in [RFC8422] section 5.4, the 578 elliptic curve domain parameters associated with the ECDH public 579 key (defined by the ECParameters structure) and the ephemeral ECDH 580 public key (defined by the ECPoint structure). The public key is 581 also noted in this document bG with b is a random secret generated 582 by the LURK Client and G the base point of the curve. 584 poo_params defines the necessary parameters to provide a proof of 585 ownership of the ECDHE private key. This option is intended to 586 prevent the LURK Server to sign bytes that do not correspond to a 587 ECDHE public key. 589 poo_prf pseudo random function used to generate the necessary 590 randoms to proof ownership of the private key. This document 591 defines sha256_128 and sha256_256 which apply the sha256 hash 592 function and respectively return the 128 or 256 first bits of the 593 resulting hash. 595 vG are the necessary points to generate the proof of ownership. 597 r necessary value to create the proof of ownership. 599 The proof of ownership (PoO) consists in the LURK Client proving the 600 knowledge of the private random b, while not disclosing b. With G 601 the base point, bG represents the public value. The PoO is based on 602 the non-interactive variant of the three-pass Schnorr identification 603 scheme (NIZR) also designated as the Fiat-Shamir transformation 604 described in [RFC8235]. More specifically, the LURK Client randomly 605 generates v and then derive c and r = v - b*c. The LURK Client 606 provides bG, vG, and r to the LURK Servers. The LURK Server first 607 checks bG is on the curve. Then it computes c similarly to the LURK 608 Client as well S = rG + (bG)c. This latest value S is compared to 609 vG. The equality between S and vG proves the ownership of b. 611 v is randomly generated by the LURK Client. v MUST remain non- 612 predictable with a length equivalent to the expected level of 613 security, that is 128 bit length (resp. 256 bit length) for a 128 614 (resp 256) bit security level. Given b, we RECOMMEND v to be at 615 least half the size of b. 617 c is computed by the LURK Client and the LURK Server as described in 618 [RFC8235]. UserID is defined by the concatenation of the 619 client_random and the server_random. OtherInfo is defined as the 620 concatenation of key_id, freshness_funct, sig_and_hash, ecdhe_params, 621 "tls12 poo". Each concatenated item is prefixed with a 4-byte 622 integer that represents the byte length of the item. 624 UserID = client_random || server_random 625 OtherInfo = key_id || freshness_funct || sig_and_hash || 626 ecdhe_params || "tls12 poo" 627 c = poo_prf(G || vG || bG || UserID || OtherInfo) 629 The LURK Client provides bG in ecdhe_params and vG as well as r in 630 poo_params. 632 With X25519 or X448, b and r MUST be clamped and vG MUST use the 633 Curve25519 (resp. Curve448). bG MAY also use the Curve25519 or 634 Curve448 representation, or the LURK Server MAY derive bG values from 635 the provided xlined value in ecdhe_params. 637 6.2. Response Payload 639 The "ecdhe" response payload has the following structure: 641 struct { 642 Signature signed_params; // RFC8422 section 5.4 643 } TLS12ECDHEResponsePayload; 645 signed_params signature applied to the hash of the ecdhe_params as 646 well as client_random and server_random as described in 647 [RFC8422] section 5.4. 649 6.3. LURK Client Behavior 651 The LURK Client builds the base as described in Section 4.1 and in 652 Section 6.1. 654 Upon receiving the response payload, the LURK Client MAY check the 655 signature. If the signature does not match an error SHOULD be 656 reported. 658 6.4. LURK Server Behavior 660 Upon receiving an ecdhe request, the LURK Server proceeds as follows: 662 1. perform steps 1 - 6 as described in Section 4.4 664 2. The LURK Server performs some format check of the ecdhe_params 665 before signing them. If the ecdhe_params does not follow the 666 expected structure. With the notations from [RFC8422], if 667 curve_type is not set to "named_curve", the LURK Server SHOULD 668 respond with an "invalid_ec_type" error. If the curve or 669 namedcurve is not supported the LURK Server SHOULD be able to 670 respond with an "invalid_ec_curve" error. 672 3. The LURK Server processes the poo_params. If the poo_prf is not 673 supported, the LURK Extension returns a "invalid_poo_prf" status. 674 If poo_prf is supported and different from "null", the LURK 675 Server proceeds to the proof of ownership as described in 676 Section 6.1. If the proof is not properly verified, the LURK 677 Extension returns a "invalid_poo" status. 679 4. The LURK Server processes the base structure as described in 680 Section 4.4 682 5. The LURK Server generates the signed_params. 684 Error are expected to provide the LURK Client an indication of the 685 cause that resulted in the error. When an error occurs the LURK 686 Server MAY ignore the request, or provide more generic error codes 687 such as "undefined_error" or "invalid_format". 689 7. capabilities 691 A exchange of type "capabilities" enables the LURK Client to be 692 informed of the supported operations performed by the LURK Server. 693 The supported parameters are provided on a per type basis. 695 7.1. Request Payload 697 A LURK "capabilities" request has no payload. 699 7.2. Response Payload 701 The "capabilities" response payload lists for each supported type, 702 the supported certificates, the supported signatures and hash 703 associated. The "capabilities" payload has the following structure: 705 struct{ 706 CertificateType certificate_type // RFC8442 section 4.4.2 707 select (certificate_type) { 708 case RawPublicKey: 709 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 710 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 711 case X509: 712 opaque cert_data<1..2^24-1>; 713 }; 714 } TypedCertificate; 716 struct { 717 KeyPairID key_id_type_list<0..255>; 718 TypedCertificate typed_certificate_list<0..255> 719 FreshnessFunctList freshness_funct_list<0..255> 720 CipherSuites cipher_suite_list<0..255> 721 PRFHash prf_hash_list<0..255> 722 } TLS12RSACapability; 724 struct { 725 KeyPairID key_id_type_list<0..255>; 726 TypedCertificate typed_certificate_list<0..255> 727 FreshnessFunctList freshness_funct_list<0..255> 728 CipherSuites cipher_suite_list<0..255> 729 SignatureAndHashAlgorithm sig_and_hash_list<0..255> 730 NameCurve ecdsa_curves_list<0..255>; 731 NameCurve ecdhe_curves_list<0..255> 732 POOPRF poo_prf_list<0..255> 733 } TLS12ECDHECapability; 735 struct { 736 uint32 length; 737 TLS12Type type 738 Select( type ) { 739 case rsa_master : TLS12RSACapability, 740 case rsa_master_with_poh : TLS12RSACapability, 741 case rsa_extended_master : TLS12RSACapability, 742 case rsa_extended_master_with_poh : TLS12RSACapability, 743 case ecdhe : TLS12ECDHECapability 744 } capability ; 745 } TLS12Capability 747 struct { 748 TLS12Capability capability_list; 749 opaque state<32>; 750 } TLS12CapabilitiesResponsePayload; 752 typed_certificate enables to contain authentication credentials of 753 various type, such as X09 certificate or raw public key. While 754 different, the structure is similar of CertificateEntry defined in 755 [RFC8446] section 4.4.2 as well as the Certificate structure 756 defined in [RFC7250]. 758 key_id_type_list the supported key_id_type. 760 freshness_funct_list designates the list of freshness_funct ( see 761 Section 4.1). 763 certificate_list designates the certificates associated to message 764 type. The format is similar but different from the 765 CertificateEntry defined in [RFC8446] in section 4.4.2 and 766 [RFC7250] section 1. The CertificateBis format enables the use of 767 X509 as well as Raw Public key, while the Certificate structure 768 defined in [RFC5246] section 7.4.2 does not. 770 sig_and_hash_list designates supported signature algorithms as well 771 as PRF used for the different operations. The format is defined 772 in [RFC5246] section 7.4.1.4.1. 774 ecdsa_curves_list the supported signatures 775 ecdhe_curves_list the supported curves for ECHDE parameters. 777 poo_prf_list the supported message type poo_prf ( see Section 6.1. 778 to be used with the proof of ownership. 780 type_list the supported message type of the LURK extension. 782 state characterizes the configuration associated to 'tls12' on the 783 LURK Server.. 785 7.3. LURK Client Behavior 787 The LURK Client performs a capability request in order to determine 788 the possible operations. 790 The LURK Client is expected to keep the state value to be able to 791 detect a change in the LURK Server configuration when an error 792 occurs. 794 7.4. LURK Server Behavior" 796 Upon receiving a capabilities request, the LURK Extension MUST return 797 the capabilities payload associated to a "success" status to the LURK 798 Server. These information are then forwarded by the LURK Server to 799 the LURK Client. 801 8. ping 803 A exchange of type "ping" enables the LURK Client to check the 804 reachability in a context of the defined LURK Extension. 806 8.1. Request Payload 808 A "ping" request has no payload. 810 8.2. Response Payload 812 A "ping" response has no payload. 814 8.3. LURK Client Behavior 816 The LURK Client sends a "ping" request to test the reachability of 817 the LURK Server. The reachability is performed for the tls12 LURK 818 Extension. 820 8.4. LURK Server Behavior 822 Upon receiving a ping request, the LURK Extension MUST return the 823 ping response associated with a "success" status to the LURK Server. 824 These information are then forwarded by the LURK Server to the LURK 825 Client. 827 9. Security Considerations 829 The security considerations defined in [I-D.mglt-lurk-lurk] applies 830 to the LURK Extension "tls12" defined in this document. 832 Anti-replay mechanisms rely in part on the security of channel 833 between the LURK Client and the LURK Server. As such the channel 834 between the LURK Client and the LURK Server MUST be ensuring 835 confidentiality and integrity. More specifically, the exchanges 836 between the LURK Client and the LURK Server MUST be an encrypted with 837 authentication encryption, and the two parties had previously 838 mutually authenticated. 840 The LURK Extension "tls12" is expected to have response smaller that 841 the request or at least not significantly larger, which makes "tls12" 842 relatively robust to amplification attacks. This is especially 843 matters when LURK is using UDP. The use of an authenticated channel 844 reduces also the risk of amplification attacks even when UDP is being 845 used. 847 The LURK Client and the LURK Server use time in their way to generate 848 the server_random. Care MUST be taken so the LURK Client and LURK 849 Server remain synchronized. 851 9.1. RSA 853 The rsa_master and rsa_extended_master returns the master_secret 854 instead of the premaster. The additional hashing operation necessary 855 to generate the master secret is expected to improve the protection 856 of the RSA private key against cryptographic analysis based on the 857 observation of a set of clear text and corresponding encrypted text. 859 The standard TLS1.2 is robust against Bleichenbacher attack as it 860 provides no means to detect if the error comes from a TLS version 861 mismatch or from the premaster format. This properties remain with 862 LURK, and so LURK does not present vulnerabilities toward 863 Bleichenbacher attack, and cannot be used as a decryption oracle. 865 9.2. ECDHE 867 A passive attacker observing the ecdhe exchange may collect a 868 sufficient amount of clear text and corresponding signature to 869 perform a cryptographic analysis or to reuse the signature for other 870 purposes. As a result, it remains important to encrypt the ecdhe 871 exchange between the LURK Client and the LURK Server. Note that this 872 vulnerability is present in TLS 1.2 as a TLS Client can accumulate 873 these data as well. The difference with LURK is by listening the 874 LURK Server, the accumulation is achieved for all TLS Clients. 876 As previously mentioned, the LURK Server may be used as signing 877 oracle for the specific string: 879 SHA(ClientHello.random + ServerHello.random + 880 ServerKeyExchange.params); 882 More specifically, the ECDHE_RSA and ECDHE_DSA mechanisms does not 883 associate the signature to a TLS1.2 context. As a result, an 884 attacker could re-used the signature in another context. 886 The attack may operate by collecting a large collection of clear text 887 and their corresponding signature. When the attacker want to provide 888 a signature, it checks in its database, a match occurs between the 889 two contents to be signed. The probability of a collision increases 890 with number of available hashes. The attack is related the pre-image 891 and collision resistance properties of the hash function. 893 The attacker may also given a clear text to be signed, generate a 894 collision such that a collision occurs which provides is related to 895 the second pre-image and collision resistance property of the hash 896 function. 898 The surface of attack is limited by: 900 o limiting the possibility of aggregating a collection of clear text 901 and their corresponding signatures. This could be achieved by 902 using multiple LURK Clients using an encrypted channel between the 903 LURK Client and the LURK Server. 905 o increasing the checks and ensure that signature is performed in a 906 TLS 1.2 context. For that purpose it is RECOMMENDED the LURK 907 Server checks the consistency of its input parameters. This 908 includes the proof of ownership as well as the format of the 909 randoms and ecdhe_params for example. 911 o limiting the usage of a Cryptographic material to a single usage, 912 in our case serving TLS 1.2. 914 9.3. Perfect Foward Secrecy 916 This document uses sha256 as the freshness_funct, in order to achieve 917 PFS Section 4.1.1 as described above. By construction of the 918 server_random, of the output of freshness_funct we will keep only the 919 last 28 bytes. The PFS property is in place as long as this 920 truncated version of freshness_funct can be considered a CRHF and 921 that the 28 bytes of randomness carried by the server_random are 922 sufficient. Otherwise, the mechanism described in this document will 923 not be considered as safe. 925 Details on the truncation will be added. Alternatively, we could use 926 a hash function like SHA3 (or, more explicitly SHAKE) which considers 927 variable output length as part of its design. The SHAKE functions 928 allow arbitrary output lengths and the PFS-input S can be of 929 arbitrary length too. However, for SHAKE128-d, if the truncated 930 output is of length d as low as 224 bits (28 bytes), then one only 931 gets 224/2=112 bits security w.r.t. collision-resistance, > 112 bits 932 w.r.t. preimage resistance and 112 bits security w.r.t. second 933 preimage resistance. 935 One reason why we have the hash-based solution to is to reduce 936 communication costs between the LURK Client and the LURK Server, 937 whilst still getting more than some security w.r.t. a MiM corrupting 938 a LURK Client and then attempting a PFS attack. 940 But, if we disregard the overhaed on communication costs, we can 941 consider other mechanisms not based on CRHF for attaining PFS 942 security. See I and II below. 944 I. For example, as freshness_funct, one can use an instance of a 945 pseudo random function (PRF), keyed on a key K that the LURK Server 946 already shares with the LURK Client. I.e., 947 server_random=freshness_funct(S;K). In this case, the mechanisms to 948 achieve PFS are as follows: 1. The LURK Client and the LURK Server 949 run a key-establishment protocol before every LURK session to 950 establish such a new key K for every LURK session. Alternatively, 951 the export this key of the key-establishment run to secure the 952 channel. The time-to-live of K is one session only. 2. The LURK 953 Server generates the value S on its side and send the server_random 954 to the LURK Client. 3. The LURK Client uses this server_random with 955 the TLS Client 4. The LURK Server checks the correctness of the use 956 of the said server_random when the query for the master_secret is 957 made, with the messages forwarded therein; 959 II. In fact, since the channel between the LURK Client and the LURK 960 Server MUST be encrypted by default, all for 2 steps in point I above 961 can be combined into 1 step (without the need of a specially executed 962 key-establishment): a. the LURK Server sends the server_random to 963 the LURK Client. b. the LURK Client uses this server_random with 964 the TLS Client c. the LURK Server checks the correctness of the use 965 of the said server_random when the query for the master_secret is 966 made, with the messages forwarded therein; 968 Yet, option I and option II are more expensive on the communication 969 than the version achieving PFS with a hash function. I.e., in I and 970 II, the LURK Server needs to be involved on the first part of the TLS 971 handshake to produce the S or server_random for the LURK Client. 972 However, note that the LURK Client no longer queries S, hence the 973 risk of a man-in-the-middle querying an old S is eliminated by 974 design. 976 Option II above is akin to what "Content delivery over TLS: a 977 cryptographic analysis of keyless SSL," by K. Bhargavan, I. 978 Boureanu, P. A. Fouque, C. Onete and B. Richard at 2017 IEEE 979 European Symposium on Security and Privacy (EuroS&P), Paris, 2017, 980 pp. 1-16, suggested in order to amend (forward-secrecy) attacks on 981 Keyless SSL. 983 10. IANA Considerations 985 The requested information is defined in [I-D.mglt-lurk-lurk]. 987 LURK Extension Designation: tls12 LURK Extension Reference: [RFD-TBD] 988 LURK Extension Description: RSA, ECDHE_RSA and ECDHE_ECDSA for (D)TLS 989 1.2. 991 LURK tls12 Extension Status 993 Value Description Reference 994 --------------------------------------------------- 995 0 - 1 Reserved [RFC-TBD-LURK] 996 2 undefined_error [RFC-TBD] 997 3 invalid_payload_format [RFC-TBD] 998 4 invalid_key_id_type [RFC-TBD] 999 5 invalid_key_id [RFC-TBD] 1000 6 invalid_tls_random [RFC-TBD] 1001 7 invalid_freshness_funct [RFC-TBD] 1002 8 invalid_encrypted_premaster [RFC-TBD] 1003 9 invalid_finished [RFC-TBD] 1004 10 invalid_ec_type [RFC-TBD] 1005 11 invalid_ec_curve [RFC-TBD] 1006 12 invalid_poo_prf [RFC-TBD] 1007 13 invalid_poo [RFC-TBD] 1008 14 invalid_cipher_or_prf_hash [RFC-TBD] 1009 15 - 255 UNASSIGNED 1011 LURK tls12 Extension Type 1013 Value Description Reference 1014 ---------------------------------------------- 1015 0 capabilities [RFC-TBD] 1016 1 ping [RFC-TBD] 1017 2 rsa_master [RFC-TBD] 1018 2 rsa_master_with_poh [RFC-TBD] 1019 3 rsa_extended_master [RFC-TBD] 1020 3 rsa_extended_master_with_poh [RFC-TBD] 1021 4 ecdhe [RFC-TBD] 1022 16 - 255 UNASSIGNED 1024 11. Acknowledgments 1026 We would like to thank for their very useful feed backs: Yaron 1027 Sheffer, Yoav Nir, Stephen Farrell, Eric Burger, Thomas Fossati, Eric 1028 Rescorla, Mat Naslung, Rich Salz, Ilari Liusvaara, Scott Fluhrer. 1029 Many ideas in this document are from [I-D.erb-lurk-rsalg]. 1031 We would also like to thank those that have supported LURK or raised 1032 interesting discussions. This includes among others Robert Skog, 1033 Hans Spaak, Salvatore Loreto, John Mattsson, Alexei Tumarkin, Richard 1034 Brunner, Stephane Dault, Dan Kahn Gillmor, Joe Hildebrand, Kelsey 1035 Cairns. 1037 12. Apendix 1039 ## LURK Exchange for TLS RSA Master Secret 1041 TLS Client Edge Server Key Server 1043 ClientHello 1044 server_version 1045 client_random 1046 cipher_suite 1047 TLS_RSA_*, ... 1048 --------> 1049 S = server_random 1050 server_random = freshness_funct( S ) 1052 ServerHello 1053 tls_version 1054 server_random 1055 Cipher_suite=TLS_RSA 1056 Certificate 1057 RSA Public Key 1058 ServerHelloDone 1059 <-------- 1061 ClientKeyExchange 1062 EncryptedPremasterSecret 1063 [ChangeCipherSpec] 1064 Finished 1065 --------> 1067 TLS12 Request Header 1068 TLS12MasterRSARequestPayload 1069 key_id 1070 freshness_funct 1071 prf_hash 1072 client_random 1073 S 1074 EncryptedPremasterSecret 1075 --------> 1077 server_random = freshness_funct( S ) 1079 master_secret = PRF(\ 1080 pre_master_secret + \ 1081 "master secret" +\ 1082 client_random +\ 1083 server_random)[0..47]; 1084 TLS12 Response Header 1085 TLS12MasterResponsePayload 1086 master 1087 <-------- 1089 [ChangeCipherSpec] 1090 Finished 1091 <-------- 1092 Application Data <-------> Application Data 1094 12.1. LURK Exchange for TLS RSA Master Secret with Proof of Handshake 1096 TLS Client Edge Server Key Server 1098 ClientHello 1099 server_version 1100 client_random 1101 cipher_suite 1102 TLS_RSA_*, ... 1103 --------> 1104 S = server_random 1105 server_random = freshness_funct( S ) 1107 ServerHello 1108 tls_version 1109 server_random 1110 Cipher_suite=TLS_RSA 1111 Certificate 1112 RSA Public Key 1113 ServerHelloDone 1114 <-------- 1116 ClientKeyExchange 1117 EncryptedPremasterSecret 1118 [ChangeCipherSpec] 1119 Finished 1120 --------> 1122 TLS12 Request Header 1123 TLS12MasterRSAWithPoHRequestPayload 1124 key_id 1125 freshness_funct 1126 handshake_messages 1127 finished 1128 --------> 1130 server_random = freshness_funct( S ) 1131 master_secret = PRF(\ 1132 pre_master_secret + \ 1133 "master secret" +\ 1134 client_random +\ 1135 server_random)[0..47]; 1137 TLS12 Response Header 1138 TLS12MasterResponsePayload 1139 master 1140 <-------- 1142 [ChangeCipherSpec] 1143 Finished 1144 <-------- 1145 Application Data <-------> Application Data 1147 12.2. LURK Exchange for TLS RSA Extended Master Secret 1148 TLS Client Edge Server Key Server 1150 ClientHello 1151 tls_version 1152 cipher_suite 1153 TLS_RSA_*, ... 1154 Extension 0x0017 1155 --------> 1157 ServerHello 1158 edge_server_version 1159 cipher_suite=TLS_RSA 1160 Extension 0x0017 1161 Certificate 1162 RSA Public Key 1163 ServerHelloDone 1164 <-------- 1165 ClientKeyExchange 1166 EncryptedPremasterSecret 1167 [ChangeCipherSpec] 1168 Finished 1169 --------> 1171 TLS12 Request Header 1172 TLS12ExtendedMasterRSARequestPayload 1173 key_id 1174 freshness_funct 1175 handshake_messages 1176 EncryptedPreMasterSecret 1177 --------> 1179 1. Computing Master Secret 1180 master_secret = master_prf( 1181 pre_master_secret +\ 1182 "extended master secret" +\ 1183 session_hash)[0..47] 1185 TLS12 Response Header 1186 TLS12MasterPayload 1187 master 1188 <-------- 1190 [ChangeCipherSpec] 1191 Finished 1192 <-------- 1193 Application Data <-------> Application Data 1195 12.3. LURK Exchange for TLS RSA Extended Master Secret with proof of 1196 handshake 1198 TLS Client Edge Server Key Server 1200 ClientHello 1201 tls_version 1202 cipher_suite 1203 TLS_RSA_*, ... 1204 Extension 0x0017 1205 --------> 1207 ServerHello 1208 edge_server_version 1209 cipher_suite=TLS_RSA 1210 Extension 0x0017 1211 Certificate 1212 RSA Public Key 1213 ServerHelloDone 1214 <-------- 1215 ClientKeyExchange 1216 EncryptedPremasterSecret 1217 [ChangeCipherSpec] 1218 Finished 1219 --------> 1221 TLS12 Request Header 1222 TLS12ExtendedMasterWithPoHRequestPayload 1223 key_id 1224 freshness_funct 1225 handshake_messages 1226 finished 1227 --------> 1229 1. Computing Master Secret 1230 master_secret = master_prf( 1231 pre_master_secret +\ 1232 "extended master secret" +\ 1233 session_hash)[0..47] 1235 TLS12 Response Header 1236 TLS12MasterPayload 1237 master 1238 <-------- 1240 [ChangeCipherSpec] 1241 Finished 1242 <-------- 1243 Application Data <-------> Application Data 1245 12.4. LURK Exchange for TLS ECDHE Signature 1247 TLS Client Edge Server Key Server 1249 ClientHello 1250 tls_version 1251 client_random 1252 cipher_suite 1253 TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_*, ... 1254 Extension Supported EC, Supported Point Format 1255 --------> 1256 S = server_random 1257 server_random = freshness_funct( S ) 1259 TLS12 Request Header 1260 TLS12ECDHEInputPayload 1261 key_id 1262 client_random 1263 S 1264 ecdhe_params 1265 --------> 1266 server_random = freshness_funct( S ) 1268 signature = ECDSA( client_random +\ 1269 server_random + ecdhe_params ) 1271 TLS12 Response Header 1272 TLS12DigitallySignedPayloads 1273 signature 1274 <-------- 1276 ServerHello 1277 tls_version 1278 server_random 1279 Cipher_suite=TLS_ECDHE_ECDSA 1280 Extension Supported EC, 1281 Supported Point Format 1282 Certificate 1283 ECDSA Public Key 1284 ServerKeyExchange 1285 ecdhe_params 1286 signature 1287 ServerHelloDone 1288 <-------- 1290 ClientKeyExchange 1291 [ChangeCipherSpec] 1292 Finished 1293 --------> 1294 [ChangeCipherSpec] 1295 Finished 1296 <-------- 1297 Application Data <-------> Application Data 1299 13. References 1301 13.1. Normative References 1303 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1304 (TLS) Protocol Version 1.2", RFC 5246, 1305 DOI 10.17487/RFC5246, August 2008, 1306 . 1308 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1309 "Elliptic Curve Cryptography Subject Public Key 1310 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1311 . 1313 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1314 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1315 January 2012, . 1317 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1318 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1319 Transport Layer Security (TLS) and Datagram Transport 1320 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1321 June 2014, . 1323 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1324 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1325 Session Hash and Extended Master Secret Extension", 1326 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1327 . 1329 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1330 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1331 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1332 . 1334 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 1335 Curve Cryptography (ECC) Cipher Suites for Transport Layer 1336 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 1337 DOI 10.17487/RFC8422, August 2018, 1338 . 1340 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1341 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1342 . 1344 13.2. Informative References 1346 [I-D.erb-lurk-rsalg] 1347 Erb, S. and R. Salz, "A PFS-preserving protocol for LURK", 1348 draft-erb-lurk-rsalg-01 (work in progress), May 2016. 1350 [I-D.fieau-cdni-https-delegation] 1351 Fieau, F., Emile, S., and S. Mishra, "HTTPS delegation in 1352 CDNI", draft-fieau-cdni-https-delegation-02 (work in 1353 progress), July 2017. 1355 [I-D.ietf-acme-acme] 1356 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1357 Kasten, "Automatic Certificate Management Environment 1358 (ACME)", draft-ietf-acme-acme-18 (work in progress), 1359 December 2018. 1361 [I-D.ietf-acme-star] 1362 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 1363 Fossati, "Support for Short-Term, Automatically-Renewed 1364 (STAR) Certificates in Automated Certificate Management 1365 Environment (ACME)", draft-ietf-acme-star-11 (work in 1366 progress), October 2019. 1368 [I-D.mglt-lurk-lurk] 1369 Migault, D., "LURK Protocol version 1", draft-mglt-lurk- 1370 lurk-00 (work in progress), February 2018. 1372 [I-D.mglt-lurk-tls-use-cases] 1373 Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios, 1374 "LURK TLS/DTLS Use Cases", draft-mglt-lurk-tls-use- 1375 cases-02 (work in progress), June 2016. 1377 [I-D.rescorla-tls-subcerts] 1378 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 1379 "Delegated Credentials for TLS", draft-rescorla-tls- 1380 subcerts-02 (work in progress), October 2017. 1382 [I-D.sheffer-acme-star-request] 1383 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 1384 Fossati, "Generating Certificate Requests for Short-Term, 1385 Automatically-Renewed (STAR) Certificates", draft-sheffer- 1386 acme-star-request-02 (work in progress), June 2018. 1388 [RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge 1389 Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, 1390 . 1392 Authors' Addresses 1394 Daniel Migault 1395 Ericsson 1396 8275 Trans Canada Route 1397 Saint Laurent, QC 4S 0B6 1398 Canada 1400 EMail: daniel.migault@ericsson.com 1402 Ioana Boureanu 1403 University of Surrey 1404 Stag Hill Campus 1405 Guildford GU2 7XH 1406 UK 1408 EMail: i.boureanu@surrey.ac.uk