idnits 2.17.1 draft-mglt-lurk-tls12-05.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 360: '... the latter SHOULD happen over a sec...' RFC 2119 keyword, line 379: '... The server_random MUST follow the structure of [RFC5246] section...' RFC 2119 keyword, line 388: '... The operation MUST be performed by ...' RFC 2119 keyword, line 409: '... A LURK Client MAY use the rsa_maste...' RFC 2119 keyword, line 414: '... 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 283 has weird spacing: '...rSecret pre_m...' == Line 296 has weird spacing: '...s_funct the o...' == Line 299 has weird spacing: '...rf_hash the o...' == Line 303 has weird spacing: '..._random the r...' == Line 324 has weird spacing: '...essages provi...' == (17 more instances...) -- The document date (26 July 2021) is 976 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 555 -- Looks like a reference, but probably isn't: '32' on line 558 == 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: 27 January 2022 University of Surrey 6 26 July 2021 8 LURK Extension version 1 for (D)TLS 1.2 Authentication 9 draft-mglt-lurk-tls12-05 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 27 January 2022. 34 Copyright Notice 36 Copyright (c) 2021 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 (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 52 3. LURK Header . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. rsa_master, rsa_master_with_poh . . . . . . . . . . . . . . . 6 54 4.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 6 55 4.1.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . 8 56 4.2. Response Payload . . . . . . . . . . . . . . . . . . . . 9 57 4.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 10 58 4.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 10 59 5. rsa_extended_master, rss_extended_master_with_poh . . . . . . 11 60 5.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 11 61 5.2. Response Payload . . . . . . . . . . . . . . . . . . . . 12 62 5.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 12 63 5.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 12 64 6. ecdhe" . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 6.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 13 66 6.2. Response Payload . . . . . . . . . . . . . . . . . . . . 15 67 6.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 15 68 6.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 15 69 7. capabilities . . . . . . . . . . . . . . . . . . . . . . . . 16 70 7.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 16 71 7.2. Response Payload . . . . . . . . . . . . . . . . . . . . 16 72 7.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 18 73 7.4. LURK Server Behavior" . . . . . . . . . . . . . . . . . . 18 74 8. ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 8.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 18 76 8.2. Response Payload . . . . . . . . . . . . . . . . . . . . 18 77 8.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 19 78 8.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 19 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 9.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 9.2. ECDHE . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 9.3. Perfect Foward Secrecy . . . . . . . . . . . . . . . . . 21 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 85 12. Apendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 12.1. LURK Exchange for TLS RSA Master Secret with Proof of 87 Handshake . . . . . . . . . . . . . . . . . . . . . . . 25 88 12.2. LURK Exchange for TLS RSA Extended Master Secret . . . . 26 89 12.3. LURK Exchange for TLS RSA Extended Master Secret with 90 proof of handshake . . . . . . . . . . . . . . . . . . . 28 91 12.4. LURK Exchange for TLS ECDHE Signature . . . . . . . . . 30 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 94 13.2. Informative References . . . . . . . . . . . . . . . . . 32 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 97 1. Introduction 99 This document describes the LURK Extension for TLS 1.2 so the LURK 100 Server can implement a Cryptographic Service in a TLS 1.2 [RFC5246] 101 and DTLS 1.2 [RFC6347] context. 103 More specifically, the LURK Server will be in charge of performing 104 the cryptographic operations associated to the private key of the TLS 105 Server, while other aspects of the termination of the TLS session is 106 handled by other services in the same administrative domain or in a 107 different administrative domain. Most Cryptographic Operations are 108 related to the TLS authentication and the current document limits the 109 Cryptographic Operations to the following authentication methods: RSA 110 and ECDHE_RSA defined in [RFC5246], [RFC6347] as well as ECDHE_ECDSA 111 defined in [RFC8422]. 113 A more detailed description of some use cases foreseen in a TLS 114 context can be found in [I-D.mglt-lurk-tls-use-cases]. 116 HTTPS delegation has been the main concern of the Content Delivery 117 Networks Interconnection (cdni) Working Group and several mechanisms 118 have been designed to delegate the load from an upstream entity to a 119 downstream entity. Entities can be of different nature and may 120 designated differently according to the context. Typically 121 designations includes Content Owner, CDN Provider, Domain Name Owner 122 for example. [I-D.fieau-cdni-https-delegation] provides a details 123 comparison of the various mechanisms applies to the CDN 124 Interconnection, and the remaining of this section positions these 125 mechanisms at a very high level view. 127 STAR [I-D.ietf-acme-star], [I-D.sheffer-acme-star-request] describes 128 a methods where the domain name owner or the content owner 129 orchestrates the refreshing process between a CA and the CDN 130 (terminating the TLS session). The CDN refreshes regularly and 131 automatically its certificates using [I-D.ietf-acme-acme], which 132 allows the use of short term certificates. 134 Delegated credentials [I-D.rescorla-tls-subcerts] consists having a 135 certificate that enables the servers to generates some "delegated 136 credentials". 138 STAR and "delegated credentials" both require some changes performed 139 by the CA - new certificate type for the delegated credentials and 140 new interfaces for the delegated and delegating entity for STAR. In 141 both case the TLS Client authenticates the delegated entity. While 142 STAR does not require changes on the TLS Client, the "delegated 143 credential" solution does. In both cases, the delegation is 144 controlled by limiting in time (7 days), which is also the limit of 145 use of a stolen key or a rogue server. Such delegation provides a 146 high scalability of the architecture and prevents additional delays 147 when a TLS session is established. 149 The LURK Architecture [I-D.mglt-lurk-lurk] and the LURK Extension 150 'tls12' do not proceed to the delegation of the HTTPS delegation by 151 delegating the entire TLS termination. Instead, the TLS termination 152 is split into sub services, for example one associated to the 153 networking part and one associated to the cryptographic operation. 154 While micro services associated to the networking part are delegated, 155 the micro service associated to the cryptographic operation may not 156 be delegated. As a result, LURK Architecture is focused on the 157 protection of the Cryptographic Material and prevents leakage of the 158 Cryptographic Material for example by avoiding node exposed to the 159 Internet to host the Cryptographic Material. In addition, LURK 160 provides means to instantaneously suspend the delegation with a 161 suspicious node. On the other hand the LURK Extension 'tls12' 162 introduces some latency, and is not as scalable as STAR or delegated 163 credential solutions. 165 The LURK Extension 'tls12' is seen as a complementary to the STAR and 166 "delegated credentials". The LURK Extension 'tls12' is a backend 167 solution that does not require any modifications from TLS Client or 168 the CA. It is also aimed at protecting the Cryptographic Material. 170 LURK may also be deployed within an administrative domain in order to 171 to provide a more controlled deployment of TLS Servers. 173 2. Terminology and Acronyms 175 This document re-uses the terminology defined in 176 [I-D.mglt-lurk-lurk]. 178 3. LURK Header 180 LURK / TLS 1.2 is a LURK Extension that introduces a new designation 181 "tls12". This document assumes that Extension is defined with 182 designation set to "tls12" and version set to 1. The LURK Extension 183 extends the LURKHeader structure defined in [I-D.mglt-lurk-lurk] as 184 follows: 186 enum { 187 tls12 (1), (255) 188 } Designation; 190 enum { 191 capabilities (0), ping (1), rsa_master (2), 192 rsa_master_with_poh (3), rsa_extended_master (4), 193 rsa_extended_master_with_poh (5), ecdhe (6), (255) 194 }TLS12Type; 196 enum { 197 // generic values reserved or aligned with the 198 // LURK Protocol 199 request (0), success (1), undefined_error (2), 200 invalid_payload_format (3), 202 // code points for rsa authentication 203 invalid_key_id_type (4), invalid_key_id (5), 204 invalid_tls_random (6), invalid_freshness_funct (7), 205 invalid_encrypted_premaster (8), invalid_finished (9) 207 //code points for ecdhe authentication 208 invalid_ec_type (10), invalid_ec_curve (11), 209 invalid_poo_prf (12), invalid_poo (13), (255) 210 }TLS12Status 212 struct { 213 Designation designation = "tls12"; 214 int8 version = 1; 215 } Extension; 217 struct { 218 Extension extension; 219 select( Extension ){ 220 case ("tls12", 1): 221 TLS12Type; 222 } type; 223 select( Extension ){ 224 case ("tls12", 1): 225 TLS12Status; 226 } status; 227 uint64 id; 228 unint32 length; 229 } LURKHeader; 231 4. rsa_master, rsa_master_with_poh 233 An exchange of type "rsa_master" or "rsa_master_with_poh" enables the 234 LURK Client to delegate the RSA Key Exchange and authentication as 235 defined in [RFC5246]. The LURK Server returns the master secret. 237 "rsa_master" provides the necessary parameters and details to 238 generate the master secret, as well as to hinder replaying of old 239 handshake messages by a corrupt LURK Client. I.e., some attestation 240 of message-freshness is acquired by the LURK Server. 242 In addition, the"rsa_master_with_poh" provides a proof of handshake 243 (PoH). The proof of handshake consists in providing the Finished 244 message of the TLS Client to the LURK Server, so that latter can 245 perform more checks that in the "rsa_master" mode. Notably, herein, 246 the LURK Server also checks that the LURK request is performed in a 247 context of a TLS handshake. 249 While "rsa_master" and "rsa_master_with_poh" exchange have 250 respectively different requests, the response is the same. The 251 motivation for having different type is that the parameters provided 252 to the LURK Server are provided using different format. "rsa_master" 253 provides them explicitly, while "rsa_master_with_poh" provides them 254 via handshake messages. 256 4.1. Request Payload 258 A rsa_master request payload has the following structure: 260 enum { 261 sha256_32 (0), (255) 262 }KeyPairIdType; 264 struct { 265 KeyPairIdType type; 266 opaque data; // length defined by the type 267 } KeyPairID; 269 enum{ 270 sha256 (0), (255) 271 } FreshnessFunct 273 enum{ 274 sha256 (0), sha384(1), sha512(2), (255) 275 } PRFHash 277 struct { 278 KeyPairID key_id; 279 FreshnessFunct freshness_funct; 280 PRFHash prf_hash; 281 Random client_random; // see RFC5246 section 7.4.1.2 282 Random server_random; 283 EncryptedPreMasterSecret pre_master; 284 // see RFC5246 section 7.4.7.1 285 // Length depends on the key. 286 } 287 } TLS12RSAMasterRequestPayload; 289 key_id The identifier of the public key. This document defines 290 sha256_32 format which takes the 32 first bits of the hash of the 291 binary ASN.1 DER representation of the public key using sha256. 292 The binary representation of RSA keys is described in [RFC8017]. 293 The binary representation of ECC keys is the subjectPublicKeyInfo 294 structure defined in [RFC5480]. 296 freshness_funct the one-way hash function (OWHF) used by LURK to 297 implement Perfect Forward Secrecy. 299 prf_hash the one way hash function used by the Pseudo Random 300 Function (PRF) to generate the master secret. PRF and hash 301 function are defined in {!RFC5246}} Section 5. 303 client_random the random value associated to the TLS Client as 304 defined in [RFC5246] Section 7.4.1.2. 306 server_random: the random value associated to the TLS Server as 307 defined in [RFC5246] Section 7.4.1.2. 309 EncryptedPreMasterSecret : The encrypted master secret as defined in 310 [RFC5246] Section 7.4.7.1. 312 A rsa_master_with_poh request payload has the following structure: 314 struct { 315 KeyPairID key_id; 316 FreshnessFunct freshness_funct; 317 opaque handshake_messages<2...2^16-2> 318 // see RFC5246 section 7.4.9 319 Finished finished 320 } TLS12RSAMasterWithPoHRequestPayload; 322 key_id, freshness_funct are defined above 324 handshake_messages provides the necessary handshake messages to 325 compute the Finished message of the TLS Client as defined in 326 [RFC5246] section 7.4.9. 328 finished the TLS Client Finished message as defined by [RFC5246] 329 section 7.4.9. 331 4.1.1. Perfect Forward Secrecy 333 This document defines a mechanism which uses a function called 334 freshness_funct, to prevent an attacker to send a request to the LURK 335 Server in such a way that the said attacker can obtain back the 336 mastersecret for an old handshake. In other words, the use of this 337 function helps prevent a forward-secrecy attack on an old TLS 338 session, where the attack would make use that session's handshake- 339 data observed by the adversary. 341 This design achieves PFS with freshness_funct being a collision- 342 resistant hash function (CHRF). By CRHF, we mean a one-way hash 343 function (OWHF) which also has collision resistance; the latter means 344 that it is computationally infeasible to find any two inputs x1 and 345 x2 such that freshness_funct(x1) = freshness_funct(x2). By one-way 346 hash function (OWHF) we mean, as standard, a hash function 347 freshness_funct that satisfies preimage resistance and 2nd-preimage 348 resistance. That is, given a hash value y, it is computationally 349 infeasible to find an x such that freshness_funct(x) = y, and 350 respectively-- given a value x1 and its hash freshness_funct(x1), it 351 is computationally infeasible to find another x2 such that 352 freshness_funct(x2) = freshness_funct(x1). 354 For the concrete use of our freshness_funct funtions, let S be a 355 fresh, randomly picked value generated by the LURK Client. The value 356 of server_random in the TLS exchange is then equal to 357 freshness_funct(S), i.e., server_random=freshness_funct(S). Between 358 the TLS Client and the LURK Server only server-random is exchanged. 359 The LURK Client sends S to the Key Server, in the query. Note that 360 the latter SHOULD happen over a secure channel. 362 A man-in-the-middle attacker observing the (plaintext) TLS handshake 363 between a TLS Client and the LURK Client does not see S, but only 364 server_random. The preimage resistance guaranted by the 365 freshness_funct makes it such that this man-in-the-middle cannot 366 retrieve S out of the observed server-random. As such, this man-in- 367 the-middle attacker cannot query the S corresponding to an (old) 368 observed handshake to the Key Server. Moreover, the collision 369 resistance guaranteed by the freshness_funct makes it such that if 370 the aforementioned man-in-the-middle cannot find S' such that 371 freshness_funct(S)=freshness_funct(S'). 373 As discussed in Section 9, PFS may be achieved in other ways (i.e., 374 not using a CRHF and the aforementioned exchanges but other 375 cryptographic primitives and other exchanges). These may offer 376 better computational efficiency. These may be standardized in future 377 versions of the LURK extension "tls12. 379 The server_random MUST follow the structure of [RFC5246] section 380 7.4.1.2, which carries the gmt_unix_time in the first four bytes. 381 So, the ServerHello.random of the TLS exchange is derived from the 382 server_random of the LURK exchange as defined below: 384 gmt_unix_time = server_random[0..3]; 385 ServerHello.random = freshness_funct( server_random + "tls12 pfs" ); 386 ServerHello.random[0..3] = gmt_unix_time; 388 The operation MUST be performed by the LURK Server as well as the TLS 389 Server, upon receiving the master secret or the signature of the 390 ecdhe_params from the LURK Client. 392 4.2. Response Payload 394 The "rsa_master" response payload contains the master secret and has 395 the following structure: 397 struct { 398 opaque master[0..47]; 399 } TLS12RSAMasterResponsePayload; 401 4.3. LURK Client Behavior 403 A LURK Client initiates an rsa_master or an rsa_master_with_poh 404 exchange in order to retrieve the master secret. The LURK exchange 405 happens on the TLS Server side (Edge Server). Upon receipt of the 406 master_secret the Edge Server generates the session keys and finish 407 the TLS key exchange protocol. 409 A LURK Client MAY use the rsa_master_with_poh to provide the LURK 410 Server evidences that the LURK exchange is performed in the context 411 of a TLS handshake. The Proof of TLS Hanshake (POH) helps the LURK 412 Server to audit the context associated to the query. 414 The LURK Client MUST ensure that the transmitted values for 415 server_random is S such as server_random = freshness_funct( S ). 417 4.4. LURK Server Behavior 419 Upon receipt of a rsa_master or a rsa_master_with_poh request, the 420 LURK Server proceeds according to the following steps: 422 1. The LURK Server checks the RSA key pair is available (key_id). 423 If the format of the key pair identifier is not understood, an 424 "invalid_key_id_type" error is returned. If the designated key 425 pair is not available an "invalid_key_id" error is returned. 427 2. The LURK Server checks the freshness_funct. If it does not 428 support the FreshnessFunct, an "invalid_freshness_funct" error 429 is returned. 431 3. The LURK Server collects the client_random, server_random and 432 pre_master parameters either provided explicitly (rsa_master) or 433 within the handshake (rsa_master_with_poh). 435 4. The LURK Server MUST check the format of the server_random and 436 more specifically checks the gmt_unix_time associated to the 437 random is acceptable. Otherwise it SHOULD return an 438 "invalid_tls_random" error. The value of the time window is 439 implementation dependent and SHOULD be a configurable 440 parameters. The LURK Server MAY also check the client_random. 441 This should be considered cautiously as such check may prevent 442 TLS Clients to set a TLS session. client_random is generated by 443 the TLS Client whose clock might not be synchronized with the 444 one of the LURK Server or that might have a TLS implementations 445 that does not generate random based on gmt_unix_time. 447 5. The LURK Server computes the necessary ServerHello.random from 448 the server_random when applicable as described in Section 4.1.1. 449 When option is set to "finished" the ServerHello.random in the 450 handshake is replaced by its new value. 452 6. The LURK Server checks the length of the encrypted premaster 453 secret and returns an "invalid_payload_format" error if the 454 length differs from the length of binary representation of the 455 RSA modulus. 457 7. The LURK Server decrypts the encrypted premaster secret as 458 described in [RFC5246] section 7.4.7.1. When a PKCS1.5 format 459 error is detected, or a mismatch between the TLS versions 460 provided as input and the one indicated in the encrypted 461 premaster secret, the Key Server returns a randomly generated 462 master secret. 464 8. The LURK Server generates the master secret as described in 465 [RFC5246] section 8.1 using the client_random, and the 466 server_random provided by the LURK Client. 468 9. With a rsa_master_with_poh, the LURK Server checks the Finished 469 message is checked as defined in [RFC5246] section 7.4.9. In 470 case of mismatch returns an "invalid_finished" error. 472 10. The LURK Server returns a master secret in a 473 TLS12RSAMasterResponsePayload. 475 11. Error are expected to provide the LURK Client an indication of 476 the cause that resulted in the error. When an error occurs the 477 LURK Server MAY ignore the request, or provide more generic 478 error codes such as "undefined_error" or "invalid_format". 480 5. rsa_extended_master, rss_extended_master_with_poh 482 A exchange of type "rsa_extended_master" enables the LURK Client to 483 delegate the RSA Key Exchange and authentication. The LURK Server 484 returns the extended master secret as defined in [RFC7627]. 486 5.1. Request Payload 488 The "rsa_extended_master" request has the following structure: 490 enum { sha256 (0), (255) } FreshnessFunct 492 enum { null(0), sha256_128(1), sha256_256(2), 493 (255) }POOPRF 495 struct { 496 KeyPairID key_id 497 FreshnessFunct freshness_funct // see RFC5246 section 6.1 498 opaque handshake_messages<2...2^16-2> // see RFC7627 section 4 499 }TLS12ExtendedMasterRSARequestPayload; 501 The "rsa_extended_master_with_poh" request has the following 502 structure: 504 struct { 505 KeyPairID key_id 506 FreshnessFunct freshness_funct // see RFC5246 section 6.1 507 opaque handshake_messages<2...2^16-2> 508 // see RFC5246 section 7.4.9 509 Finished finished 510 } 511 }TLS12ExtendedMasterRSAWithPoHRequestPayload; 513 key_id, freshness_funct, option, handshake, finished are defined in 514 Section 4.1. 516 handshake_messages With a the handshake message includes are those 517 necessary to generate a extended master secret as defined in 518 [RFC7627] section 4. 520 5.2. Response Payload 522 rsa_extended_master response payload has a similar structure as the 523 rsa_master response payload Section 4.2. 525 5.3. LURK Client Behavior 527 The LURK Client proceeds as described in Section 4.3. The main 528 difference is that the necessary element to generate the master 529 secret are included in the handshake and or not provided separately. 531 5.4. LURK Server Behavior 533 The LURK Server proceeds as described in Section 4.4 except that the 534 generation of the extended master is processed as described in 535 [RFC7627]. 537 6. ecdhe" 539 A exchange of type "ecdhe" enables the LURK Client to delegate the 540 ECDHE_RSA [RFC5246] or the ECDHE_ECDSA [RFC8422] authentication. 542 6.1. Request Payload 544 The "ecdhe" request payload has the following structure: 546 enum { null(0), sha256_128(1), sha256_256(2), 547 (255) }POOPRF 549 struct { 550 POOPRF poo_prf; 551 select( poo_prf ) { 552 case ( "null" ): 553 case ( "sha256_128" ) 554 ECPoint vG; //RFC8422 section 5.4 555 opaque R[16] r; 556 case ( "sha256_256" ): 557 ECPoint vG; //RFC8422 section 5.4 558 opaque R[32] r; 559 } 560 } TLS12POOParams; 562 struct { 563 KeyPairID key_id; 564 FreshnessFunct freshness_funct; 565 Random client_random; // see RFC5246 section 7.4.1.2 566 Random server_random; 567 SignatureAndHashAlgorithm sig_and_hash //RFC 5246 section 4.7 568 ServerECDHParams ecdhe_params; // RFC8422 section 5.4 569 POOParams poo_params; 570 } TLS12ECDHERequestPayload; 572 key_id, freshness_funct, client_random, server_random is defined in 573 Section 4.1. 575 ecdhe_params contains as defined in [RFC8422] section 5.4, the 576 elliptic curve domain parameters associated with the ECDH public 577 key (defined by the ECParameters structure) and the ephemeral ECDH 578 public key (defined by the ECPoint structure). The public key is 579 also noted in this document bG with b is a random secret generated 580 by the LURK Client and G the base point of the curve. 582 poo_params defines the necessary parameters to provide a proof of 583 ownership of the ECDHE private key. This option is intended to 584 prevent the LURK Server to sign bytes that do not correspond to a 585 ECDHE public key. 587 poo_prf pseudo random function used to generate the necessary 588 randoms to proof ownership of the private key. This document 589 defines sha256_128 and sha256_256 which apply the sha256 hash 590 function and respectively return the 128 or 256 first bits of the 591 resulting hash. 593 vG are the necessary points to generate the proof of ownership. 595 r necessary value to create the proof of ownership. 597 The proof of ownership (PoO) consists in the LURK Client proving the 598 knowledge of the private random b, while not disclosing b. With G 599 the base point, bG represents the public value. The PoO is based on 600 the non-interactive variant of the three-pass Schnorr identification 601 scheme (NIZR) also designated as the Fiat-Shamir transformation 602 described in [RFC8235]. More specifically, the LURK Client randomly 603 generates v and then derive c and r = v - b*c. The LURK Client 604 provides bG, vG, and r to the LURK Servers. The LURK Server first 605 checks bG is on the curve. Then it computes c similarly to the LURK 606 Client as well S = rG + (bG)c. This latest value S is compared to 607 vG. The equality between S and vG proves the ownership of b. 609 v is randomly generated by the LURK Client. v MUST remain non- 610 predictable with a length equivalent to the expected level of 611 security, that is 128 bit length (resp. 256 bit length) for a 128 612 (resp 256) bit security level. Given b, we RECOMMEND v to be at 613 least half the size of b. 615 c is computed by the LURK Client and the LURK Server as described in 616 [RFC8235]. UserID is defined by the concatenation of the 617 client_random and the server_random. OtherInfo is defined as the 618 concatenation of key_id, freshness_funct, sig_and_hash, ecdhe_params, 619 "tls12 poo". Each concatenated item is prefixed with a 4-byte 620 integer that represents the byte length of the item. 622 UserID = client_random || server_random 623 OtherInfo = key_id || freshness_funct || sig_and_hash || 624 ecdhe_params || "tls12 poo" 625 c = poo_prf(G || vG || bG || UserID || OtherInfo) 627 The LURK Client provides bG in ecdhe_params and vG as well as r in 628 poo_params. 630 With X25519 or X448, b and r MUST be clamped and vG MUST use the 631 Curve25519 (resp. Curve448). bG MAY also use the Curve25519 or 632 Curve448 representation, or the LURK Server MAY derive bG values from 633 the provided xlined value in ecdhe_params. 635 6.2. Response Payload 637 The "ecdhe" response payload has the following structure: 639 struct { 640 Signature signed_params; // RFC8422 section 5.4 641 } TLS12ECDHEResponsePayload; 643 signed_params signature applied to the hash of the ecdhe_params as 644 well as client_random and server_random as described in 646 [RFC8422] section 5.4. 648 6.3. LURK Client Behavior 650 The LURK Client builds the base as described in Section 4.1 and in 651 Section 6.1. 653 Upon receiving the response payload, the LURK Client MAY check the 654 signature. If the signature does not match an error SHOULD be 655 reported. 657 6.4. LURK Server Behavior 659 Upon receiving an ecdhe request, the LURK Server proceeds as follows: 661 1. perform steps 1 - 6 as described in Section 4.4 663 2. The LURK Server performs some format check of the ecdhe_params 664 before signing them. If the ecdhe_params does not follow the 665 expected structure. With the notations from [RFC8422], if 666 curve_type is not set to "named_curve", the LURK Server SHOULD 667 respond with an "invalid_ec_type" error. If the curve or 668 namedcurve is not supported the LURK Server SHOULD be able to 669 respond with an "invalid_ec_curve" error. 671 3. The LURK Server processes the poo_params. If the poo_prf is not 672 supported, the LURK Extension returns a "invalid_poo_prf" status. 673 If poo_prf is supported and different from "null", the LURK 674 Server proceeds to the proof of ownership as described in 675 Section 6.1. If the proof is not properly verified, the LURK 676 Extension returns a "invalid_poo" status. 678 4. The LURK Server processes the base structure as described in 679 Section 4.4 681 5. The LURK Server generates the signed_params. 683 Error are expected to provide the LURK Client an indication of the 684 cause that resulted in the error. When an error occurs the LURK 685 Server MAY ignore the request, or provide more generic error codes 686 such as "undefined_error" or "invalid_format". 688 7. capabilities 690 A exchange of type "capabilities" enables the LURK Client to be 691 informed of the supported operations performed by the LURK Server. 692 The supported parameters are provided on a per type basis. 694 7.1. Request Payload 696 A LURK "capabilities" request has no payload. 698 7.2. Response Payload 700 The "capabilities" response payload lists for each supported type, 701 the supported certificates, the supported signatures and hash 702 associated. The "capabilities" payload has the following structure: 704 struct{ 705 CertificateType certificate_type // RFC8442 section 4.4.2 706 select (certificate_type) { 707 case RawPublicKey: 708 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 709 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 710 case X509: 711 opaque cert_data<1..2^24-1>; 712 }; 713 } TypedCertificate; 715 struct { 716 KeyPairID key_id_type_list<0..255>; 717 TypedCertificate typed_certificate_list<0..255> 718 FreshnessFunctList freshness_funct_list<0..255> 719 CipherSuites cipher_suite_list<0..255> 720 PRFHash prf_hash_list<0..255> 721 } TLS12RSACapability; 723 struct { 724 KeyPairID key_id_type_list<0..255>; 725 TypedCertificate typed_certificate_list<0..255> 726 FreshnessFunctList freshness_funct_list<0..255> 727 CipherSuites cipher_suite_list<0..255> 728 SignatureAndHashAlgorithm sig_and_hash_list<0..255> 729 NameCurve ecdsa_curves_list<0..255>; 730 NameCurve ecdhe_curves_list<0..255> 731 POOPRF poo_prf_list<0..255> 732 } TLS12ECDHECapability; 734 struct { 735 uint32 length; 736 TLS12Type type 737 Select( type ) { 738 case rsa_master : TLS12RSACapability, 739 case rsa_master_with_poh : TLS12RSACapability, 740 case rsa_extended_master : TLS12RSACapability, 741 case rsa_extended_master_with_poh : TLS12RSACapability, 742 case ecdhe : TLS12ECDHECapability 743 } capability ; 744 } TLS12Capability 746 struct { 747 TLS12Capability capability_list; 748 opaque state<32>; 749 } TLS12CapabilitiesResponsePayload; 751 typed_certificate enables to contain authentication credentials of 752 various type, such as X09 certificate or raw public key. While 753 different, the structure is similar of CertificateEntry defined in 754 [RFC8446] section 4.4.2 as well as the Certificate structure 755 defined in [RFC7250]. 757 key_id_type_list the supported key_id_type. 759 freshness_funct_list designates the list of freshness_funct ( see 760 Section 4.1). 762 certificate_list designates the certificates associated to message 763 type. The format is similar but different from the 764 CertificateEntry defined in [RFC8446] in section 4.4.2 and 765 [RFC7250] section 1. The CertificateBis format enables the use of 766 X509 as well as Raw Public key, while the Certificate structure 767 defined in [RFC5246] section 7.4.2 does not. 769 sig_and_hash_list designates supported signature algorithms as well 770 as PRF used for the different operations. The format is defined 771 in [RFC5246] section 7.4.1.4.1. 773 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 * 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 * 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 * 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 Work in Progress, Internet-Draft, draft-erb-lurk-rsalg-01, 1349 28 May 2016, . 1352 [I-D.fieau-cdni-https-delegation] 1353 Fieau, F., Stephan, E., and S. Mishra, "HTTPS delegation 1354 in CDNI", Work in Progress, Internet-Draft, draft-fieau- 1355 cdni-https-delegation-02, 3 July 2017, 1356 . 1359 [I-D.ietf-acme-acme] 1360 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1361 Kasten, "Automatic Certificate Management Environment 1362 (ACME)", Work in Progress, Internet-Draft, draft-ietf- 1363 acme-acme-18, 20 December 2018, 1364 . 1367 [I-D.ietf-acme-star] 1368 Sheffer, Y., Lopez, D., Dios, O. G. D., Perales, A. A. P., 1369 and T. Fossati, "Support for Short-Term, Automatically 1370 Renewed (STAR) Certificates in the Automated Certificate 1371 Management Environment (ACME)", Work in Progress, 1372 Internet-Draft, draft-ietf-acme-star-11, 24 October 2019, 1373 . 1376 [I-D.mglt-lurk-lurk] 1377 Migault, D., "LURK Protocol version 1", Work in Progress, 1378 Internet-Draft, draft-mglt-lurk-lurk-00, 9 February 2018, 1379 . 1382 [I-D.mglt-lurk-tls-use-cases] 1383 Migault, D., J, K. M., Salz, R., Mishra, S., and O. G. D. 1384 Dios, "LURK TLS/DTLS Use Cases", Work in Progress, 1385 Internet-Draft, draft-mglt-lurk-tls-use-cases-02, 28 June 1386 2016, . 1389 [I-D.rescorla-tls-subcerts] 1390 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 1391 "Delegated Credentials for TLS", Work in Progress, 1392 Internet-Draft, draft-rescorla-tls-subcerts-02, 30 October 1393 2017, . 1396 [I-D.sheffer-acme-star-request] 1397 Sheffer, Y., Lopez, D., Dios, O. G. D., Perales, A. A. P., 1398 and T. Fossati, "Generating Certificate Requests for 1399 Short-Term, Automatically-Renewed (STAR) Certificates", 1400 Work in Progress, Internet-Draft, draft-sheffer-acme-star- 1401 request-02, 29 June 2018, 1402 . 1405 [RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero-Knowledge 1406 Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, 1407 . 1409 Authors' Addresses 1411 Daniel Migault 1412 Ericsson 1413 8275 Trans Canada Route 1414 Saint Laurent, QC 4S 0B6 1415 Canada 1417 Email: daniel.migault@ericsson.com 1419 Ioana Boureanu 1420 University of Surrey 1421 Stag Hill Campus 1422 Guildford 1423 GU2 7XH 1424 United Kingdom 1426 Email: i.boureanu@surrey.ac.uk