idnits 2.17.00 (12 Aug 2021) /tmp/idnits46472/draft-mglt-lurk-tls13-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 34 instances of too long lines in the document, the longest one being 33 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 445 has weird spacing: '...ntHello or ...' == Line 768 has weird spacing: '... empty indic...' == Line 770 has weird spacing: '...erprint a 4 b...' == Line 1189 has weird spacing: '... tag is def...' == Line 1197 has weird spacing: '...hemeral is de...' == (20 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * (c) The TLS Certificate structure MUST not be provided by the LURK client as part of the handshake structure. Instead, the CS generates the Certificate message from the certificate structure described in Section 5.7. The handshake MUST NOT contain a TLS Certificate message and CS SHOULD raise an invalid_handshake_error if such message is found in the TLS handshake. When a client Certificate is provided, the CS SHOULD raise an invalid_handshake error in the absence of a CertificateRequest message. -- The document date (26 July 2021) is 292 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NewSessionTicket' is mentioned on line 2156, but not defined == Outdated reference: A later version (-01) exists of draft-mglt-lurk-lurk-00 == Outdated reference: A later version (-05) exists of draft-mglt-lurk-tls12-04 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). 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 26 July 2021 5 Expires: 27 January 2022 7 LURK Extension version 1 for (D)TLS 1.3 Authentication 8 draft-mglt-lurk-tls13-05 10 Abstract 12 This document describes the LURK Extension 'tls13' which enables 13 interactions between a LURK client and a LURK server in a context of 14 authentication with (D)TLS 1.3. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 27 January 2022. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4. LURK Header . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 5. Structures . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 5.1. secret_request . . . . . . . . . . . . . . . . . . . . . 7 55 5.2. handshake . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5.3. session_id . . . . . . . . . . . . . . . . . . . . . . . 10 57 5.4. freshness . . . . . . . . . . . . . . . . . . . . . . . . 11 58 5.5. ephemeral . . . . . . . . . . . . . . . . . . . . . . . . 13 59 5.5.1. shared_secret_provided: . . . . . . . . . . . . . . . 13 60 5.5.2. secret_generated: . . . . . . . . . . . . . . . . . . 13 61 5.5.3. no_secret . . . . . . . . . . . . . . . . . . . . . . 14 62 5.6. selected_identity . . . . . . . . . . . . . . . . . . . . 15 63 5.7. certificate . . . . . . . . . . . . . . . . . . . . . . . 16 64 5.8. tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 65 5.9. secret . . . . . . . . . . . . . . . . . . . . . . . . . 19 66 5.10. signature . . . . . . . . . . . . . . . . . . . . . . . . 20 67 6. LURK exchange on the TLS server . . . . . . . . . . . . . . . 20 68 6.1. s_init_cert_verify . . . . . . . . . . . . . . . . . . . 20 69 6.2. s_new_tickets . . . . . . . . . . . . . . . . . . . . . . 21 70 6.3. s_init_early_secret . . . . . . . . . . . . . . . . . . . 22 71 6.4. s_hand_and_app_secret . . . . . . . . . . . . . . . . . . 23 72 7. LURK exchange on the TLS client . . . . . . . . . . . . . . . 24 73 7.1. c_init_post_hand_auth . . . . . . . . . . . . . . . . . . 26 74 7.2. c_post_hand_auth . . . . . . . . . . . . . . . . . . . . 28 75 7.3. c_init_cert_verify . . . . . . . . . . . . . . . . . . . 28 76 7.4. c_init_client_hello . . . . . . . . . . . . . . . . . . . 30 77 7.5. c_client_hello . . . . . . . . . . . . . . . . . . . . . 32 78 7.6. c_hand_and_app_secret . . . . . . . . . . . . . . . . . . 33 79 7.7. c_register_tickets . . . . . . . . . . . . . . . . . . . 35 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 37 85 11.2. Informative References . . . . . . . . . . . . . . . . . 37 86 Appendix A. Annex . . . . . . . . . . . . . . . . . . . . . . . 37 87 A.1. TLS server ECDHE (no session resumption) . . . . . . . . 37 88 A.1.1. ecdhe generated on the CS . . . . . . . . . . . . . . 39 89 A.1.2. ecdhe generated by the TLS server . . . . . . . . . . 39 90 A.2. TLS server ECDHE ( with session resumption ) . . . . . . 40 91 A.3. TLS server PSK / PSK-ECDHE . . . . . . . . . . . . . . . 42 92 A.4. TLS client unauthenticated ECDHE . . . . . . . . . . . . 45 93 A.5. TLS client unauthenticated PSK / PSK-ECDHE . . . . . . . 49 94 A.6. TLS client authenticated ECDHE . . . . . . . . . . . . . 50 95 A.6.1. (EC)DHE or Proposed PSK protected by the CS . . . . . 51 96 A.6.2. (EC)DHE provided by the TLS client . . . . . . . . . 52 97 A.7. TLS client authenticated - post handshake 98 authentication . . . . . . . . . . . . . . . . . . . . . 53 99 A.7.1. Initial Post Handshake Authentication . . . . . . . . 54 100 A.7.2. Post Handshake Authentication . . . . . . . . . . . . 54 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 55 103 1. TODO 105 1. check the terminology is used. PSK agreed.... 107 2. move the handshake description to the s_exchange description 108 description 110 3. state diagram for the server. 112 2. Introduction 114 This document defines a LURK extension for TLS 1.3 [RFC8446]. 116 This document assumes the reader is familiar with TLS 1.3 the LURK 117 architecture [I-D.mglt-lurk-lurk]. 119 Interactions with the Cryptographic Service (CS) can be performed by 120 the TLS client as well as by the TLS server. 122 LURK defines an interface to a CS that stores the security 123 credentials which include the PSK involved in a PSK or PSK-ECDHE 124 authentication or the key used for signing in an ECDHE 125 authentication. In the case of session resumption the PSK is derived 126 from the resumption_master_secret during the key schedule [RFC8446] 127 section 7.1, this secret MAY require similar protection or MAY be 128 delegated as in the LURK extension of TLS 1.2 [I-D.mglt-lurk-tls12]. 130 The current document extends the scope of the LURK extension for TLS 131 1.2 in that it defines the CS on the TLS server as well as on the TLS 132 client and the CS can operate in non delegating scenarios. 134 This document defines the role to specify whether the CS runs on a 135 TLS client or a TLS service. The CS MUST be associated a single 136 role. 138 From a LURK client perspective, the purpose of the LURK exchange is 139 to request secrets, a signing operations, or ticket 140 (NewSessionTicket) as summed up in Table Figure 1. 142 +--------+-----------------------+------------------------+ 143 | Role | LURK exchange | secret | sign | ticket | 144 +--------+-----------------------+--------+------+--------+ 145 | server | s_init_early_secret | yes | - | - | 146 | server | s_init_cert_verify | yes | yes | - | 147 | server | s_hand_and_app_secret | yes | - | - | 148 | server | s_new_ticket | yes | - | yes | 149 | client | c_init_post_hand_auth | - | yes | - | 150 | client | c_post_hand_auth | - | yes | - | 151 | client | c_init_cert_verify | yes | yes | - | 152 | client | c_init_early_secret | yes | - | - | 153 | client | c_init_hand_secret | yes | - | - | 154 | client | c_hand_and_app_secret | yes | - | - | 155 | client | c_register_tickets | yes | - | yes | 156 +--------+-----------------------+--------+------+--------+ 158 Figure 1: Operation associated to LURK exchange 160 The number of operations are limited, but the generation of secrets, 161 tickets as well as signing heavily rely on the knowledge of the TLS 162 handshake messages and in turn impacts these TLS handshake messages. 163 As a result, these operations are highly inter-dependent. This is 164 one reason multiple sequential exchanges are needed between the LURK 165 client and the CS as opposed to independent requests for secrets, 166 signing or tickets. This especially requires the necessity to create 167 a session between the LURK client and the CS. In addition, the LURK 168 client and the CS need to synchronize the TLS handshake. First it is 169 a necessary component for the CS to generate the secrets, signature 170 and tickets. Second, elements are respectively generated by the LURK 171 client and by the CS. 173 While all these messages do share a lot of structures, they also 174 require different structure that make them unique. 176 3. Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in 181 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 This document uses the terms defined [RFC8446] and 185 [I-D.mglt-lurk-tls12]. 187 ECHDE designates the ECDHE authentication defined in [RFC8446]. 188 (EC)DHE 189 designates the shared secret agreed by the key_share extension 190 (section 4.2.8 of [RFC8446]) during a TLS handshake. 192 PSK Proposed A TLS handshake between a TLS client and a TLS server 193 is said to be "PSK proposed" when the latest ClientHello contains 194 a psk_key_exchange_modes (section 4.2.9 of [RFC8446]) and a 195 pre_shared_key (section 4.2.11 of [RFC8446]) extension. A TLS 196 client is said to "propose PSK" when its TLS handshake is PSK 197 proposed. 199 PSK Agreed A TLS handshake between a TLS client and a TLS server is 200 said to be "PSK agreed" when the TLS handshake is PSK proposed and 201 the ServerHello contains a psk_key_exchange_modes and a 202 pre_shared_key extension. A TLS client and a TLS server are said 203 to have "agreed on PSK" when its TLS handshake is PSK agreed. 205 ECDHE Agreed A TLS handshake between a TLS client and a TLS server 206 is said to be "ECDHE agreed" when the ServerHello contains neither 207 a psk_key_exchange_modes or a pre_shared_key extension. As 208 currently TLS proposes only ECDHE and PSK based authentication, 209 when PSK agreed is false, ECDHE agreed is true. A TLS client and 210 a TLS server are said to have "agreed on ECDHE" when its TLS 211 handshake is PSK agreed. 213 Key Share Proposed A TLS handshake between a TLS client and a TLS 214 server is said to be "key shared proposed" or "(EC)DHE proposed" 215 when the latest ClientHello contains a key_share extension 216 (section 4.2.8 of [RFC8446]). A TLS client is said to "propose 217 PSK" when its TLS handshake is PSK proposed. 219 Key Share Agreed A TLS handshake between a TLS client and a TLS 220 server is said to be "key shared agreed" or "(EC)DHE agreed" when 221 the TLS handshake is key shared proposed and the ServerHello 222 contains neither a key_share extension. A TLS client and a TLS 223 server are said to have "agreed on (EC)DHE" when its TLS handshake 224 is key share agreed. 226 Early Data Enabled A TLS client is said to "support early data" or 227 "enable early data" when its latest ClientHello contains a 228 early_data extension (section 4.2.10 of [RFC8446]. 230 Post Handshake Enabled: A TLS client is said to "support early data" 231 or "enable early data" when its latest ClientHello contains a 232 post_handshake_auth extension. 234 4. LURK Header 236 LURK / TLS 1.3 is a LURK Extension that introduces a new designation 237 "tls13". This document assumes that Extension is defined with 238 designation set to "tls13" and version set to 1. The LURK Extension 239 extends the LURKHeader structure defined in [I-D.mglt-lurk-lurk] as 240 follows: 242 enum { 243 tls13 (2), (255) 244 } Designation; 246 enum { 247 capabilities(0), 248 ping(1), 249 s_init_cert_verify(2), 250 s_new_ticket(3), 251 s_init_early_secret(4), 252 s_hand_and_app_secret(5), 253 c_binder_key(6), 254 c_init_early_secret(7), 255 c_init_hand_secret(8), 256 c_hand_secret(9), 257 c_app_secret(10), 258 c_cert_verify(11), 259 c_register_tickets(12), 260 c_post_hand(13), (255) 261 }TLS13Type; 263 enum { 264 // generic values reserved or aligned with the 265 // LURK Protocol 266 request (0), success (1), undefined_error (2), 267 invalid_payload_format (3), 269 invalid_psk 270 invalid_freshness 272 invalid_request 273 invalid_key_id_type 274 invalid_key_id 275 invalid_signature_scheme 276 invalid_certificate_type 277 invalid_certificate 278 invalid_certificate_verify 279 invalid_secret_request 280 invalid_handshake 281 invalid_extension 282 invalid_ephemeral 283 invalid_identity 284 too_many_identities 286 }TLS13Status 288 struct { 289 Designation designation = "tls13"; 290 int8 version = 1; 291 } Extension; 293 struct { 294 Extension extension; 295 select( Extension ){ 296 case ("tls13", 1): 297 TLS13Type; 298 } type; 299 select( Extension ){ 300 case ("tls13", 1): 301 TLS13Status; 302 } status; 303 uint64 id; 304 unint32 length; 305 } LURKHeader; 307 5. Structures 309 This section describes structures that are widely re-used across the 310 multiple LURK exchanges. 312 5.1. secret_request 314 secret_request is a 16 bit structure described in Table Figure 2 that 315 indicates the requested key or secrets by the LURK client. The 316 secret_request structure is present in the request of any exchange 317 except for a c_post_hand exchange. The same structure is used across 318 all LURK exchanges, but each LURK exchange only permit a subset of 319 values described in Table Figure 3. 321 A LURK client MUST NOT set secret_request to key or secrets that are 322 not permitted. The CS MUST check the secret_request has only 323 permitted values and has all mandatory keys or secrets set. If these 324 two criteria are not met the CS MUST NOT perform the LURK exchange 325 and SHOULD return a invalid_secret_request error. If the CS is not 326 able to compute an optional key or secret, the CS MUST proceed the 327 LURK exchange and ignore the optional key or secret. 329 +------+-------------------------------------------+ 330 | Bit | key or secret (designation) | 331 +------+-------------------------------------------+ 332 | 0 | binder_key (b) | 333 | 1 | client_early_traffic_secret (e_c) | 334 | 2 | early_exporter_master_secret (e_x) | 335 | 3 | client_handshake_traffic_secret (h_c) | 336 | 4 | server_handshake_traffic_secret (h_s) | 337 | 5 | client_application_traffic_secret_0 (a_c) | 338 | 6 | server_application_traffic_secret_0 (a_s) | 339 | 7 | exporter_master_secret (x) | 340 | 8 | resumption_master_secret (r) | 341 | 9-15 | reserved and set to zero | 342 +------+-------------------------------------------+ 344 Figure 2: secret_request structure 346 +-----------------------+-----------------------------+ 347 | LURK exchange | Permitted secrets | 348 +-----------------------+-----------------------------+ 349 | s_init_cert_verify | h_c*, h_s*, a_c*, a_s*, x* | 350 | s_new_ticket | r* | 351 | s_init_early_secret | b,e_c*, e_x* | 352 | s_hand_and_app_secret | h_c, h_s, a_c*, a_s*, x* | 353 | c_init_post_hand_auth | - | 354 | c_post_hand_auth | - | 355 | c_init_cert_verify | a_c*, a_s*, x* | 356 | c_init_client_hello | b*, e_c*, e_x* | 357 | c_client_hello | b*, e_c*, e_x* | 358 | c_hand_and_app_secret | h_c, h_s, a_c*, a_s*, x*, r*| 359 | c_register_tickets | - | 360 +-----------------------+-----------------------------+ 361 * indicates the secret MAY be requested 362 - indicates no secrets van be requested 364 Figure 3: secret_request permitted values per LURK exchange 366 5.2. handshake 368 The derivation of the secrets, signing operation and tickets requires 369 the TLS handshake. The TLS handshake is described in [RFC8446] 370 section 4 and maintained by the TLS server and the TLS client to 371 derive the same secrets. As the CS is in charge is deriving the 372 secrets as well to perform some signature verification, the CS must 373 be be aware of the TLS handshake. The TLS handshake is not 374 necessarily being provided by the LURK client to the CS, but instead 375 is derived some structures provided by the LURK client as well as 376 other structures generated or modified by the CS. 378 When an unexpected handshake context is received, the CS SHOULD 379 return an invalid_handshake error. 381 The value of the TLS hanshake is defined in [RFC8446] section 4 and 382 remainded in Table Figure 4 reminds the TLS handshake values after 383 each LURK exchange and describes operations performed by the CS in 384 order to build it. 386 On the TLS server: 388 * (a) ServerHello.random value provided by the LURK client requires 389 specific treatment as described in Section 5.4 before being 390 inserted in the TLS handshake variable. 392 * (b) When the shared secret ( and so the private ECDHE ) is 393 generated by the CS, the KeyShareServerHello structure cannot be 394 provided to the CS by the LURK client in a ServerHello and is 395 instead completed by the CS as described in Section 5.5. 397 * (c) The TLS Certificate structure MUST not be provided by the LURK 398 client as part of the handshake structure. Instead, the CS 399 generates the Certificate message from the certificate structure 400 described in Section 5.7. The handshake MUST NOT contain a TLS 401 Certificate message and CS SHOULD raise an invalid_handshake_error 402 if such message is found in the TLS handshake. When a client 403 Certificate is provided, the CS SHOULD raise an invalid_handshake 404 error in the absence of a CertificateRequest message. 406 * (d) The Certificate and Finished messages are not provided in a 407 handshake structure by the LURK client but are instead generated 408 by the CS as described in Section 5.10. 410 * (e) Some authentication PSK_ECHDE or ECDHE requires the agreement 411 of a shared ECDHE secret. This is indicated by the presence of 412 key_share extension in both ClientHello and ServerHello. When 413 these extensions are not found, the CS SHOULD raise an error. 414 Note that in the case of PSK / PSK-ECDHE, the presence or absence 415 of key_share extension MAY be used to distinguish between the two 416 authentication methods. 418 * (f) ECDHE authentication does not involve the agreement of a PSK. 419 This is indicated by the presence of a key_share extension in both 420 ClientHello and ServerHello. When these extensions are found, the 421 CS SHOULD raise an error. 423 * (g) PSK and PSK_ECDHE requires the agreement of a PSK, so a psk is 424 expected in the ClientHello as well as - when present in the 425 ServerHello. When this extension are not found, the CS SHOULD 426 raise an error. 428 +-----------------------+------------------------------------+---------------+ 429 | LURK exchange | TLS handshake | CS operations | 430 +-----------------------+------------------------------------+---------------+ 431 | s_init_cert_verify | ClientHello ... later of | a,b,c,d,e,f | 432 | | server EncryptedExtensions / | | 433 | | CertificateRequest | | 434 | s_new_ticket | earlier of client Certificate / | c | 435 | | client CertificateVerify / | | 436 | | Finished ... Finished | | 437 | s_init_early_secret | ClientHello | a, g | 438 | s_hand_and_app_secret | ServerHello ... later of | b, g | 439 | | server EncryptedExtensions / | | 440 | | CertificateRequest | | 441 | c_init_post_hand_auth | ClientHello ... ServerHello | e | 442 | | CertificateRequest | | 443 | c_post_hand_auth | CertificateRequest | | 444 | c_init_cert_verify | ClientHello...server Finished | e,f | 445 | c_init_client_hello | (Partial) ClientHello or | | 446 | | ClientHello, HelloRetryRequest, | | 447 | | (Partial) ClientHello | | 448 | c_client_hello | HelloRetryRequest, (Partial) ClientHello | 449 | c_hand_and_app_secret | ServerHello, {EncryptedExtensions} | | 450 | | ... later of { server Finished } / | | 451 | | EndOfEarlyData | | 452 | c_register_tickets | - | | 453 +-----------------------+------------------------------------+---------------+ 455 Figure 4: handshake values per LURK exchange 457 Handshake handshake<0..2^32> //RFC8446 section 4 (clear) clientHello...client finished CertificateRequest 459 5.3. session_id 461 The session_id is a 32 bit identifier that identifies a LURK session 462 between a LURK client and a CS. Unless the exchange is sessionless, 463 the session_id is negotiated at the initiation of the LURK session 464 where the LURK client (resp. the CS) indicates the value to be used 465 for inbound session_id in the following LURK exchanges. For other 466 LURK exchanges, the session_id is set by the sender to the inbound 467 value provided by the receiving party. When the CS receives an 468 unexpected session_id the CS SHOULD return an invalid_session_id 469 error. 471 Table Figure 5 indicates the presence of the session_id. 473 +-----------------------+------------+ 474 | LURK exchange | session_id | 475 +-----------------------+------------+ 476 | s_init_cert_verify | * | 477 | s_new_ticket | y | 478 | s_init_early_secret | y | 479 | s_hand_and_app_secret | y | 480 | c_init_post_hand_auth | * | 481 | c_post_hand_auth | y | 482 | c_init_cert_verify | * | 483 | c_init_client_hello | y | 484 | c_client_hello | y | 485 | c_hand_and_app_secret | y | 486 | c_register_tickets | y | 487 +-----------------------+------------+ 489 y indicates the session_id is present 490 - indicates session_id may be absent 491 * indicates session_id may be present (depending on the tag.last_message) 493 Figure 5: session_id in LURK exchanges 495 The session_id structure is defined below: ~~~ uint32 session_id ~~~ 497 5.4. freshness 499 The freshness function implements perfect forward secrecy (PFS) and 500 prevents replay attack. On the TLS server, the CS generates the 501 ServerHello.random of the TLS handshake that is used latter to derive 502 the secrets. The ServerHello.random value is generated by the CS 503 using the freshness function and the ServerHello.random provided by 504 the LURK client in the handshake structure. The CS operates 505 similarly on the TLS client and generates the ClientHello.random of 506 the TLS handshake using the freshness function as well as the 507 ClientHello.random value provided by the LURK client in the handshake 508 structure. 510 If the CS does not support the freshness, the CS SHOULD return an 511 invalid_freshness error. In this document the freshness function is 512 implemented by applying sha256. 514 Table {table:freshness} details the exchanges that contains the 515 freshness structure. 517 +-----------------------+-----------+ 518 | LURK exchange | freshness | 519 +-----------------------+-----------+ 520 | s_init_cert_verify | y | 521 | s_new_ticket | - | 522 | s_init_early_secret | - | 523 | s_hand_and_app_secret | y | 524 | c_init_post_hand_auth | y | 525 | c_post_hand_auth | - | 526 | c_init_cert_verify | y | 527 | c_init_client_hello | y | 528 | c_client_hello | - | 529 | c_hand_and_app_secret | - | 530 | c_register_tickets | - | 531 +-----------------------+-----------+ 533 y indicates freshness is present 534 - indicates freshness is absent 536 Figure 6: freshness in LURK exchange 538 The extension data is defined as follows: 540 enum { sha256(0) ... (255) } Freshness; 542 When the CS is running on the TLS server, the ServerHello.random is 543 generated as follows: 545 server_random = ServerHello.random 546 ServerHello.random = freshness( server_random + "tls13 pfs srv" ); 548 When the CS is running on the TLS client, the ClientHello.random is 549 generated as follows: 551 client_random = ClientHello.random 552 ClientHello.random = freshness( client_random + "tls13 pfs clt" ); 554 The server_random (resp client_random) MUST be deleted once it has 555 been received by the CS. In some cases, especially when the TLS 556 client enables post handshake authentication and interacts with the 557 CS via a (c_init_post_hand_auth) exchange, there might be some delay 558 between the ClientHello is sent to the server and the Handshake 559 context is shared with the CS. The client_random MUST be kept until 560 the post-handshake authentication is performed as the full handshake 561 is provided during this exchange. 563 5.5. ephemeral 565 The Ephemeral structure carries the necessary information to generate 566 the (EC)DHE shared secret used to derive the secrets. This document 567 defines the following ephemeral methods to generate the (EC)DHE 568 shared secret: 570 * secret_provided: Where (EC)DHE keys and shared secret are 571 generated by the TLS server and provided to the CS 573 * secret_generated: Where the (EC)DH keys and shared secret are 574 generated by the CS. 576 * no_secret: where no (EC)DHE is involved, and PSK authentication is 577 performed. 579 5.5.1. shared_secret_provided: 581 When ECDHE shared secret are generated by the TLS server, the LURK 582 client provides the shared secret value to the CS. The shared secret 583 is transmitted via the SharedSecret structure, which is similar to 584 the key_exchange parameter of the KeyShareEntry described in The CS 585 MUST NOT return any data.[RFC8446] section 4.2.8. 587 struct { 588 NamedGroup group; 589 opaque shared_secret[coordinate_length]; 590 } SharedSecret; 592 Where coordinate_length depends on the chosen group. For secp256r1, 593 secp384r1, secp521r1, x25519, x448, the coordinate_length is 594 respectively 32 bytes, 48 bytes, 66 bytes, 32 bytes and 56 bytes. 595 Upon receiving the shared_secret, the CS MUST check group is proposed 596 in the KeyShareClientHello and agreed in the KeyShareServerHello. 598 5.5.2. secret_generated: 600 When the ECDHE public/private keys are generated by the CS, the LURK 601 client requests the CS the associated public value. Note that in 602 such cases the CS would receive an incomplete Handshake Context from 603 the LURK client with the public part of the ECDHE missing. Typically 604 the ServerHello message would present a KeyShareServerHello that 605 consists of a KeyShareEntry with an empty key_exchange field, but the 606 field group is present. 608 The CS MUST check the group field in the KeyShareServerHello, and get 609 the public value of the TLS client from the KeyShareClientHello. The 610 CS performs the same checks as described in [RFC8446] section 4.2.8. 612 The CS generates the private and public (EC)DH keys, computes the 613 shared key and return the KeyShareEntry server_share structure 614 defined in [RFC8446] section section 4.2.8 to the LURK client. 616 5.5.3. no_secret 618 With PSK authentication, (EC)DHE keys and shared secrets are not 619 needed. The CS SHOULD check the PSK authentication has been agreed, 620 that is pre_shared_key and psk_key_exchamge_modes extensions are noth 621 present in the ClientHello and in the ServerHello 623 When the ephemeral method or the group is not supported, the CS 624 SHOULD return an invalid_ephemeral error. 626 +-----------------------+-----------+---------------------------+ 627 | | | ephemeral_method= secret | 628 | LURK exchange | ephemeral | no | provided | generated | 629 +-----------------------+-----------+----+----------+-----------+ 630 | s_init_cert_verify | y+ | - | y | y | 631 | s_new_ticket | - | - | - | - | 632 | s_init_early_secret | - | - | - | - | 633 | s_hand_and_app_secret | y | y | y | y | 634 | c_init_post_hand | y | - | y | - | 635 | c_post_hand | y | - | y | y | 636 | c_init_cert_verify | y | - | y | y | 637 | c_init_client_hello | y | y | - | y | 638 | c_client_hello | y | y | - | y | 639 | c_hand_and_app_secret | y | y | y | - | 640 | c_register_tickets | - | - | - | - | 641 +-----------------------+-----------+----+----------+-----------+ 643 y indicates presence of ephemeral or possible value for ephemeral_method 644 - indicates absent or ephemeral or incompatible value for ephemeral_method 646 Figure 7: Ephemeral field in LURK exchange 648 The extension data is defined as follows: 650 enum { no_secret (0), secret_provided(1), secret_generated(2) (255)} EphemeralMethod; 652 EphemeralRequest { 653 EphemeralMethod method; 654 select(method) { 655 case secret_provided: 656 SharedSecret shared_secret<0..2^16>; 657 } 658 } 660 EphemeralResponse { 661 select(method) { 662 case secret_generated: 663 KeyShareEntry server_share 664 } 665 } 667 5.6. selected_identity 669 The selected_identity indicates the identity of the PSK used in the 670 key schedule. The selected_identity is expressed as a (0-based) 671 index into the identities in the client's list. The client's list is 672 provided in the pre_shared_key extension as expressed in [RFC8446] 673 section 4.2.11. 675 The LURK client MUST provide the selected_identity only when PSK or 676 PSK-authentication is envisioned and when the PSK has not been 677 provided earlier. These exchanges are s_init_early_secret on the TLS 678 server and c_init_early_secret and c_init_hand_secret on the TLS 679 client side. 681 +-----------------------+-----+ 682 | LURK exchange | req | 683 +-----------------------+-----+ 684 | s_init_cert_verify | - | 685 | s_new_ticket | - | 686 | s_init_early_secret | y | 687 | s_hand_and_app_secret | - | 688 | c_init_post_hand_auth | - | 689 | c_post_hand_auth | - | 690 | c_init_cert_verify | - | 691 | c_init_client_hello | - | 692 | c_client_hello | - | 693 | c_hand_and_app_secret | - | 694 | c_register_tickets | - | 695 +-----------------------+-----+ 697 y indicates the selected_identity is present 698 - indicates the selected_identity is absent 700 Figure 8: psk_id in LURK exchange 702 The extension data is defined as follows: 704 uint16 selected_identity; //RFC8446 section 4.2.11 706 The CS retrieve the PSK identity from the ClientHello and SHOULD send 707 an invalid_psk error if an error occurs. If the PSK is not provided, 708 a default PSK is generated as described in [RFC8446] section 7.1. If 709 the default PSK is not allowed then an invalid_psk is returned. 711 5.7. certificate 713 The certificate structure indicates the presence and associated value 714 of the Certificate message in the TLS handshake. 716 Upon receiving a certificate field, the CS MUST: 1. ensure coherent 717 with the handshake messages - typically authentication method is 718 ECDHE and not PSK or PSK-ECDHE. 2. ensure the provided value 719 corresponds to an acceptable provisioned value. 3. generate the 720 appropriated corresponding message. 722 If the CS is not able to understand the lurk_tls13_certificate field, 723 it SHOULD return an invalid_certificate error. 725 Table Figure 9 indicates the presence of that field in the LURK 726 exchanges. 728 +-----------------------+-------------+--------------------+ 729 | LURK exchange | certificate | certificate type | 730 +-----------------------+-------------+--------------------+ 731 | s_init_cert_verify | y | server certificate | 732 | s_new_ticket | * | client certificate | 733 | s_init_early_secret | - | | 734 | s_hand_and_app_secret | - | | 735 | c_init_post_hand_auth | y | client_certificate | 736 | c_post_hand_auth | y | client_certificate | 737 | c_init_cert_verify | y | client certificate | 738 | c_init_client_hello | - | | 739 | c_client_hello | - | | 740 | c_hand_and_app_secret | y | client_certificate | 741 | c_register_tickets | - | | 742 +-----------------------+-------------+--------------------+ 744 * indicates certificate type MAY be set to emtpy. 745 y indicates certificate type MUST NOT be set to empty 746 - indicates the certificate structure is absent 748 Figure 9: certificate per LURK exchange 750 There are different ways the LURK client can provide the certificate 751 message: 753 enum { empty(0), finger_print(1), uncompressed(2), (255) 754 }; LURKTLS13CertificateType 756 struct { 757 LURKTLS13CertificateType certificate_type; 758 select (certificate_type) { 759 case empty: 760 // no payload 761 case finger_print 762 uint32 hash_cert; 763 case uncompressed: 764 Certificate certificate; // RFC8446 section 4.4.2 765 }; 766 } LURKTLS13Certificate; 768 empty indicates there is no certificates provided by this field. 770 fingerprint a 4 bytes finger print length that represents the 771 fingerprinting of the TLS Certificate message. Fingerprinting is 772 described in [RFC7924] and takes as input the full handshake 773 message - that is a message of message type certificate with that 774 contain the Certificate as its message_data. In this document 775 only the 4 most left bytes of the output are considered. 776 uncompressed 778 indicates the Certificate message as defined in [RFC8446] is 779 provided. 781 5.8. tag 783 This field provides extra information. Currently, the tag structure 784 defines tag.last_message and tag.cert_request. 786 The LURK client or the CS sets the tag.last_message to terminate the 787 LURK session. The tag.cert_request is only used by the CS in a 788 c_hand_and_app_secret exchange. The tag.cert_request by the CS when 789 a CertificateRequest has been found in the handshake and that the CS 790 includes in its response the necessary information to the TLS client 791 to build a CertificateVerify message (see Section 7.6 ). 793 In this document, we use setting, setting to True to indicate the bit 794 is set to 1. Respectively, we say unsetting, setting to False to 795 indicate the bit is set to 0. 797 Table Figure 10 indicates the different values carried by the tag as 798 well as the exchange these tags are considered. The bits values MUST 799 be ignored outside their exchange context and bits Bits that are not 800 specified within a given exchange MUST be set to zero by the sender 801 and MUST be ignored by the receiver. 803 +------+----------------+ 804 | Bit | description | 805 +------+----------------+ 806 | 0 | last_exchange | 807 | 1 | cert_request | 808 | 2-7 | RESERVED | 809 +------+----------------+ 811 Figure 10: tag description 813 +-----------------------+--------------+--------------+ 814 | LURK exchange | last_message | cert_request | 815 +-----------------------+--------------+--------------+ 816 | s_init_cert_verify | y | - | 817 | s_new_ticket | y | - | 818 | s_init_early_secret | - | - | 819 | s_hand_and_app_secret | y | - | 820 | c_init_post_hand_auth | y | - | 821 | c_post_hand_auth | y | - | 822 | c_init_cert_verify | y | - | 823 | c_init_client_hello | - | - | 824 | c_client_hello | - | _ | 825 | c_hand_and_app_secret | y | y (response) | 826 | c_register_tickets | y | - | 827 +-----------------------+--------------+--------------+ 829 y indicates tag is present 830 - indicates tag is absent 832 Figure 11: tag per LURK exchange 834 5.9. secret 836 The Secret structure is used by the CS to send the various secrets 837 derived by the key schedule described in [RFC8446] section 7. 839 enum { 840 binder_key (0), 841 client_early_traffic_secret(1), 842 early_exporter_master_secret(2), 843 client_handshake_traffic_secret(3), 844 server_handshake_traffic_secret(4), 845 client_application_traffic_secret_0(5), 846 server_application_traffic_secret_0(6), 847 exporter_master_secret(7), 848 esumption_master_secret(8), 849 (255) 850 } SecretType; 852 struct { 853 SecretType secret_type; 854 opaque secret_data<0..2^8-1>; 855 } Secret; 857 secret_type: The type of the secret or key 859 secret_data: The value of the secret. 861 5.10. signature 863 The signature requires the signature scheme, a private key and the 864 appropriated context. The signature scheme is provided using the 865 SignatureScheme structure defined in [RFC8446] section 4.2.3, the 866 private key is derived from the lurk_tls13_certificate Section 5.7 867 and the context is derived from the handshake Section 5.2 and 868 lurk_tls13_certificate Section 5.7. 870 Signing operations are described in [RFC8446] section 4.4.3. The 871 context string is derived from the role and the type of the LURK 872 exchange as described below. The Handshake Context is taken from the 873 key schedule context. 875 +--------------------+-------------------------------------+ 876 | type | context | 877 +--------------------+-------------------------------------+ 878 | s_init_cert_verify | "TLS 1.3, server CertificateVerify" | 879 | c_cert_verify | "TLS 1.3, client CertificateVerify" | 880 +--------------------+-------------------------------------+ 882 struct { 883 opaque signature<0..2^16-1>; //RFC8446 section 4.4.3. 884 } Signature; 886 6. LURK exchange on the TLS server 888 This section describes the LURK exchanges that are performed on the 889 TLS server. Unless specified used structures are described in 890 Section 5 892 6.1. s_init_cert_verify 894 s_init_cert_verify initiates a LURK session when the server is 895 authenticated with ECDHE. The ClientHello received by the TLS 896 server, and the ServerHello and optionally the HelloRetryRequest MUST 897 carry a key_share extension. 899 If the LURK client is configured to not proceed to further exchange, 900 it sets the last_exchange bit of the tag. When this bit is set, the 901 session_id is ignored. The CS sets the last_exchange bit if the 902 last_exchange bit has been set by the LURK client or when it has been 903 configured to not accept further LURK exchanges, such as 904 s_new_ticket. 906 struct{ 907 uint8 tag; 908 select (tag.last_exchange){ 909 case False: 910 uint32 session_id; 911 } 912 FreshnessFunct freshness; 913 Ephemeral ephemeral; 914 Handshake handshake<0..2^32>; //RFC8446 section 4 915 LURKTLS13Certificate certificate; 916 uint16 secret_request; 917 SignatureScheme sig_algo; //RFC8446 section 4.2.3. 918 }SInitCertVerifyRequest 920 struct{ 921 uint8 tag; 922 select (tag.last_exchange){ 923 case False: 924 uint32 session_id; 925 } 926 Ephemeral ephemeral; 927 Secret secret_list<0..2^16-1>; 928 Signature signature; 929 }SInitCertVerifyResponse 931 sig_algo SignatureScheme is defined in [RFC8446] section 4.2.3. 933 6.2. s_new_tickets 935 new_session ticket handles session resumption. It enables to 936 retrieve NewSessionTickets that will be forwarded to the TLS client 937 by the TLS server to be used later when session resumption is used. 938 It also provides the ability to delegate the session resumption 939 authentication from the CS to the TLS server. In fact, if the LURK 940 client requests and receives the resumption_master_secret it is able 941 to emit on its own NewSessionTicket. As a result s_new_ticket LURK 942 exchanges are only initiated if the TLS server expects to perform 943 session resumption and the CS responds only if if session_resumption 944 is enabled. 946 The CS MAY responds with a resumption_master_secret based on its 947 policies. 949 The LURK client MAY perform multiple s_new_ticket exchanges. The 950 LURK client and CS are expected to advertise by setting the 951 last_exchange bit in the tag field. 953 struct { 954 uint8 tag 955 uint32 session_id 956 Handshake handshake<0..2^32> //RFC8446 section 4. 957 LURKTLS13Certificate certificate; 958 uint8 ticket_nbr; 959 uint16 secret_request; 960 } SNewTicketRequest; 962 struct { 963 uint8 tag 964 uint32 session_id 965 Secret secret_list<0..2^16-1>; 966 NewSessionTicket ticket_list<0..2^16-1>; //RFC8446 section 4.6.1. 967 } SNewTicketResponse; 969 ticket_nbr: designates the requested number of NewSessionTicket. In 970 the case of delegation this number MAY be set to zero. The CS MAY 971 responds with less tickets when the value is too high. 973 6.3. s_init_early_secret 975 s_init_early_secret initiates a LURK session when the server is 976 authenticated by the PSK or PSK-ECDHE methods. This means the 977 ClientHello received by the TLS server and ServerHello responded by 978 the TLS server MUST carry the pre_shared_key and 979 psk_key_exchange_modes extensions. 981 selected_identity indicates the selected PSK 983 struct{ 984 uint32 session_id 985 FreshnessFunct freshness 986 uint16 selected_identity 987 Handshake handshake<0..2^32> //RFC8446 section 4 988 uint16 secret_request; 989 }SInitEarlySecretRequest 991 struct{ 992 uint32 session_id 993 Secret secret_list<0..2^16-1>; 994 }SInitEarlySecretResponse 995 The binder_key MUST be requested, since it is used to validate the 996 PSK. The TLS client MAY indicate support for early application data 997 via the early_data extension. Depending on the TLS server policies, 998 it MAY accept early data and request the client_early_traffic_secret. 999 The TLS server MAY have specific policies and request 1000 early_exporter_master_secret. 1002 The CS MUST check pre_shared_key and psk_key_exchange_modes 1003 extensions are present in the ClientHello message. If these 1004 extensions are not present, a invalid_handshake error SHOULD be 1005 returned. The CS MUST ignore the client_early_traffic_secret if 1006 early_data extension is not found in the ClientHello. The 1007 Cryptographic Service MAY ignore the request for 1008 client_early_traffic_secret or early_exporter_master_secret depending 1009 on configuration parameters. 1011 6.4. s_hand_and_app_secret 1013 The s_hand_and_app_secret is necessary to complete the ServerHello 1014 and always follows an s_init_early_secret LURK exchange. Such 1015 sequence is guaranteed by the session_id. In case of unknown 1016 session_id or an invalid_request error SHOULD be returned. 1018 The LURK client MUST ensure that PSK or PSK-ECDHE authentication has 1019 been selected via the presence of the pre_shared_key extension in the 1020 ServerHello. In addition, the selected identity MUST be the one 1021 provided in the pre_shared_key extension of the previous 1022 s_init_early_secret exchange. The CS MUST also check the selected 1023 cipher in the ServerHello match the one associated to the PSK. The 1024 CS generates the Finished message as described in [RFC8446] section 1025 4.4.4. Which involves the h_s secret. The LURK client MAY request 1026 the exporter_master_secret depending on its policies. The CS MAY 1027 ignore the request based on its policies. 1029 If the LURK client is configured to not proceed to further exchange, 1030 it sets the last_exchange bit of the tag. The CS sets the 1031 last_exchange bit if the last_exchange bit has been set by the LURK 1032 client or when it has been configured to not accept further LURK 1033 exchange. 1035 struct{ 1036 uint8 tag 1037 uint32 session_id 1038 Ephemeral ephemeral 1039 Handshake handshake<0..2^32> //RFC8446 section 4 1040 uint16 secret_request; 1041 } SHandAndAppSecretRequest 1043 struct{ 1044 uint8 tag 1045 uint32 session_id 1046 Ephemeral ephemeral 1047 Secret secret_list<0..2^16-1>; 1048 } SHandAndAppSecretResponse 1050 7. LURK exchange on the TLS client 1052 The CS described in this document considers the case where PSK and 1053 (EC)DHE private part MAY be protected by the CS. This document does 1054 not consider the case where a TLS client may propose a combination of 1055 protected and unprotected PSKs. Either all proposed PSK are 1056 unprotected by the CS or all PSK are protected by the CS. Similarly, 1057 this document does not consider the case where a TLS client may 1058 propose a combination of protected and unprotected (EC)DHE. Either 1059 all (EC)DHE are generated by the CS or all (EC)DHE are generated by 1060 the TLS client. 1062 Figure Figure 12 summarizes the different possible LURK session as 1063 well as the different messages that are involved in the session. 1065 ^ | no 1066 | (EC)DHE in CS or ------------+ 1067 ClientHello | PSK in CS Proposed | 1068 Derivation | yes | | 1069 | c_init_client_hello | 1070 | | no | 1071 | Hello Retry Request --+ | 1072 | yes | | | 1073 ClientHello | c_client_hello | | 1074 sent -->v |<------------+ | 1075 ServerHello-->^ | | no 1076 received | | ECDHE Agreed --+ 1077 | | yes | | 1078 ServerHello | c_hand_and_app_secret c_init_cert_verify| 1079 Treatment | | | | 1080 clientFinished| +-------+------------+ | no 1081 sent -->v | Post Auth Enabled --+ 1082 ^ | + | 1083 | | CertificateRequest | 1084 | | | | 1085 | | c_init_post_hand_auth| 1086 | | | | 1087 |+----------------->|<--------------------+ | 1088 Posthandshake || +---------+-------+ | 1089 Treatment || | | | 1090 ||Post Auth Enabled (EC)DHE in CS or | 1091 || + Agreed PSK in CS | 1092 ||CertificateRequest + | 1093 || | NewSessionTicket | 1094 || | | | 1095 ||c_post_hand_auth c_register_tickets | 1096 || | | | 1097 || +-------+---------+ | 1098 || | | 1099 v+----------------+ +-----+ 1100 | | 1101 LURK session LURK session 1102 closed not initiated 1104 Figure 12: LURK client State Diagram 1106 The TLS client needs to interact with the CS when either the TLS 1107 client proposes PKSs and the CS hosts the PSKs or when the TLS client 1108 requests the CS to generate the (EC)DHE private key. The TLS client 1109 requests with a c_init_client_hello exchange the CS the binder_keys, 1110 the (EC)DHE public part as well as early secrets and is thus able to 1111 start the TLS handshake, that is sending a ClientHello with potential 1112 early data. In case a HeloRetryRequest is received, the TLS client 1113 pursue with a c_client_hello exchange to complete the second 1114 ClientHello. Upon receiving a ServerHello as well as other messages 1115 by the TLS server, the TLS client requests via a 1116 c_hand_and_App_secret exchange the necessary information (signature, 1117 secrets) to complete the TLS handshake. 1119 When the TLS client does not propose PSKs that are protected by the 1120 CS nor does request the CS to generate the private part of the 1121 (EC)DHE shared secret, the TLS client does not need to interact wit 1122 the CS to send its ClientHello. However, the TLS client may interact 1123 with the CS to authenticate itself to the TLS server via the 1124 generation of a signature contained in a CertificateVerify message. 1125 Such authentication can be performed during the TLS handshake when 1126 ECDHE is agreed and when the TLS client enables post handshake 1127 authentication, in which case the signature is requested via a 1128 c_init_cert_verify exchange. 1130 Once the TLS handshake is completed, and the TLS client has enabled 1131 post handshake authentication, the TLS server may request by sending 1132 a CertificateRequest the TLS client to authenticate itself with a 1133 signature. If the TLS client has already started a LURK session 1134 associated to the TLS handshake the signature is requested via a 1135 c_post_hand_auth exchange. Otherwise, the signature is requested via 1136 a c_init_post_hand_auth exchange. Multiple post hand shake 1137 authentication may be performed in both cases and additional 1138 signature generation are requested via c_post_hand_auth exchange. 1140 Similarly, once the TLS handshake is completed, the TLS client may 1141 receive NewSessionTickets from the TLS server to perform session 1142 resumption. If the TLS client has its (EC)DHE or the PSK in use 1143 protected by the CS - the NewSessionTicket is registered via a 1144 c_register_ticket. Multiple NewSessionTickets may be registered. 1145 When no protected PSK have been agreed and (EC)DHE are not generated 1146 by the CS, the TLS client may generate the PSK session resumption. 1147 As a result, it cannot be registered in the CS as to prevent 1148 providing a false sense of security. 1150 7.1. c_init_post_hand_auth 1152 The c_init_post_hand_auth occurs when the TLS client performs post 1153 handshake authentication while no previous interactions occurred 1154 between the TLS client and the CS. More specifically, the (EC)DHE 1155 shared secrets have been generated by the TLS client, and the 1156 proposed keys, if proposed previously by the TLS client, are not 1157 protected by the CS. 1159 The CS completes and returns the signature as described in 1160 Section 5.10. 1162 Since session resumption secrets are not protected by the CS, the 1163 registration of NewSessioinTickets is not expected, and the only 1164 exchanges that MAY follow are additional post handshake 1165 authentications described in Section 7.2. 1167 struct{ 1168 uint8 tag; 1169 select (tag.last_exchange){ 1170 case False: 1171 uint32 session_id; 1172 } 1173 FreshnessFunct freshness; 1174 Ephemeral = ephemeral ## ephemeral_method = secret_provided 1175 Handshake handshake<0..2^32> //RFC8446 section 4 1176 LURKTLS13Certificate cert; 1177 SignatureScheme sig_algo; 1178 }CInitPostHandAuthRequest 1180 struct{ 1181 unit8 tag 1182 select (tag.last_exchange){ 1183 case False: 1184 uint32 session_id; 1185 } 1186 Signature signature 1187 }CInitPostHandAuth 1189 tag is defined in Section 5.8. The TLS client sets tag.last_message 1190 if further post handshake authentications are expected. Similarly 1191 the CS sets the tag.last_message if further post handshake 1192 authentications are permitted. Note that it is out of scope of 1193 this specification to specify the reasons, but it is RECOMMENEDED 1194 the CS sets life time to LURK session as well as limits the 1195 maximum number of post handshake authentications. 1197 ephemeral is defined in Section 5.5 and ephemeral_method MUST be set 1198 to 'secret_provided' when the TLS handshake agreed an ECDHE or a 1199 PSK-ECDHE authentication. The ephemeral_method MUST be set to 1200 'no_secret' when PSK the TLS handshake agreed on PSK 1201 authentication. 1203 handshake is defined in Section 5.2 and post handshake 1204 authentication MUST be enabled by the TLS client. 1206 cert is defined in Section 5.7 and is used by the TLS client to 1207 indicate the expected certificate to be used to compute the 1208 signature as well as the certificate that is expected to be send 1209 further to the TLS server. 1211 sig_algo is defined in Section 5.10 and indicates the selected 1212 algorithm. 1214 signature is defined in Section 5.10. 1216 7.2. c_post_hand_auth 1218 The c_post_hand_auth exchange enables a TLS client to perform post 1219 handshake authentication. 1221 This exchange is followed by a c_register_ticket or a 1222 c_post_hand_and_app exchange. 1224 struct{ 1225 Tag tag 1226 uint32 session_id 1227 Ephemeral = ephemeral ## ephemeral_method = secret_provided 1228 Handshake handshake<0..2^32> // CertificateRequest 1229 LURKTLS13Certificate cert; 1230 SignatureScheme sig_algo; 1231 }CPostHandAuthRequest 1233 struct{ 1234 Tag tag 1235 uint32 session_id 1236 Signature signature 1237 }CPostHandAuth 1239 tag, sig_algo, cert, signature are described in Section 7.1 1241 handshake is defined in Section 5.2 and is only composed of a 1242 CertificateRequest. However, post handshake authentication MUST 1243 be enabled by the TLS client. 1245 7.3. c_init_cert_verify 1247 The c_init_cert_verify exchange occurs when the TLS client is being 1248 requested to authenticate during the TLS handshake. According to 1249 [RFC8446] client authentication during the TLS handshake is not valid 1250 with a PSK or PSK based authentication. As a result, ECHDE needs to 1251 be agreed. In addition, as c_init_cert_verify initiates a LURK 1252 session, the ECDHE shared secrets have been generated by the TLS 1253 client as opposed to the CS. 1255 The CS completes and returns the signature as described in 1256 Section 5.10. When further LURK exchanges are expected, the CS 1257 generates also the Finished message in order to be able to complete 1258 the latter requests for post authentication. 1260 This exchange is followed by a c_post_hand_auth exchange. 1262 struct{ 1263 uint8 tag; 1264 select (tag.last_exchange){ 1265 case False: 1266 uint32 session_id; 1267 } 1268 FreshnessFunct freshness; 1269 Ephemeral ephemeral; 1270 Handshake handshake<0..2^32>; //RFC8446 section 4 1271 LURKTLS13Certificate certificate; 1272 SignatureScheme sig_algo; //RFC8446 section 4.2.3. 1273 }CInitCertVerifyRequest 1275 struct{ 1276 uint8 tag; 1277 select (tag.last_exchange){ 1278 case False: 1279 uint32 session_id; 1280 } 1281 Ephemeral ephemeral; 1282 Signature signature; 1283 }CInitCertVerifyResponse 1285 freshness, session_id are respectively defined in Section 5.4 and 1286 Section 5.3. 1288 tag is defined in Section 5.8. The TLS client that does not expect 1289 an additional post handshake authentication MUST set it 1290 tag.last_message. A consequence is that a TLS client that does 1291 not enable post authentication MUST set the tag.last_message. 1293 The CS MUST set the tag.last_message when the TLS client does not 1294 enabled post handshake authentication or when no further post 1295 handshake authentication is expected. 1297 ephemeral is defined in Section 5.5. The TLS client MUST set the 1298 ephemeral_method to 'secret_provided'. 1300 handshake is defined in Section 5.2 and must be set to ECDHE agreed. 1301 Note that PSK may be proposed if these PSKs are not provisioned in 1302 the CS. The handshake messages are also in clear. 1304 7.4. c_init_client_hello 1306 The c_init_ephemeral_binder exchange occurs when the TLS client needs 1307 to generate the ClientHello as well as the early secrets. In fact 1308 the generation of the ClientHello may require the CS to generates the 1309 (EC)DHE private key and returns the public part as well as the 1310 binder_key to generate the binders. On the other hand, the 1311 generation of the early secrets requires the ClientHello to be 1312 completed. As a result, the CS will be expected to complete the 1313 ClientHello from a potential partial ClientHello. More specifically, 1314 when binders are needed, the partial Client Hello does not contains 1315 the OfferedPsks structure, that is the PreSharedKeyExtension. The 1316 latter structure is simply stripped from the ClientHello, without any 1317 further changes, such as changing the lengths for example. It is 1318 entirely built by the CS and append as the last extension as 1319 described in section 4.2.11 of The reason for having CPskID as 1320 opposed to the identity structure is that nothing prevent identities 1321 of two different NewSessionTickets to be collide. CPskID are managed 1322 by the CS of the TLS client to prevent such collisions and are 1323 provided during the registration of the NewSessionTickets 1324 c_register_tickets (see [RFC8446]. Note that extension_type as well 1325 as the 16 bit length of the OfferedPsks remain present. The 1326 PreSharedKeyExtension structure of the ClientHello is built from a 1327 list of CPskIDs where each CPskID designates a PSK with an identifier 1328 managed by the CS of the TLS client. The PSK can be associated to a 1329 NewSessionTicket in which case the CPskID will be used to designate 1330 the NewSessionTicket and its associate identity 1331 structure.Section 7.7). When the PSK is provisioned, the TLS client 1332 needs to be configured with it. When the CS is not able to generate 1333 the PreSharedKeyExtension an invalid_identity error SHOULD be raised. 1335 Note that when PSK is not proposed or when PSK are not registered in 1336 the CS, the ClientHello is fully provided - without the 1337 PreSharedKeyExtension or with a completed PreSharedKeyExtension 1338 extension. The CS is expected to be able to distinguish between the 1339 two by for example, comparing the length of the handshake provided in 1340 c_init_client_hello and the length indicated in the ClientHello. 1342 Note that (EC)DHE may be generated when ECDHE or PSK-ECDHE 1343 authentication is proposed by the TLS client, while early secrets and 1344 binder_key can only be requested when PSK is proposed. When the TLS 1345 client requests the generation of a (EC)DHE private key, the 1346 KeyShareClietHello MAY contain a list of KeyShareEntry (defined in 1347 section 4.2.8 When an error is found regarding the 1348 KeyShareClientHello, the CS SHOULD raise an invalid_ephemeral error. 1349 Note that according to [RFC8446] ). When provided, these structures 1350 contains the group but are being stripped the key_exchange_value, 1351 while all other fields - including the lengths - are left 1352 unchanged.Section 5.5 when the ephemeral_method is set to 1353 'no_secret', the resulting list is empty. 1355 This exchange is followed by a c_client_hello or a 1356 c_hand_and_app_secret. 1358 struct{ 1359 uint32 c_psk_id 1360 }CPskID 1362 struct{ 1363 uint32 session_id 1364 Freshness freshness 1365 Ephemeral ephemeral ephemeral_method=secret_generate or no_secret 1366 Handshake handshake<0..2^32> //RFC8446 section 4 1367 CPskID c_psk_id_list<0..2^8-1> 1368 uint16 secret_request; 1369 }CInitClientHello 1371 struct{ 1372 uint32 session_id 1373 Ephemeral ephemeral_list<0..2^16-1> 1374 Secret secret_list<0..2^16-1>; 1375 }CInitClientHello 1377 session_id, freshness and ephemeral, secret_request and secret_list 1378 are respectively defined in Section 5.3, Section 5.4, Section 5.5, 1379 Section 5.1 and Section 5.9. 1381 ephemeral is defined in Section 5.5. With a single ClientHello or 1382 partial ClientHello, ephemeral_method is set to secret_generate 1383 when ECDHE and PSK-ECDHE authentication are being proposed or 1384 no_secret when only PSK is proposed or when the ECDHE is generated 1385 by the TLS client. 1387 Note that even though the CLientHello requests multiple 1388 KeyShareENtries, a single ephemeral method is provided. 1390 handshake is defined in Section 5.2. When a partial ClientHello is 1391 provided, PSK or PSK-ECDHE MUST be enabled. When a ClientHello is 1392 provided, PSK or PSK-ECDHE may be proposed but with unprotected 1393 keys. ClientHello, HelloRetryRequest, ClientHello or ClientHello, 1394 HelloRetryRequest, partial ClientHello MAY be provided. However, 1395 there are cases this is not possible, typically when the 1396 HellRequestRetry does not contain a key_share extension, the 1397 (EC)DHE shared secret is generated with the (EC)DHE generated 1398 associated to the first ClientHello. When the (EC)DHE private key 1399 has been generated by the CS, the TLS client MUST use a 1400 c_early_secret LURK exchange as defined in Section 7.5 in order to 1401 ensure the CS is aware of the (EC)DHE shared secret to generate 1402 the further secrets. 1404 c_psk_id designate an 32 bit identifier for a PSK. This identifier 1405 is provided and managed by the CS of the TLS client to avoid 1406 collision of different PSK provided by different TLS servers. 1408 c_psk_id_list designates the list of CPskIDs. The list is used by 1409 the CS to build the OfferedPsks structure - including the 1410 PSKIdentity structure. The list of identities in the OfferedPsks 1411 MUST be the same as the one of the c_psk_id_list. 1413 ephemeral_list When contains the different values of (EC)DHE public 1414 parts - i.e. the KeyShareEntries when the ephemeral_method is set 1415 to secret_generated. When the ephemeral_method is set to 1416 no_secret, the list is an empty list by construction of the 1417 ephemeral structure (see Section 5.5). 1419 7.5. c_client_hello 1421 The c_client_hello exchange occurs after a TLS server responds to a 1422 ClientHello generated using a c_init_client_hello defined in 1423 Section 7.4 is being responded a HelloRetryRequest by the TLS server. 1424 While in some cases, re-initiating a LURK exchange with a 1425 _init_client_hello MAY be considered, this document RECOMMENDS to 1426 proceed as follows when a HelloRetryRequest is received: 1428 * If the first ClientHello has been generated via a 1429 c_init_client_hello, use c_client_hello to generate the second 1430 ClientHello 1432 * If the first ClientHello has not been generated via a 1433 c_init_client_hello, consider generating the second ClientHello 1434 via c_init_client_hello. 1436 This exchange is followed by a c_hand_and_app_secret. 1438 struct{ 1439 uint32 session_id 1440 Freshness freshness 1441 Ephemeral ephemeral ephemeral_method=secret_generate or no_secret 1442 Handshake handshake<0..2^32> //RFC8446 section 4 1443 uint16 secret_request; 1444 }CClientHello 1446 struct{ 1447 uint32 session_id 1448 Ephemeral ephemeral 1449 Secret secret_list<0..2^16-1>; 1450 }CClientHello 1452 session_id, ephemeral, secret_request and secret_list are 1453 respectively defined in Section 5.3, Section 5.5, Section 5.1 and 1454 Section 5.9. 1456 handshake is defined in Section 5.2. The handshake MUST contain a 1457 HelloRetryRequest and a ClientHello or partial ClientHello. The 1458 same restrictions as defined in Section 7.4 apply to the 1459 ClientHello 1461 7.6. c_hand_and_app_secret 1463 The c_hand_and_app_secret exchange occurs after a ServerHello is 1464 received and the TLS client request handshake secrets to decrypt 1465 (resp. encrypt) handshake messages sent by (resp. to) the server. 1466 Similarly the TLS client requests application secrets used to protect 1467 the TLS session as well as other secrets such as exporter secrets. 1469 Upon receiption of the handshake the CS derives the handshake secrets 1470 and the server_handshake_traffic_secret as described in [RFC8446] 1471 section 7.3 to decrypt the encrypted messages. The presence of a 1472 CertificateRequest indicates the TLS server expects the TLS client to 1473 authenticate via a CertificateVerify message. If the CS protects a 1474 private key associated to the TLS client, the CS MUST provides the 1475 necessary information to the TLS client client. Otherwise, the 1476 CertificateRequest is ignored by the CS. 1478 When the CS generates the signature, the presence of the certificate, 1479 the signature and sig_algo is indicated by setting tag.cert_request. 1480 Unlike on the TLS server, where the TLS server indicates the 1481 certificate to chose as well as the signature scheme to select, on 1482 the TLS client, such decision is left to the CS. The choice of the 1483 signature algorithm and certificate is performed by the CS as 1484 described in When resumption_master_secret is requested by the TLS 1485 client, or when further exchanges between teh TLS client and the CS 1486 are expected, the CS generates the CertificateVerify and Finished 1487 message to synchronize the TLS handshake context. The Certificate, 1488 respectively CertificateVerify and Finished message are generated as 1489 described in [RFC8446] section 4.4.2.3. [RFC8446] section 4.4.2, 1490 section 4.4.3, and section 4.4.4. 1492 This exchange is followed by a c_post_hand_auth, c_register_ticket 1493 exchange. 1495 struct{ 1496 uint8 tag; 1497 uint32 session_id; 1498 Ephemeral ephemeral; 1499 Handshake handshake<0..2^32>; //RFC8446 section 4 1500 uint16 secret_request; 1501 }CHandAndAppSecretRequest 1503 struct{ 1504 uint8 tag; 1505 uint32 session_id; 1506 Secret secret_list<0..2^16-1>; 1507 select( tag.cert_request){ 1508 case true: 1509 LURKTLS13Certificate certificate; 1510 SignatureScheme sig_algo; 1511 Signature signature; 1512 } 1513 }CHandAndAppSecretRequest 1515 session_id, secret_request certificate signature, and secret_list are 1516 respectively described in Section 5.3, Section 5.1, Section 5.7, 1517 Section 5.10 and Section 5.9 1519 tag is defined in Section 5.8 and indicates whether the further 1520 exchanges are expected or not. If the TLS client or the TLS 1521 server do not expect to perform session resumption or have not 1522 enabled post handshake authentication the tag.last_message SHOULD 1523 be set. 1525 ephemeral is defined in Section 5.5. Since ClientHello as already 1526 been sent, the purpose of the ephemeral is to provid ethe (EC)DHE 1527 shared secret to perform the key schedule and ephemeral_method 1528 MUST NOT be set to secret_generated. 1530 handshake is defined in Section 5.2 and includes the ServerHello up 1531 to the server Finished. These messages are passed to the CS 1532 encrypted. 1534 sig_algo is defined in Section 5.10 and defines the algorithm chosen 1535 by the CS. 1537 7.7. c_register_tickets 1539 The c_register_ticket is only used when the TLS client intend to 1540 perform session resumption. The LURK client MAY provide one or 1541 multiple NewSessionTickets. These tickets will be helpful for the 1542 session resumption to bind the PSK value to some identities. As teh 1543 NewSessionTicket's identities may collide when being provided by 1544 multiple TLS servers, the CS provides identities it manages to 1545 prevent such collisions (CPskID). One such CPskID is assigned to 1546 each ticket and is later used to designate that ticket (see 1547 Section 7.4). When too many tickets are provided, the CS SHOULD 1548 raise a too_many_identities error. 1550 struct { 1551 uint8 tag 1552 uint32 session_id 1553 NewSessionTicket ticket_list<0..2^16-1>; //RFC8446 section 4.6.1. 1554 } RegisterTicketsRequest; 1556 struct { 1557 uint8 tag 1558 uint32 session_id 1559 CPskID c_spk_id_list<0..2^8-1> 1560 } RegisterTicketsResponse; 1562 8. Security Considerations 1564 Security credentials as per say are the private key used to sign the 1565 CertificateVerify when ECDHE authentication is performed as well as 1566 the PSK when PSK or PSK-ECDHE authentication is used. 1568 The protection of these credentials means that someone gaining access 1569 to the CS MUST NOT be able to use that access from anything else than 1570 the authentication of an TLS being established. In other way, it 1571 MUST NOT leverage this for: * any operations outside the scope of TLS 1572 session establishment. * any operations on past established TLS 1573 sessions * any operations on future TLS sessions * any operations on 1574 establishing TLS sessions by another LURK client. 1576 The CS outputs are limited to secrets as well as NewSessionTickets. 1577 The design of TLS 1.3 make these output of limited use outside the 1578 scope of TLS 1.3. Signature are signing data specific to TLS 1.3 1579 that makes the signature facility of limited interest outside the 1580 scope of TLS 1.3. NewSessionTicket are only useful in a context of 1581 TLS 1.3 authentication. 1583 ECDHE and PSK-ECDHE provides perfect forward secrecy which prevents 1584 past session to be decrypted as long as the secret keys that 1585 generated teh ECDHE share secret are deleted after every TLS 1586 handshake. PSK authentication does not provide perfect forward 1587 secrecy and authentication relies on the PSK remaining sercet. The 1588 Cryptographic Service does not reveal the PSK and instead limits its 1589 disclosure to secrets that are generated from the PSK and hard to be 1590 reversed. 1592 Future session may be impacted if an attacker is able to authenticate 1593 a future session based on what it learns from a current session. 1594 ECDHE authentication relies on cryptographic signature and an ongoing 1595 TLS handshake. The robustness of the signature depends on the 1596 signature scheme and the unpredictability of the TLS Handshake. PSK 1597 authentication relies on not revealing the PSK. The CS does not 1598 reveal the PSK. TLS 1.3 has been designed so secrets generated do 1599 not disclose the PSK as a result, secrets provided by the 1600 Cryptographic do not reveal the PSK. NewSessionTicket reveals the 1601 identity (ticket) of a PSK. NewSessionTickets.ticket are expected to 1602 be public data. It value is bound to the knowledge of the PSK. The 1603 Cryptographic does not output any material that could help generate a 1604 PSK - the PSK itself or the resumption_master_secret. In addition, 1605 the Cryptographic only generates NewSessionTickets for the LURK 1606 client that initiates the key schedule with CS with a specific way to 1607 generate ctx_id. This prevents the leak of NewSessionTickets to an 1608 attacker gaining access to a given CS. 1610 If an the attacker get the NewSessionTicket, as well as access to the 1611 CS of the TLS client it will be possible to proceed to the 1612 establishment of a TLS session based on the PSK. In this case, the 1613 CS cannot make the distinction between the legitimate TLS client and 1614 teh attacker. This corresponds to the case where the TLS client is 1615 corrupted. 1617 Note that when access to the CS on the TLS server side, a similar 1618 attack may be performed. However the limitation to a single re-use 1619 of the NewSessionTicket prevents the TLS server to proceed to the 1620 authentication. 1622 Attacks related to other TLS sessions are hard by design of TLS 1.3 1623 that ensure a close binding between the TLS Handshake and the 1624 generated secrets. In addition communications between the LURK 1625 client and the CS cannot be derived from an observed TLS handshake 1626 (freshness function). This makes attacks on other TLS sessions 1627 unlikely. 1629 9. IANA Considerations 1630 10. Acknowledgments 1632 11. References 1634 11.1. Normative References 1636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1637 Requirement Levels", BCP 14, RFC 2119, 1638 DOI 10.17487/RFC2119, March 1997, 1639 . 1641 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1642 (TLS) Cached Information Extension", RFC 7924, 1643 DOI 10.17487/RFC7924, July 2016, 1644 . 1646 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1647 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1648 May 2017, . 1650 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1651 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1652 . 1654 11.2. Informative References 1656 [I-D.mglt-lurk-lurk] 1657 Migault, D., "LURK Protocol version 1", Work in Progress, 1658 Internet-Draft, draft-mglt-lurk-lurk-00, 9 February 2018, 1659 . 1662 [I-D.mglt-lurk-tls12] 1663 Migault, D. and I. Boureanu, "LURK Extension version 1 for 1664 (D)TLS 1.2 Authentication", Work in Progress, Internet- 1665 Draft, draft-mglt-lurk-tls12-04, 25 January 2021, 1666 . 1669 Appendix A. Annex 1671 A.1. TLS server ECDHE (no session resumption) 1673 This section illustrates the most common exchange of a TLS client 1674 authenticates a TLS server with it certificate (ECDHE) without 1675 session resumption. 1677 The TLS handshake is depicted below from {!RFC8446}}. For clarity as 1678 ECDHE authentication is performed, PSK related extensions ( 1679 psk_key_exchange_modes, pre_shared_key ) have been omitted. In 1680 addition, as the TLS client is not authenticated, CertificateRequest 1681 sent by the TLS server as well as Certificate and CertificateVerify 1682 sent by the TLS client have been removed. 1684 TLS client TLS Server 1686 Key ^ ClientHello 1687 Exch | + key_share 1688 v + signature_algorithms ---------> 1689 ServerHello ^ Key 1690 + key_share v Exch 1691 {EncryptedExtensions} Server Params 1692 {Certificate} ^ 1693 {CertificateVerify} | Auth 1694 {Finished} v 1695 <-------- [Application Data*] 1696 {Finished} --------> 1697 [Application Data] <-------> [Application Data] 1699 The TLS server interacts with the CS with a s_init_cert_verify 1700 exchange in order to respond to the ClientHello. 1702 Since there is no session resumption, the request indicates with the 1703 tag set to last_exchange that no subsequent messages are expected. 1704 As a result, no session_id is provided. The freshness function is 1705 set to sha256, the handshake is constituted with the appropriated 1706 messages with a modified server_random to provide PFS. The 1707 Certificate message is also omitted from the handshake and is instead 1708 provided in the certificate structure using a finger_print. The 1709 requested secrets are handshake and application secrets, that is h_s, 1710 h_c, a_s, and a_c. The signature scheme is ed25519. With 1711 authentication based on certificates, there are two ways to generate 1712 the shared secrets that is used as an input to the derive the 1713 secrets. The ECDHE private key and shared secret may be generated by 1714 the CS as described in {sec:ex:srv:cs_generated}. On the other hand 1715 the ECDHE private key and shared secret may be generated by the TLS 1716 server as described in {tls_server_generated} 1718 A.1.1. ecdhe generated on the CS 1720 When the (EC)DHE private key and shared secrets are generated by the 1721 CS, the LURK client set the ephemeral_method to secret_generated. 1722 The (EC)DHE group x25519 is specified in the handshake in the 1723 key_share extension. In return the CS provides the LURK client the 1724 public key so the TLS server can send the ServerHello to the TLS 1725 client. 1727 In this scenario, the CS is the only entity that knows the private 1728 ECDHE key and the shared secret, and only the CS is able to compute 1729 the secrets. The CS indicates the exchange is final by setting the 1730 tag to last_message, returns the x25519 public key that will be 1731 included in the ServerHello key_share extension, the signature sig 1732 that will be returned in the CertificateVerify message as well as the 1733 secrets that will be used to derive the appropriated keys. 1735 TLS server 1736 LURK client Cryptographic Service 1737 SInitCertVerifyRequest 1738 tag=last_exchange --------> 1739 freshness = sha256 1740 ephemeral 1741 ephemeral_method = secret_generated 1742 handshake = handshake (x25519) 1743 certificate = finger_print 1744 secret_request = h_s, h_c, a_s, and a_c 1745 sig_algo = ed25519 1746 SInitCertVerifyResponse 1747 tag=last_exchange 1748 ephemeral 1749 key 1750 group = x25519, 1751 key_exchange = public_key 1752 secret_list 1753 signature = sig 1754 <--------- 1756 A.1.2. ecdhe generated by the TLS server 1758 When the (EC)DHE private keys and the shared secrets are generated by 1759 the TLS server, the LURK client provides the shared secret to the CS 1760 as only the shared secret is necessary to generated the signature. 1761 This is indicated by the ephemeral_method set to secret_provided. No 1762 (EC)DHE values are returned by the CS as these have already been 1763 generated by the TLS server. However, the TLS server has all the 1764 necessary material to generate the secrets and the only information 1765 that the CS owns and that is not known to et TLS server is the 1766 private key (associated to the certificate) used to generate the 1767 signature. This means that is session resumption were allowed, since 1768 it is based on PSK authentication derived from the resumption secret, 1769 these sessions could be authenticated by the TLS server without any 1770 implication from the CS. 1772 In this scenario, the CS is the only entity that knows the private 1773 ECDHE key. Only the CS is able to generate the signature. Both the 1774 CS and the TLS server are able to compute all secrets. The CS 1775 indicates the exchange is final by setting the tag to last_message, 1776 returns the signature sig that will be returned in the 1777 CertificateVerify message as well as - when requested - the secrets 1778 that will be used to derive the appropriated keys. 1780 TLS server 1781 LURK client Cryptographic Service 1782 SInitCertVerifyRequest 1783 tag.last_exchange=True --------> 1784 freshness = sha256 1785 ephemeral 1786 ephemeral_method = secret_provided 1787 key 1788 group = x25519 1789 shared_secret = shared_secret 1790 handshake = handshake 1791 certificate = finger_print 1792 secret_request = h_s, h_c, a_s, and a_c 1793 sig_algo = ed25519 1794 SInitCertVerifyResponse 1795 tag.last_exchange=True 1796 secret_list 1797 signature = sig 1798 <--------- 1800 A.2. TLS server ECDHE ( with session resumption ) 1802 When the TLS client is enabling session resumption, the TLS server is 1803 expected to generate some tickets that will be later used for later 1804 sessions. The generation of the tickets is based on the 1805 resumption_master_secret. To ensure protection of the authentication 1806 credential used for the session resumption, the CS necessarily must 1807 have generated the (EC)DHE keys and must not have provided the 1808 resumption_master_secret. In either other cases, the TLS client is 1809 able to compute the resumption_master_secret and so session 1810 resumption is out of control of the CS. As a result, the CS sort of 1811 achieves a delegation to the TLS server. 1813 In the remaining of this section, we consider the session resumption 1814 is performed by the CS. 1816 ECDHE authentication is performed with the CS generating the private 1817 part of the (EC)DHE as described in {sec:ex:srv:cs_generated}. 1818 However, additional s_new_ticket exchanges are needed so the TLS 1819 server provides sufficient material to generate the tickets by the CS 1820 and retrieves the generated tickets by the CS. As result, the main 1821 difference with the scenario described in {sec:ex:srv:cs_generated} 1822 is that tag carries a session_id to identify the session between the 1823 TLS server and the CS. 1825 TLS server 1826 LURK client Cryptographic Service 1827 SInitCertVerifyRequest 1828 tag.last_exchange=False 1829 session_id = session_id_tls_server --------> 1830 freshness = sha256 1831 ephemeral 1832 ephemeral_method = secret_generated 1833 handshake = handshake (x25519) 1834 certificate = finger_print 1835 secret_request = h_s, h_c, a_s, a_c 1836 sig_algo = ed25519 1837 SInitCertVerifyResponse 1838 tag.last_exchange=False 1839 session_id = session_id_cs 1840 ephemeral 1841 key 1842 group = x25519, 1843 key_exchange = public_key 1844 secret_list 1845 signature = sig 1846 <--------- 1848 To enable session resumption, the TLS server needs to send 1849 NewSessionTickets to the TLS client. This exchange is taken from 1850 [RFC8446] and represented below: ~~~ TLS client TLS Server <----- 1851 [NewSessionTicket] ~~~ 1853 The TLS server requests NewSessionTicket to the CS by sending a 1854 SNewTicketRequest. The tag.last_exchange set to False indicates to 1855 the CS the TLS server is willing to request NewSessionTickets 1856 multiple times. The session_id is set to the value provided 1857 previously by the CS. This session_id will be used to associate the 1858 SNewTicketRequest to the specific context of teh TLS handshake. 1859 handshake is the remaining handshake necessary to generate the 1860 secrets. In some cases, when the TLS client is authenticated, the 1861 TLS handshake contains a Certificate message that is carried in the 1862 certificate structure as opposed as to the handshake structure. In 1863 our current case, the TLS client is not authenticated, so the 1864 certificate_type is set to 'empty'. ticket_nbr is an indication of 1865 the number of requested NewSessionTicket, and secret_list indicates 1866 the requested secrets. In our case the resumption_master_secret (r) 1867 will remain in the CS and will be anyway ignored by the CS, so the 1868 secret_request has its r bit unset. 1870 As depicted below, the CS provides a list of tickets that could be 1871 later used in order to authenticate the TLS server using PSK or PSK- 1872 ECDHE authentication as describe din {sec:ex:srv:server-psk}. 1874 TLS server 1875 LURK client Cryptographic Service 1876 SNewTicketRequest 1877 tag.last_exchange=False 1878 session_id = session_id_cs 1879 handshake = client Finished 1880 certificate 1881 certificate_type = empty 1882 ticket_nbr 1883 secret_request --------> 1884 SNewTicketResponse 1885 tag.last_exchange=False 1886 session_id = session_id_tls_server 1887 secret_list 1888 <--------- ticket_list 1890 A.3. TLS server PSK / PSK-ECDHE 1892 PSK/PSK-ECDHE authentication is the method used for session 1893 resumption but can also be used outside the scope of session 1894 resumption. In both cases, the PSK is hosted by the CS. 1896 The PSK authentication can be illustrated by the exchange below: 1898 TLS client TLS Server 1899 ClientHello 1900 + key_share 1901 + psk_key_exchange_mode 1902 + pre_shared_key --------> 1903 ServerHello 1904 + pre_shared_key 1905 + key_share 1906 {EncryptedExtensions} 1907 {Finished} 1908 <-------- [Application Data*] 1910 The TLS client may propose to the TLS server multiple PSKs. 1912 Each of these PSKs is associated a PskBindersEntry defined in 1913 [RFC8446] section 4.2.11.2. PskBindersEntry is computed similarly to 1914 the Finished message using the binder_key and the partial 1915 ClientHello. The TLS server is expected to pick a single PSK and 1916 validate the binder. In case the binder does not validate the TLS 1917 Handshake is aborted. As a result, only one binder_key is expected 1918 to be requested by the TLS server as opposed to the TLS client. In 1919 this example we assume the psk_key_exchange_mode indicated by the TLS 1920 client supports PSK-ECDHE as well as PSK authentication. The 1921 presence of a pre_shared_key and a key_share extension in the 1922 ServerHello indicates that PSK-ECDHE has been selected. 1924 While the TLS handshake is performed in one round trip, the TLS 1925 server and the CS have 2 LURK exchanges. These exchanges are 1926 consecutive and performed in the scope of a LURK session. A first 1927 exchange (s_init_early_secret) validates the ClientHello receives by 1928 the TLS server and existence of the selected PSK (by the TLS server) 1929 is actually hosted by the CS. Once the s_init_early_secret exchange 1930 succeeds, the TLS server starts building the ServerHello and requests 1931 the necessary parameters derived by the CS to complete the 1932 ServerHello with a second exchange (s_init_hand_and_apps). 1934 The TLS server is expected to select a PSK, check the associated 1935 binder and proceed further. If the binder fails, it is not expected 1936 to proceed to another PSK, as a result, the TLS server is expected to 1937 initiates a single LURK session. 1939 The SInitEarlySecretRequest structure provides the session_id that 1940 will be used later by the TLS server to identify the session with 1941 future inbound responses from the CS (session_id_server). The 1942 freshness function (sha256) is used to implement PFS together with 1943 the ClientHello.random. selected_identity indicates the PSK chosen 1944 by the TLS server among those proposed by the TLS client in its 1945 ClientHello. The secrets requested by the TLS server are indicated 1946 in secret_request. This example shows only the binder_key, but other 1947 early secrets may be requests as well. 1949 The CS responds with a SInitEarlySecretResponse that contains the 1950 session_id_cs used later to identify the incoming packets associated 1951 to the LURK session and the binder_key. 1953 TLS server 1954 LURK client Cryptographic Service 1955 SInitEarlySecretRequest ----------> 1956 session_id = session_id_tls_server 1957 freshness = sha256 1958 selected_identity = 0 1959 handshake = ClientHello 1960 secret_request = b 1961 SInitEarlySecretResponse 1962 session_id = session_id_cs 1963 <--------- secret_list = binder_key 1965 To complete to the ServerHello exchange, the TLS server needs the 1966 handshake and application secrets. These secrets are requested via 1967 an s_hand_and_app_secret LURK exchange. 1969 The SHandAndAppSecretRequest structure carries a tag with its 1970 last_exchange set to False to indicate the willingness of the TLS 1971 server to keep the session open and proceed to further LURK 1972 exchanges. In our case, this could mean the TLS server expects to 1973 request additional tickets. The session_id is set to session_id_cs, 1974 the value provided by the CS. ephemeral is in our case set the 1975 ephemeral_method to secret_generated as described in Appendix A.1. 1976 The method (x25519) to generate the (EC)DHE is indicated in the 1977 handshake. The necessary handshake to derive the handshake and 1978 application secrets, as well the requested secrets are indicated in 1979 the secret_request structure. 1981 The CS sets its tag.last_exchange to True to indicate the session 1982 will be closed after this exchange. This also means that no ticket 1983 will be provided by the CS. The CS returns the (EC)DHE public key as 1984 well as requested secrets in a SHandAndAppResponse structure 1985 similarly to what is being described in {sec:ex:srv:ecdhe}. 1987 TLS server 1988 LURK client Cryptographic Service 1989 SHandshakeAndAppRequest 1990 tag.last_exchange = False 1991 session_id = session_id_cs 1992 ephemeral 1993 ephemeral_method = secret_generated 1994 handshake = ServerHello(x25519) ... EncryptedExtensions 1995 secret_request = h_c, h_s, a_c, a_s -------> 1996 SHandAndAppResponse 1997 tag.last_exchange = True 1998 session_id = session_id_tls_server 1999 ephemeral 2000 key 2001 group = x25519, 2002 key_exchange = public_key 2003 <--------- secret_list 2005 A.4. TLS client unauthenticated ECDHE 2007 This section details the case where a TLS client establishes a TLS 2008 session authenticating the TLS server using ECDHE. The TLS client 2009 interacts with the CS in order to generate the (EC)DHE private part. 2010 While this section does not illustrates session resumption, the TLS 2011 client is configured to proceed to session resumption which will be 2012 described with further details in Appendix A.5. 2014 The TLS handshake described in [RFC8446] is depicted below. In this 2015 example, the TLS client proposes a key_share extension to agree on a 2016 (EC)DHE shared secret, but does not propose any PSK. 2018 TLS client TLS Server 2020 Key ^ ClientHello 2021 Exch | + key_share 2022 v + signature_algorithms ---------> 2023 ServerHello ^ Key 2024 + key_share v Exch 2025 {EncryptedExtensions} Server Params 2026 {Certificate} ^ 2027 {CertificateVerify} | Auth 2028 {Finished} v 2029 <-------- [Application Data*] 2030 {Finished} --------> 2031 [Application Data] <-------> [Application Data] 2033 If the TLS client generates the (EC)DHE private key, no interaction 2034 with the CS is needed as it will have the default PSK value as well 2035 as the (EC)DHE shared secrets necessary to proceed to the key 2036 schedule described in section 7.1 of [RFC8446]. 2038 In this example, the TLS client requests the CS via a 2039 c_init_client_hello to generate the (EC)DHE private key and provide 2040 back the public part that will be placed into the key_share extension 2041 before being sent to the TLS server. 2043 Like in any init methods, the TLS client indicates with 2044 session_id_tls_client the idnetifier of the session that is being 2045 assigned by the TLS client for future inbound LURK message responses 2046 sent by the CS. Similarly, the CS advertises its session_id_cs. 2047 freshness is set to sha256, and the ClientHello.random is generated 2048 as described in Section 5.4. handshake contains the ClientHello 2049 message to which the key_exchange of the KeyShareentries has been 2050 stripped off without changing the other fields. As PSK are not 2051 involved, no early secrets are involved and c_psk_list and 2052 secret_request are empty. 2054 The CS provides the KeyShareEntries. The TLS client is able to build 2055 the ClientHello to the TLS server with ClientHello.random and by 2056 placing the KeyShareEntries. 2058 TLS client 2059 LURK client Cryptographic Service 2060 CInitClientHello 2061 session_id = session_id_tls_client 2062 freshness = sha256 2063 ephemeral 2064 ephemeral_method = secret_generated 2065 handshake = ClientHello(x25519, x488, ... ) 2066 c_psk_id_list = [] 2067 secret_request = [] ------> 2068 CInitClientHello 2069 session_id=session_id_cs 2070 ephemeral_list 2071 key 2072 group = x25519, 2073 key_exchange = public_key 2074 ephemeral_method = secret_generated 2075 key 2076 group = x488, 2077 key_exchange = public_key 2078 secret_list=[] 2080 Upon receiving the response from the TLS server, responds with a 2081 ServerHello followed by additional encrypted messages. 2083 The TLS client needs the handshake secrets to decrypt these encrypted 2084 messages and send back the client Finished message. In addition, the 2085 TLS client requests the application secrets to encrypt and decrypt 2086 the TLS session. The secrets are requested via a 2087 c_hand_and_app_secret. 2089 We assume the TLS client supports session resumption so, the 2090 tag.last_message is unset. The session_id takes the value advertises 2091 by each party during the previous c_init_client_hello exchange. 2092 Since the CS already has the (EC)DHE private keys, it will be able to 2093 derive the (EC)DHE shared secret and no information needs to be 2094 provided by the TLS client. As a result, ephemeral_method is set to 2095 no_secret. The handshake is composed of the messages sent by the TLS 2096 server. As the TLS client does not have yet the messages are not 2097 decrypted, and are provided encrypted. The requested secrets are the 2098 handshake and application secrets. 2100 The CS generates the handshake secrets and the associated key to 2101 decrypt the encrypted messages. As no CertificateRequest has been 2102 found, the CS does not compute the signature that would authenticate 2103 the TLS client. In this section, we assume the CS is ready to accept 2104 further exchanges, and in our case the c_register_tickets exchange to 2105 enable session resumption. Since session resumption is enabled, the 2106 CS computes the Finished message to generate the 2107 resumption_master_secret. 2109 The CS returns the response by unsetting the tag.last_message and 2110 cert_request. The ephemeral is an empty list and secret_request 2111 returns the requested secrets. 2113 TLS client 2114 LURK client Cryptographic Service 2115 CHandAndAppSecretRequest 2116 tag.last_message=False 2117 session_id=session_id_cs 2118 ephemeral 2119 ephemeral_method = no_secret 2120 handshake = ServerHello, {EncryptedExtensions}...,{Finished}. 2121 secret_request = h_c, h_s, a_c, a_s -------> 2122 CHandAndAppSecretResponse 2123 tag 2124 last_message=False 2125 cert_request=False 2126 session_id=session_id_tls_clt 2127 ephemeral_list = [] 2128 secret_request = h_s, h_c, a_s, and a_c 2130 Upon reception of the response, the TLS client generates the 2131 necessary keys to decrypt and encrypt the handshake message and 2132 terminates the TLS handshake. The TLS client is also able to decrypt 2133 and encrypt application traffic. 2135 In this section, we assume that after some time, the TLS client 2136 receives a NewSessionTicket from the TLS server. The TLS client will 2137 then transmit the NewSessionTicket to the CS so that it can generate 2138 the associated PSK that will be used for the authentication. 2140 As multiple NewSessionTickets may be sent, in this example, both TLS 2141 client and CS enable further additional registrations by unsetting 2142 tag.last_message. For each registered NewSessionTicket, the CS 2143 returns c_spk_id that will use for further references. The c_spk_ids 2144 are managed by the CS which can ensure the uniqueness of these 2145 references as opposed to using the ticket field that is assigned by 2146 the TLS server. 2148 Appendix A.5 illustrates how session resumption is performed using 2149 PSK / PSK-ECDHE authentication. 2151 TLS client 2152 LURK client Cryptographic Service 2153 RegisterTicketsRequest 2154 tag.last_message=False 2155 session_id=session_id_cs 2156 ticket_list = [NewSessionTicket] 2157 ----------------> 2158 RegisterTicketsResponse 2159 last_message=False 2160 session_id=session_id_tls_clt 2161 <-------- c_spk_id_list = [nst_id] 2163 A.5. TLS client unauthenticated PSK / PSK-ECDHE 2165 This section describes the intercation between a TLS client and a CS 2166 for a PSK-ECDHE TLS handshake. Appendix A.4 shows how the PSK may be 2167 provisioned during a ECDHE TLS handshake. The scenario described in 2168 this section presents a number of similarities to the one described 2169 in Appendix A.4. As such, we expect the reader to be familiar with 2170 Appendix A.4 and will highlight the differences with Appendix A.4 to 2171 avoid to repeat the description. 2173 In this section, the PSK is protected by the CS, but the (EC)DHE 2174 private keys are generated by the TLS client and as such are 2175 considered as unprotected. As the (EC)DHE secret are generated by 2176 the TLS client, the ephemeral_method is set to no_secret, and the 2177 key_share extension is fully provided in the ClientHello. However, 2178 the ClientHello do not carry the PreSharedKeyExtension. Instead, 2179 this extension is built from the NewSessionTicket identifier nst_id 2180 provided in our case from a previous c_register_ticktes exchange (see 2181 Appendix A.4 }. The TLS client requests the binder_key associated to 2182 nst_id in order to be able to complete the binders. 2184 Upon receiving the message, the CS, computes the binder_keys, 2185 complete the ClientHello in order to synchronize its TLS handshake 2186 with the TLS client (and the TLS server). As the CS does not 2187 generate any (EC)DHE, the ephemeral_list is empty. 2189 TLS client 2190 LURK client Cryptographic Service 2191 CInitClientHello 2192 session_id = session_id_tls_client 2193 freshness = sha256 2194 ephemeral 2195 ephemeral_method = no_secret 2196 handshake = ClientHello without PreSharedKeyExtension 2197 c_psk_id_list = [nst_id] 2198 secret_request = [b] ------> 2199 CInitClientHello 2200 session_id=session_id_cs 2201 ephemeral_list = [] 2202 secret_list=[binder_key] 2204 When the TLS client receives the responses from the TLS server, the 2205 handshake and application secrets are requested with a c_hand_and_app 2206 similarly to Appendix A.4. The only difference here is that (EC)DHE 2207 have been generated by the TLS client and the shared secret needs to 2208 be provided to the CS as described below: 2210 TLS client 2211 LURK client Cryptographic Service 2212 CHandAndAppSecretRequest 2213 tag.last_message=False 2214 session_id=session_id_cs 2215 ephemeral 2216 ephemeral_method = secret_provided 2217 shared_secret 2218 handshake = ServerHello, {EncryptedExtensions}...,{Finished}. 2219 secret_request = h_c, h_s, a_c, a_s -------> 2220 CHandAndAppSecretResponse 2221 tag 2222 last_message=False 2223 cert_request=False 2224 session_id=session_id_tls_clt 2225 ephemeral_list = [] 2226 secret_request = h_s, h_c, a_s, and a_c 2228 Upon receiving the response, the TLS client proceeds similarly to the 2229 TLS client described in Appendix A.4. 2231 A.6. TLS client authenticated ECDHE 2233 This section provides scenarios when the TLS client is authenticated 2234 during the TLS handshake. Post handshake authentication is detailed 2235 in Appendix A.7 2237 A.6.1. (EC)DHE or Proposed PSK protected by the CS 2239 When the (EC)DHE part have been generated by the CS, or the proposed 2240 PSK are protected by the CS, the TLS client sends a ClientHello after 2241 a c_client_hello exchange with the CS (see Appendix A.5 or 2242 Appendix A.4). The request for TLS client authentication is 2243 indicated by a encrypted CertificateRequest sent by the TLS server as 2244 indicated below: 2246 TLS client TLS Server 2248 Key ^ ClientHello 2249 Exch | + key_share 2250 v + signature_algorithms ---------> 2251 ServerHello ^ Key 2252 + key_share v Exch 2253 {EncryptedExtensions} ^ Server Params 2254 {CertificateRequest} v 2255 {Certificate} ^ 2256 {CertificateVerify} | Auth 2257 {Finished} v 2258 <-------- [Application Data*] 2259 ^ {Certificate} 2260 Auth | {CertificateVErify} 2261 v {Finished} --------> 2262 [Application Data] <-------> [Application Data] 2264 The TLS client is unaware of the presence of the CertifcateRequest 2265 until it has decrypted the message with a key derived from the 2266 handshake secrets. As a result, the TLS client initiates a 2267 c_hand_an_app_secret exchange as described in Appendix A.5 or 2268 Appendix A.4. 2270 The CS proceeds as described in Appendix A.5 or Appendix A.4. 2271 However, after the messages have been decrypted, the CS proceeds to 2272 the generation of the signature and returns the necessary information 2273 to build the CertificateVerify. The CS indicates their presence by 2274 setting tag.cert_request and returns the certificate, the sig_algo 2275 and sig as described below: 2277 TLS client 2278 LURK client Cryptographic Service 2279 CHandAndAppSecretRequest 2280 tag.last_message=False 2281 session_id=session_id_cs 2282 ephemeral 2283 ephemeral_method = secret_provided 2284 shared_secret 2285 handshake = ServerHello, {EncryptedExtensions}...,{Finished}. 2286 secret_request = h_c, h_s, a_c, a_s -------> 2287 CHandAndAppSecretResponse 2288 tag 2289 last_message=False 2290 cert_request=True 2291 session_id=session_id_tls_clt 2292 ephemeral_list = [] 2293 secret_request = h_s, h_c, a_s, and a_c 2294 certificate 2295 certificate_type = finger_print 2296 sig_algo = ed25519 2297 sig 2299 Note that in the example above, (EC)DHE have not been generated by 2300 the CS, but the c_client_hello was motivated to propose a protected 2301 PSK. As the PSK has not been agreed for authentication by the TLS 2302 server, the TLS session does not provide PFS and the protection is 2303 similar as the one described in {sec:ex:clt:auth:ecdhe-certverify}, 2304 where the TLS client would have proposed directly ECDHE with (EC)DHE 2305 generated by the TLS client. 2307 A.6.2. (EC)DHE provided by the TLS client 2309 This section considers a TLS client that proposes to authenticate the 2310 TLS server using ECDHE with (EC)DHE private parts being generated by 2311 the TLS client. 2313 The TLS client does not need to interact with CS to build its 2314 ClientHello. Similarly, as the (EC)DHE private part have been 2315 generated by the TLS client, the TLS client is able to perform the 2316 key schedule and derive the necessary keys to decrypt the encrypted 2317 response from the TLS server. Upon receiving a CertificateRequest, 2318 the TLS client requests the CS to generate the signature needed to 2319 send the CertificateVerify. The exchange is very similar as the one 2320 s_init_cert_verify (see Appendix A.1.2). As the (EC)DHE shared 2321 secret is generated by the TLS client, the ephemeral_method is 2322 necessarily set to secret_provided. The handshake is set to the 2323 ClientHello ... server Finished, and the certificate carries the 2324 reference to the TLS client certificate, so the CS picks the 2325 appropriated private key. sig_algo designates the signature 2326 algorithm. 2328 TLS server 2329 LURK client Cryptographic Service 2330 CInitCertVerifyRequest 2331 tag.last_exchange=True --------> 2332 freshness = sha256 2333 ephemeral 2334 ephemeral_method = secret_provided 2335 key 2336 group = x25519 2337 shared_secret = shared_secret 2338 handshake = hanshake 2339 certificate 2340 certificate_type = finger_print 2341 sig_algo = ed25519 2342 CInitCertVerifyResponse 2343 tag.last_exchange=True 2344 signature = sig 2345 <--------- 2347 A.7. TLS client authenticated - post handshake authentication 2349 Post handshake authentication may be requested at any time after the 2350 TLS handshake is completed as long as the TLS client has indicated 2351 its support with a post_handshake_authentication extension. 2353 If the establishment of the TLS session did not required any 2354 interactions with the CS, post handshake authentication is performed 2355 with a c_init_post_hand_auth exchange as described in Appendix A.7.1. 2356 When the TLS handshake already required some interactions with the CS 2357 the post handshake authentication is performed using a 2358 c_post_hand_auth described in {sec:ex:clt:auth:post_continued}. 2360 In some cases, both c_init_post_hand_auth and c_post_hand_auth can be 2361 used. When this is possible, c_post_hand_auth is preferred as the 2362 handshake context is already being provisioned in the CS. On the 2363 other hand, when the shared secret is only known to the CS, 2364 c_init_post_hand_auth cannot be used instead. 2366 A.7.1. Initial Post Handshake Authentication 2368 This situation describes the case where the TLS client has performed 2369 the TLS handshake without interacting with the CS. As a result, if 2370 involved PSK, (EC)DHE shared secrets are unprotected and hosted by 2371 the TLS client. Upon receiving a CertificateRequest, the TLS client 2372 sends session_id and freshness to initiate the LURK session. 2373 tag.last_message is set in order to accept future post handshake 2374 authentication request. ephemeral_method is set to secret_provide as 2375 the CS is unable to generate the (EC)DHE shared secret. handshake is 2376 set to the full handshake including the just received 2377 CertificateRequest message. The certificate represents the TLS 2378 client certificate to determine the private key involved in computing 2379 the signature. sig_algo specifies the signature algorithm. 2381 TLS server 2382 LURK client Cryptographic Service 2383 CInitPostHandAuthRequest 2384 tag.last_message = False 2385 session_id = session_id_tls_client 2386 freshness = sha256 2387 ephemeral 2388 ephemeral_method = secret_provided 2389 handshake = ClientHello ... client Finished CertificateRequest 2390 certificate 2391 certificate_type = finger_print 2392 sig_algo ----------------> 2393 CInitPostHandAuthResponse 2394 tag.last_message = False 2395 session_id = session_id_cs 2396 <-------------- signature = sig 2398 A.7.2. Post Handshake Authentication 2400 In this scenario, the post authentication is performed while a LURK 2401 session has already been set. Upon receiving the CertificateRequest, 2402 the TLS client proceeds similarly to the initial post handshake 2403 authentication as described in As a result, the exchange is 2404 illustrated below:Appendix A.7.1 except that the LURK session does 2405 not need to be initiated, the shared secret is already known to the 2406 CS and the handshake is only constituted of the remaining 2407 CertificateRequest message. 2409 TLS server 2410 LURK client Cryptographic Service 2411 CInitPostHandAuthRequest 2412 tag.last_message = False 2413 session_id = session_id_tls_client 2414 handshake = CertificateRequest 2415 certificate 2416 certificate_type = finger_print 2417 sig_algo ----------------> 2418 CInitPostHandAuthResponse 2419 tag.last_message = False 2420 session_id = session_id_cs 2421 <-------------- signature = sig 2423 Author's Address 2425 Daniel Migault 2426 Ericsson 2427 8275 Trans Canada Route 2428 Saint Laurent, QC 4S 0B6 2429 Canada 2431 Email: daniel.migault@ericsson.com