idnits 2.17.1 draft-mglt-lurk-tls13-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 127: '...7.1, this secret MAY require similar p...' RFC 2119 keyword, line 128: '...ssion resumption MAY also be delegated...' RFC 2119 keyword, line 226: '...er hand, some CS MAY be optimized by i...' RFC 2119 keyword, line 228: '... implementations MAY not implement the...' RFC 2119 keyword, line 231: '... the CS MAY also in return impact th...' (100 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If the CS has been configured not to handle session resumption. The session is finished and ks_ctx SHOULD be deleted and some implementations MAY NOT create the ks_ctx. == 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: The first c_register_ticket MAY request the session_resumption_master. Next register_new_session MUST not request that secret.If these conditions are not met, a invalid_key_request error is returned. -- The document date (April 24, 2020) is 1453 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: 'RFC2119' is mentioned on line 142, but not defined == Missing Reference: 'RFC8174' is mentioned on line 142, but not defined == Missing Reference: 'NewSessionTicket' is mentioned on line 1907, but not defined == Outdated reference: A later version (-05) exists of draft-mglt-lurk-tls12-02 == Outdated reference: A later version (-01) exists of draft-mglt-lurk-lurk-00 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LURK D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track April 24, 2020 5 Expires: October 26, 2020 7 LURK Extension version 1 for (D)TLS 1.3 Authentication 8 draft-mglt-lurk-tls13-02 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 October 26, 2020. 33 Copyright Notice 35 Copyright (c) 2020 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 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. LURK Header . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Generic structures . . . . . . . . . . . . . . . . . . . . . 5 54 4.1. key_request . . . . . . . . . . . . . . . . . . . . . . . 6 55 4.2. secrets . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.3. handshake_context . . . . . . . . . . . . . . . . . . . . 8 57 4.4. Secret Sub Exchange . . . . . . . . . . . . . . . . . . . 9 58 4.4.1. Ephemeral Extension . . . . . . . . . . . . . . . . . 10 59 4.4.2. PSK_id Extension . . . . . . . . . . . . . . . . . . 12 60 4.4.3. Freshness Extension . . . . . . . . . . . . . . . . . 13 61 4.4.4. Session ID Extension . . . . . . . . . . . . . . . . 15 62 4.5. Signing Sub-Exchange . . . . . . . . . . . . . . . . . . 17 63 5. LURK exchange on the TLS server . . . . . . . . . . . . . . . 18 64 5.1. s_init_early_secret . . . . . . . . . . . . . . . . . . . 19 65 5.2. s_init_cert_verify . . . . . . . . . . . . . . . . . . . 20 66 5.3. s_hand_and_app_secret . . . . . . . . . . . . . . . . . . 20 67 5.4. s_new_tickets . . . . . . . . . . . . . . . . . . . . . . 21 68 6. LURK exchange on the TLS client . . . . . . . . . . . . . . . 22 69 6.1. c_binder_key . . . . . . . . . . . . . . . . . . . . . . 22 70 6.2. c_init_early_secret . . . . . . . . . . . . . . . . . . . 23 71 6.3. c_hand_secret . . . . . . . . . . . . . . . . . . . . . . 23 72 6.4. c_init_hand_secret . . . . . . . . . . . . . . . . . . . 23 73 6.5. c_app_secret . . . . . . . . . . . . . . . . . . . . . . 24 74 6.6. c_cert_verify . . . . . . . . . . . . . . . . . . . . . . 24 75 6.7. c_register_tickets . . . . . . . . . . . . . . . . . . . 25 76 6.8. c_post_hand . . . . . . . . . . . . . . . . . . . . . . . 26 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 80 10. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 81 10.1. LURK state diagrams on TLS client . . . . . . . . . . . 28 82 10.1.1. LURK client . . . . . . . . . . . . . . . . . . . . 30 83 10.1.2. Cryptographic Service . . . . . . . . . . . . . . . 32 84 10.2. LURK state diagrams on TLS server . . . . . . . . . . . 33 85 10.2.1. LURK client . . . . . . . . . . . . . . . . . . . . 33 86 10.2.2. Cryptographic Service . . . . . . . . . . . . . . . 34 87 10.3. TLS handshakes with Cryptographic Service . . . . . . . 35 88 10.4. TLS 1.3 ECDHE Full Handshake . . . . . . . . . . . . . . 37 89 10.4.1. TLS Client: ClientHello . . . . . . . . . . . . . . 37 90 10.4.2. TLS Server: ServerHello . . . . . . . . . . . . . . 38 91 10.4.3. TLS client: client Finished . . . . . . . . . . . . 40 92 10.5. TLS 1.3 Handshake with session resumption . . . . . . . 43 93 10.5.1. Full Handshake . . . . . . . . . . . . . . . . . . . 43 94 10.5.2. TLS server: NewSessionTicket . . . . . . . . . . . . 44 95 10.5.3. TLS client: NewSessionTicket . . . . . . . . . . . . 45 96 10.5.4. Session Resumption . . . . . . . . . . . . . . . . . 46 97 10.6. TLS 1.3 0-RTT handshake . . . . . . . . . . . . . . . . 49 98 10.6.1. TLS client: ClientHello . . . . . . . . . . . . . . 50 99 10.6.2. TLS server: ServerHello . . . . . . . . . . . . . . 51 100 10.6.3. TLS client: Finished . . . . . . . . . . . . . . . . 51 101 10.7. TLS client authentication . . . . . . . . . . . . . . . 51 102 10.8. TLS Client:Finished (CertificateRequest) . . . . . . . . 52 103 10.9. TLS Client Authentication (PostHandshake) . . . . . . . 52 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 53 106 11.2. Informative References . . . . . . . . . . . . . . . . . 54 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 54 109 1. Introduction 111 This document defines a LURK extension for TLS 1.3 [RFC8446]. 113 This document assumes the reader is familiar with TLS 1.3 the LURK 114 architecture [I-D.mglt-lurk-lurk]. 116 The motivations for the LURK Extension TLS 1.3 are similar to those 117 for the LURK use cases [I-D.mglt-lurk-tls-use-cases]. 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 as well. On 128 the other hand session resumption MAY also be delegated as in the 129 LURK extension of TLS 1.2 [I-D.mglt-lurk-tls12]. 131 The current document extends the scope of the LURK extension for TLS 132 1.2 in that it defines the CS on the TLS server as well as on the TLS 133 client and the CS can operate in non delegating scenarios. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119][RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 This document uses the terms defined [RFC8446] and 144 [I-D.mglt-lurk-tls12]. 146 3. LURK Header 148 LURK / TLS 1.3 is a LURK Extension that introduces a new designation 149 "tls13". This document assumes that Extension is defined with 150 designation set to "tls13" and version set to 1. The LURK Extension 151 extends the LURKHeader structure defined in [I-D.mglt-lurk-lurk] as 152 follows: 154 enum { 155 tls13 (2), (255) 156 } Designation; 158 enum { 159 capabilities(0), 160 ping(1), 161 s_init_early_secret(2), 162 s_init_cert_verify(3), 163 s_hand_and_app_secret(4), 164 s_new_ticket(5), 165 c_binder_key(6), 166 c_init_early_secret(7), 167 c_init_hand_secret(8), 168 c_hand_secret(9), 169 c_app_secret(10), 170 c_cert_veri913fy(11), 171 c_register_ticket(12), 172 c_post_hand(13), (255) 173 }TLS13Type; 175 enum { 176 // generic values reserved or aligned with the 177 // LURK Protocol 178 request (0), success (1), undefined_error (2), 179 invalid_payload_format (3), 181 invalid_psk 182 invalid_freshness_funct 184 invalid_request 185 invalid_key_id_type 186 invalid_key_id 187 invalid_signature_scheme 188 invalid_certificate_type 189 invalid_certificate 190 invalid_certificate_verify 191 invalid_key_request 192 invalid_handshake 193 invalid_extension 194 invalid_ephemeral 195 invalid_cookie_h 197 }TLS13Status 199 struct { 200 Designation designation = "tls13"; 201 int8 version = 1; 202 } Extension; 204 struct { 205 Extension extension; 206 select( Extension ){ 207 case ("tls13", 1): 208 TLS13Type; 209 } type; 210 select( Extension ){ 211 case ("tls13", 1): 212 TLS13Status; 213 } status; 214 uint64 id; 215 unint32 length; 216 } LURKHeader; 218 4. Generic structures 220 The CS is not expected to perform any policies such as choosing the 221 appropriated authentication method. Such choices are performed by 222 the TLS client or TLS server that instruct the LURK client 223 accordingly. Such enforced policies between the TLS client and the 224 TLS server are those performed on a standard TLS exchange. 226 On the other hand, some CS MAY be optimized by implementing a subset 227 of the specified possibilities described in this document. Typically 228 some implementations MAY not implement the session resumption or the 229 post handshake authentication to avoid keeping states of a given 230 session once the handshake has been performed. These capabilities of 231 the CS MAY also in return impact the policies of the TLS client or 232 TLS server. 234 These limitations are mentioned throughout the document, and even 235 represented in the state diagrams, the recommendation is that the CS 236 SHOULD NOT impact the policies of the TLS client or TLS server. 237 Instead they SHOULD be able to optimize the CS to their policies via 238 some configuration parameters presented in section Section 10.1. 239 Such parameters are implementation dependent and only provided here 240 as informative. 242 This document defines the role to specify whether the CS runs on a 243 TLS client or a TLS service. The CS MUST be associated a single 244 role. 246 LURK exchanges falls into three categories: 1) request of keys or 247 secrets, 2) request of signing operations, and 3) requests for ticket 248 (NewSessionTicket) management purposes. In some cases, these 249 operations are combined into a single LURK exchange. Table Figure 1 250 below summarizes the operations associated for each exchange. 252 +--------+-----------------------+------------------------+ 253 | Role | LURK exchange | secret | sign | ticket | 254 +--------+-----------------------+------------------------+ 255 | server | s_init_early_secret | yes | - | - | 256 | server | s_init_cert_verify | yes | yes | - | 257 | server | s_hand_and_app_secret | yes | - | - | 258 | server | s_new_ticket | yes | - | yes | 259 | client | c_binder_key | yes | - | - | 260 | client | c_init_early_secret | yes | - | - | 261 | client | c_init_hand_secret | yes | - | - | 262 | client | c_hand_secret | yes | - | - | 263 | client | c_app_secret | yes | - | - | 264 | client | c_cert_verify | yes | yes | - | 265 | client | c_register_ticket | yes | - | yes | 266 | client | c_post_hand | - | yes | - | 267 +--------+-----------------------+------------------------+ 269 Figure 1: Operation associated to LURK exchange 271 This section describes structures that are widely re-used across the 272 multiple LURK exchanges. 274 4.1. key_request 276 key_request is a 16 bit structure described in Table Figure 2 that 277 indicates the requested key or secrets by the LURK client. The same 278 structure is used across all LURK exchanges, but each LURK exchange 279 only permit a subset of values described in Table Figure 3. 281 A LURK client MUST NOT set key_request to key or secrets that are not 282 permitted. The CS MUST check the key_request has only permitted 283 values and has all mandatory keys or secrets set. If these two 284 criteria are not met the CS MUST NOT perform the LURK exchange and 285 SHOULD return a invalid_key_request error. If the CS is not able to 286 compute an optional key or secret, the CS MUST proceed the LURK 287 exchange and ignore the optional key or secret. 289 +------+-------------------------------------------+ 290 | Bit | key or secret (designation) | 291 +------+-------------------------------------------+ 292 | 0 | binder_key (b) | 293 | 1 | client_early_traffic_secret (e_c) | 294 | 2 | early_exporter_master_secret (e_x) | 295 | 3 | client_handshake_traffic_secret (h_c) | 296 | 4 | server_handshake_traffic_secret (h_s) | 297 | 5 | client_application_traffic_secret_0 (a_c) | 298 | 6 | server_application_traffic_secret_0 (a_s) | 299 | 7 | exporter_master_secret (x) | 300 | 8 | resumption_master_secret (r) | 301 | 9-15 | reserved and set to zero | 302 +------+-------------------------------------------+ 304 Figure 2: key_request structure 306 +-----------------------+--------------------------+ 307 | LURK exchange | Permitted key/secrets | 308 +-----------------------+--------------------------+ 309 | s_init_early_secret | b,e_c*, e_x* | 310 | s_init_cert_verify | h_c, h_s, a_c*, a_s*, x* | 311 | s_hand_and_app_secret | h_c, h_s, a_c*, a_s*, x* | 312 | s_new_ticket | r* | 313 | c_binder_key | b | 314 | c_init_early_secret | e_c*, e_x* | 315 | c_init_hand_secret | h_c, h_s | 316 | c_hand_secret | h_c, h_s | 317 | c_app_secret | a_c*, a_s*, x* | 318 | c_cert_verify | a_c*, a_s*, x* | 319 | c_register_ticket | r* | 320 | c_post_hand | | 321 +-----------------------+--------------------------+ 323 (*) indicates an optional value, other values are mandatory 325 Figure 3: key_request permitted values per LURK exchange 327 4.2. secrets 329 The Secret structure carries a secret designated by its type and 330 value. 332 enum { 333 binder_key (0), 334 client_early_traffic_secret(1), 335 early_exporter_master_secret(2), 336 client_handshake_traffic_secret(3), 337 server_handshake_traffic_secret(4), 338 client_application_traffic_secret_0(5), 339 server_application_traffic_secret_0(6), 340 exporter_master_secret(7), 341 esumption_master_secret(8), 342 (255) 343 } SecretType; 345 struct { 346 SecretType secret_type; 347 opaque secret_data<0..2^8-1>; 348 } Secret; 350 secret_type: The type of the secret or key 352 secret_data: The value of the secret. 354 4.3. handshake_context 356 Secrets derivation takes Handshake Context as input. It is the 357 responsibility of the CS to maintain this variable in an internal 358 variable. On the other hand, it is the responsibility of the LURK 359 client to provide the necessary element so the Cryptographic Service 360 got the necessary Handshake Context. The Handshake Context evolves 361 during the key derivation schedule, the LURK client implements an 362 incremental approach where only the missing part of the Handshake 363 Context are provided. The main intention is to prevent the LURK 364 client from providing multiple time the same information as well as 365 to perform extensive compatibility checks between the duplicated 366 information provided. 368 The handshake_context variable is based on the Handshake structure 369 defined in [RFC8446] section 4. The table below lists the values of 370 the handshake_context associated to each LURK exchange. 372 +-----------------------+--------------------------------+ 373 | LURK exchange | handshake_context | 374 +-----------------------+--------------------------------+ 375 | s_init_early_secret | ClientHello | 376 | s_init_cert_verify | ClientHello ... later of | 377 | | server EncryptedExtensions / | 378 | | CertificateRequest | 379 | s_hand_and_app_secret | ServerHello ... later of | 380 | | server EncryptedExtensions / | 381 | | CertificateRequest | 382 | s_new_ticket | earlier of client Certificate /| 383 | | client CertificateVerify / | 384 | | Finished ... Finished | 385 | c_binder_key | | 386 | c_init_early_secret | ClientHello | 387 | c_init_hand_secret | ClientHello ... ServerHello | 388 | c_hand_secret | ServerHello | 389 | c_app_secret | server EncryptedExtensions ... | 390 | | server Finished | 391 | c_cert_verify | server EncryptedExtensions ... | 392 | | later of server Finished/ | 393 | | EndOfEarlyData | 394 | c_register_ticket | earlier of client Certificate | 395 | | client CertificateVerify ... | 396 | | client Finished | 397 | c_post_hand | CertificateRequest | 398 +-----------------------+--------------------------------+ 400 Figure 4: handshake values per LURK exchange 402 4.4. Secret Sub Exchange 404 Secrets are derived from the key schedule of [RFC8446] section 7. 406 The derivation of secrets requires an optional PSK that is provided 407 in the psk_id extension described in section Section 4.4.2 as well as 408 a ECDHE value which is provided by the ecdhe extension described in 409 section Section 4.4.1. 411 The extensions considered in this document are defined as below: 413 enum { psk_id(1), ephemeral(2), freshness(3), session_id(4) ... (255) 414 } LURK13ExtensionType; 416 struct { 417 LURK13ExtensionType extension_type; 418 opaque extension_data<0..2^16-1>; 419 } LURK13Extension 421 struct { 422 uint16 key_request; 423 Handshake handshake_context<0..2^32> //RFC8446 section 4. 424 LURK13Extension extention_list<0...2^16> 425 } SecretsRequest; 427 struct { 428 Secret secret_list<0..2^16-1>; 429 Extension extention_list<0...2^16> 430 } SecretsResponse; 432 key_request: designates the requested secrets (see section 433 Section 4.1). 435 handshake_context: designates the necessary messages so the CS is 436 aware of the appropriated Handshake Context to generate the secrets 437 (see section Section 4.3). 439 extension_list: the list of extensions. 441 secret_list: the list of requested secrets (see section Section 4.2). 443 4.4.1. Ephemeral Extension 445 The Ephemeral structure carries the necessary information to generate 446 the ECDHE input used to derive the secrets. This document describes 447 two ways the shared secret can be generated: shared_secret_provided: 448 When Diffie Hellman or ECDH keys and shared secret are generated by 449 the TLS server and the shared secret is provided to the CS 451 secret_generated: When the DH / ECDH keys and shared secret are 452 generated by the CS. 454 4.4.1.1. shared_secret_provided: 456 When ECDHE shared secret are not generated by the CS, the LURK client 457 provides the shared secret value to the CS via the ephemeral 458 extension. The shared secret is transmitted via the 459 EphemeralSharedSecret, constructed similarly to the key_exchange 460 parameter of the KeyShareEntry described in [RFC8446] section 4.2.8. 461 The CS MUST NOT return any data. 463 struct { 464 NamedGroup group; 465 opaque shared_secret[coordinate_length]; 466 } EphemeralSharedSecret; 468 Where coordinate_length depends on the chosen group. For secp256r1, 469 secp384r1, secp521r1, x25519, x448, the coordinate_length is 470 respectively 32 bytes, 48 bytes, 66 bytes, 32 bytes and 56 bytes. 471 Upon receiving the shared_secret, the CS MUST check group is proposed 472 in the KeyShareClientHello and agreed in the KeyShareServerHello. 474 4.4.1.2. secret_generated: 476 When the ECDHE public/private keys are generated by the CS, the LURK 477 client requests the CS the associated public value. Note that in 478 such cases the CS would receive an incomplete Handshake Context from 479 the LURK client with the public part of the ECDHE missing. Typically 480 the ServerHello message would present a KeyShareServerHello that 481 consists of a KeyShareEntry with an empty key_exchange field, but the 482 field group is present. 484 The CS MUST check the group field in the KeyShareServerHello, and get 485 the public value of the TLS client from the KeyShareCLientHello. The 486 CS performs the same checks as described in [RFC8446] section 4.2.8. 487 The CS generates the private and public Diffie Hellman or ECDH keys, 488 computes the shared key and return the KeyShareEntry server_share 489 structure defined in [RFC8446] section section 4.2.8. 491 Other methods may be defined in the future. 493 This extension MUST NOT be sent outside the LURK exchanges mentioned 494 below. When received outside these exchanges, the CS SHOULD return 495 an invalid_extension error. When the ephemeral is not supported, an 496 invalid_ephemeral error SHOULD be returned. The ephemeral extension 497 MUST NOT appear more than once in a LURK session. When the 498 extensions appears in more than one LURK exchange an 499 invalid_ephemeral error SHOULD be returned 500 +-----------------------+----------+ 501 | LURK exchange | Presence | 502 +-----------------------+----------+ 503 | s_init_early_secret | - | 504 | s_init_cert_verify | M | 505 | s_hand_and_app_secret | * | 506 | s_new_ticket | - | 507 | c_binder_key | * | 508 | c_init_early_secret | - | 509 | c_init_hand_secret | * | 510 | c_hand_secret | * | 511 | c_app_secret | - | 512 | c_cert_verify | - | 513 | c_register_ticket | - | 514 | c_post_hand | - | 515 +-----------------------+----------+ 516 M indicates the extension is mandatory 517 - indicates the extension MUST NOT be provided 518 * indicates the extension MAY be provided 520 Figure 5: Ephemeral Extension presence per LURK exchange 522 The extension data is defined as follows: 524 enum { secret_provided(0), secret_generated(1) (255)} EphemeralMethod; 526 EphemeralDataRequest { 527 EphemeralMethod method; 528 select(method) { 529 case secret_provided: 530 EphemeralSharedSecret shared_secret<0..2^16>; 531 } 532 } 534 EphemeralDataResponse { 535 select(method) { 536 case secret_generated: 537 KeyShareEntry server_share 538 } 539 } 541 4.4.2. PSK_id Extension 543 The psk_id indicates the identity of the PSK used in the key 544 schedule. 546 The LURK client MUST provide this extension only when PSK or PSK- 547 authentication is envisioned and when the PSK has not been provided 548 earlier. These exchanges are s_init_early_secret on the TLS server. 549 On the TLS client side, these exchanges are c_binder_key, 550 c_init_early_secret and c_init_hand_secret. The LURK client MUST NOT 551 provide this extension outside these exchanges. When receiving the 552 PSK extension outside these messages, the CS MUST NOT proceed to the 553 exchange and SHOULD return a invalid_format error. 555 +-----------------------+----------+ 556 | LURK exchange | Presence | 557 +-----------------------+----------+ 558 | s_init_early_secret | M | 559 | s_init_cert_verify | - | 560 | s_hand_and_app_secret | - | 561 | s_new_ticket | - | 562 | c_binder_key | M | 563 | c_init_early_secret | M | 564 | c_init_hand_secret | * | 565 | c_hand_secret | - | 566 | c_app_secret | - | 567 | c_cert_verify | - | 568 | c_register_ticket | - | 569 | c_post_hand | - | 570 +-----------------------+----------+ 571 M indicates the extension is mandatory 572 - indictaes the extension MUST NOT be provided 573 * indicates the extension MAY be provided 575 Figure 6: psk extension presence per LURK exchange 577 The extension data is defined as follows: 579 PskIdentity psk_id; //RFC8446 section 4.2.11 581 When the psk extension is provided in LURK exchange that is not 582 permitted an invalid_extension error SHOULD be returned. 584 Upon receiving this extension in the permitted LURK exchange the CS 585 checks the PSK is available. In case the PSK is not available, an 586 invalid_psk error is returned. If the PSK is not provided, a default 587 PSK is generated as described in [RFC8446] section 7.1. If the 588 default PSK is not allowed then an invalid_psk is returned. 590 4.4.3. Freshness Extension 592 The freshness_function provides perfect forward secrecy (PFS) and is 593 used by the LURK client on the TLS client to generate the 594 ClientHello.random or by the LURK client on the TLS server to 595 generate the ServerHello.random. When these randoms are provided to 596 the CS, the freshness_function MUST be provided as well. 598 Table Figure 7 lists the LURK exchange that MUST include the 599 freshness function extension as well as those where the extension may 600 be provided. 602 +-----------------------+------------+ 603 | LURK exchange | Presence | 604 +-----------------------+------------+ 605 | s_init_early_secret | - | 606 | s_init_cert_verify | M | 607 | s_hand_and_app_secret | M | 608 | s_new_ticket | - | 609 | c_binder_key | - | 610 | c_init_early_secret | M | 611 | c_init_hand_secret | M | 612 | c_hand_secret | - | 613 | c_app_secret | - | 614 | c_cert_verify | - | 615 | c_register_ticket | - | 616 | c_post_hand | - | 617 +-----------------------+------------+ 618 * indicates the extension MAY be provided 619 M indicates the extension is mandatory 620 - indictaes the extension MUST NOT be provided 622 Figure 7: freshness_funct extension presence per LURK exchange 624 The extension data is defined as follows: 626 FreshnessFunct freshness_funct; // {{I-D.mglt-lurk-tls12}} section 4.1 628 If the CS does not support the freshness_funct, an 629 invalid_freshness_funct error is returned. 631 Perfect forward secrecy is implemented in a similar manner as with 632 the TLS 1.2 extension described in [I-D.mglt-lurk-tls12] section 633 4.1.1. As ServerHello.random in TLS 1.3 do not include time, it is 634 not considered here. In addition, we use a specific context related 635 to TLS 1.3. 637 As a result, the ServerHello.random is generated as follows on the 638 TLS server. 640 ServerHello.random = freshness_funct( server_random + "tls13 pfs srv" ); 641 The ClientHello.random is generated as follows on the TLS client 642 side: 644 ClientHello.random = freshness_funct( server_random + "tls13 pfs clt" ); 646 Perfect forward secrecy applies to the ServerHello.random on the TLS 647 server and on the ClientHello.random on the TLS client. As a result, 648 PFS is provided on the TLS server as long as the ServerHello is part 649 of the Handshake Context. Similarly PFS is provided on the TLS 650 client as long as ClientHello is part of the Handshake Context. On 651 the TLS server, s_init_early_secret exchange do not have the 652 ServerHello so this exchange is not protected by PFS later exchanges 653 are. On the TLS client side, c_binder_key does not have any 654 Handshake Context so this exchange is not protected by PFS. Later 655 exchanges are. 657 4.4.4. Session ID Extension 659 A LURK client and the CS are likely to establish a LURK session. A 660 session is mandatory to be set when a given TLS session requires 661 multiple interactions between the Lurk client and the CS. Stateless 662 interactions MAY be possible with ECDHE authentication without 663 session resumption. Other configuration MAY also use other 664 configurations to determine the session, such as a TCP session for 665 example, in which case multiplexing LURK sessions over a common 666 transport layer is not possible. 668 The LURK client indicates its willing to set a session as well as the 669 session ID that should be used by the CS by inserting a Session ID 670 Extension. The LURK client MAY only insert the Extension in a LURK 671 message that initiates a session. 673 Upon receiving the Session ID Extension in an unexpected message, the 674 CS MUST return an invalid_extension error. Upon receiving the 675 Session ID Extension in an expected LURK message, The CS MAY ignored 676 the received extension indicating thus to the LURK client that no 677 session ID are needed. The LURK client MUST NOT insert a session ID 678 in the following messages. If the CS agrees on setting a LURK 679 session, the CS will return the Extension back with the expected 680 Session ID use for the communication between the LURK client and the 681 CS. When a session ID has been agreed all remaining exchange contain 682 the session ID provided by the peer. 684 The CS MAY require a session ID being agreed between the LURK client 685 and the CS. When the LURK client does not include the Session ID 686 Extension, the CS MUST respond with an invalid_session_id error. 688 The policy to have session ID on LURK message is a policy that 689 applies to the CS and LURK client cannot have different policies. 690 When session ID are enabled, the CS expect every LURK message to have 691 a session ID except for the initiating messages. 693 +-----------------------+----------+ 694 | LURK exchange | Presence | 695 +-----------------------+----------+ 696 | s_init_early_secret | * | 697 | s_init_cert_verify | * | 698 | s_hand_and_app_secret | - | 699 | s_new_ticket | - | 700 | c_binder_key | - | 701 | c_init_early_secret | * | 702 | c_init_hand_secret | * | 703 | c_hand_secret | | 704 | c_app_secret | - | 705 | c_cert_verify | - | 706 | c_register_ticket | - | 707 | c_post_hand | - | 708 +-----------------------+----------+ 709 * indicates the extension MAY be provided 710 - indicates the extension MUST NOT be provided 712 Figure 8: Presence of the Session ID Extension in the various LURK 713 exchanges 715 The extension data is defined as follows: 717 uint32 session_id 719 The session ID agreement leads to the definition of the following 720 structure that will be embedded into any non initiating LURK 721 exchange. 723 struct{ 724 select( session_id_agreed ){ 725 case True: 726 unint32 session_id 727 case False: 728 } 729 } SessionID 731 session_id_agreed: indicates the LURK client and the CS have agreed 732 on using session ID as well as the respective session ID value to 733 use. 735 session_id can take the following values: 1. session_id_cs: the 736 session ID provided by the CS to the LURK client in the Session ID 737 extension. This is the value the LURK client MUST use in any 738 subsequent exchange. That value will be used by the CS to associate 739 its internal context to the session. 2. session_id_client: the 740 session ID provided by the LURK client to the CS in the Session ID 741 extension. This is the value the CS MUST use in any subsequent 742 exchange. That value will be used by the LURK client to associate 743 its internal context to the session. 745 4.5. Signing Sub-Exchange 747 The signature requires the signature scheme (sig_algo), the 748 designated private key (key_id), as well as sufficient context to 749 generate the necessary data to be signed. In our case the necessary 750 context is provided by the LURKCertificate, assuming the CS will have 751 the necessary Handshake Context. The latest may be provided in a 752 combination of a secret request. 754 key_id is processed as described in [I-D.mglt-lurk-tls12] section 755 4.1. If the CS does not support the KeyPairIdType an 756 invalid_key_id_type is returned. If the CS does not recognize the 757 key, an invalid_key_id error is returned. 759 sig_algo designates the signature algorithm scheme, and it is defined 760 in {{!RFC8446} section 4.2.3. When the CS does not support the 761 signature scheme an invalid_signature_scheme error is returned. 763 The certificate is a public data that may repeat over multiple 764 distinct TLS handshakes. To limit the load of unnecessary 765 information being transmitted multiple times, the LURKCertificate 766 enables to carry the index of the Certificate structure rather than 767 the structure itself. When the lurk_certificate_type is set to 768 sha256_32, the index of the Certificate structure is sent. The 769 current specification generates the index using sha256_32, that is 770 the first 32 bits of the hash of the Certificate structure using 771 SHA256 as the hashing function. When lurk_certificate_type is set to 772 X509 or RawPublicKey the full Certificate structure is expected. 773 When the CS does not support the certificate_type, an 774 invalid_certificate_type error is returned. When the Certificate 775 structure does not match the private key, an invalid_certificate 776 error is returned. 778 Signing operations are described in [RFC8446] section 4.4.3. The 779 context string is derived from the role and the type of the LURK 780 exchange as described below. The Handshake Context is taken from the 781 key schedule context. 783 +--------------------+-------------------------------------+ 784 | type | context | 785 +--------------------+-------------------------------------+ 786 | s_init_cert_verify | "TLS 1.3, server CertificateVerify" | 787 | c_cert_verify | "TLS 1.3, client CertificateVerify" | 788 +--------------------+-------------------------------------+ 790 The CS computes the signature as described in [RFC8446] section 791 4.4.3. and returns signature in SigningResponse. When the CS does 792 not have the necessary Handshake Context, context or is unable to 793 proceeds to the signing operation, an invalid_certificate_verify 794 error is returned. 796 The structure is represented below: 798 enum { X509(0), RawPublicKey(1), 799 sha256_32(128) (255)}; LURK13CertificateType 801 struct { 802 LURK13CertificateType certificate_type; 803 select (lurk_certificate_type) { 804 case sha256_32: 805 uint32 hash_cert; 806 case X509, RawPublicKey: 807 Certificate certificate; // RFC8446 section 4.4.2 808 }; 809 } LURK13Certificate; 811 struct { 812 KeyPairId key_id; // draft-mglt-lurk-tls12 section 4.1 813 SignatureScheme sig_algo; //RFC8446 section 4.2.3. 814 LURKCertificate certificate; 815 } SigningRequest; 817 struct { 818 opaque signature<0..2^16-1>; //RFC8446 section 4.4.3. 819 } SigningResponse; 821 5. LURK exchange on the TLS server 823 This section describes the LURK exchanges that are performed on the 824 TLS server. The state diagram is provided in section Section 10.2 826 5.1. s_init_early_secret 828 A TLS server MAY receive a ClientHello that proposes PSK or PSK-ECDHE 829 authentication via the pre_shared_key and psk_key_exchange_modes 830 extensions. Depending on its policies, the TLS server MAY decide to 831 proceed to such authentication. It chooses a PSK identity so the 832 LURK client initiates a key schedule context (ks_ctx) that will 833 manage the session with the CS. This session is initiated with a 834 s_init_early_secret exchange. 836 The binder_key MUST be requested, since it is used to validate the 837 PSK. 839 The TLS client MAY indicate support for early application data via 840 the early_data extension. Depending on the TLS server policies, it 841 MAY accept early data and request the client_early_traffic_secret. 843 The TLS server MAY have specific policies and request 844 early_exporter_master_secret. 846 Upon receiving an s_init_early_secret request, the CS proceeds the 847 SecretRequest as described in section Section 4.4. 849 The CS MUST check pre_shared_key and psk_key_exchange_modes 850 extensions are present in the ClientHello. If these extensions are 851 not present, a invalid_handshake error SHOULD be returned. 853 The CS MUST ignore the client_early_traffic_secret if early_data 854 extension is not found in the ClientHello. The Cryptographic Service 855 MAY ignore the request for client_early_traffic_secret, in any case. 856 The CS MAY ignored the request for early_exporter_master_secret. 858 struct{ 859 SecretRequest secret_request 860 } InitEarlySecretRequest 862 struct{ 863 SecretResponse secret_response 864 } InitEarlySecretResponse 866 secret_request: The structure associated to the secret request 867 defined in section Section 4.4 869 secret_response: The structure associated to the secret request 870 defined in section Section 4.4. 872 5.2. s_init_cert_verify 874 A TLS server MAY receive a ClientHello that proposes ECDHE 875 authentication with a key_share extension. Depending on its 876 policies, the TLS server MAY decide to proceed to such authentication 877 and indicate it to the LURK client so it initiates a key schedule 878 context (ks_ctx) that will manage the session with the CS. This 879 session is initiated with a s_init_cert_verify exchange. 881 The Cryptographic MUST ensure the ServerHello has selected the ECDHE 882 authentication that is a key_share extension is present and no 883 pre_shared_key extension is present. If these conditions are not 884 met, a invalid_handshake error SHOULD be returned. 886 In order to provide generate the client_application_traffic_secret_0 887 and server_application_traffic_secret_0, the CS generates the server 888 Finished. This value is computed to avoid multiple round trips. 889 This value is not returned to the LURK client and needs to be 890 computed again by the TLS server. 892 After the exchange is completed, the TLS server is able to build and 893 return the ServeHello and complete the TLS handshake. 895 If the CS has been configured not to handle session resumption. The 896 session is finished and ks_ctx SHOULD be deleted and some 897 implementations MAY NOT create the ks_ctx. 899 struct{ 900 SecretRequest secret_request 901 SigingRequest signing_request 902 }InitCertVerifyRequest 904 struct{ 905 SecretResponse secret_response 906 SigingResponse signing_response 907 }InitCertVerifyResponse 909 secret_request and secret_response are defined in section 910 Section 5.1. 912 5.3. s_hand_and_app_secret 914 The s_hand_and_app_secret is necessary to complete the ServerHello 915 and always follows an s_init_early_secret LURK exchange. Such 916 sequence is guaranteed by the session_id and cookie mechanism. In 917 case of unknown session_id or an unexpected cookie value, an 918 invalid_request error SHOULD be returned. 920 The LURK client MUST ensure that PSK or PSK-ECDHE authentication has 921 been selected via the presence of the pre_shared_key extension in the 922 the ServerHello. In addition, the selected identity MUST be the one 923 provided in the psk extension of the previous s_init_early_secret 924 exchange. 926 The LURK client MAY request the exporter_master_secret depending on 927 its policies. The CS MAY ignore the request based on its policies. 929 Similarly to the s_init_cert_verify, if session resumption is not 930 provided by the CS, the LURK session ends after this exchange and 931 ks_ctx SHOULD be removed. 933 struct{ 934 SessionID session_id_cs 935 SecretRequest secret_request 936 } HandAndAppRequest 938 struct{ 939 SessionID session_id_client 940 SecretResponse secret_response 941 } HandAndAppResponse 943 5.4. s_new_tickets 945 new_session ticket handles session resumption. It enables to 946 retrieve NewSessionTickets that will be forwarded to the TLS client 947 by the TLS server to be used later when session resumption is used. 948 It also provides the ability to delegate the session resumption 949 authentication from the CS to the TLS server. In fact, if the LURK 950 client requests and receives the resumption_master_secret it is able 951 to emit on its own NewSessionTicket. As a result s_new_ticket LURK 952 exchanges are only initiated if the TLS server expects to perform 953 session resumption and the CS responds only if if session_resumption 954 is enabled. If session resumption is not enabled, the Cryptographic 955 MAY have ended the LURK session and the s_new_ticket will be ignored 956 or responded with a invalid_request error. 958 The CS MAY responds with a resumption_master_secret based on its 959 policies. 961 The LURK client MAY perform multiple s_new_ticket exchanges before 962 the session between the LURK client and the CS is in a finished state 963 with ks_ctx deleted. 965 struct { 966 SessionID session_id_cs 967 uint8 ticket_nbr; 968 unint16 key_request; 969 Handshake handshake_context<0..2^32> //RFC8446 section 4. 970 } NewTicketRequest; 972 struct { 973 SessionID session_id_client 974 Secrets secrets 975 NewSessionTicket ticket_list<0..2^16-1>; //RFC8446 section 4.6.1. 976 } NewTicketResponse; 978 crypto_service_session_id, crypto_service_cookie, 979 lurk_client_session_id, and lurk_client_cookie are defined in section 980 Section 5.3. key_request is defined in section Section 4.1. 982 ticket_nbr: designates the requested number of NewSessionTicket. In 983 the case of delegation this number MAY be set to zero. The CS MAY 984 responds with less tickets when the value is too high. 986 6. LURK exchange on the TLS client 988 This section describes the LURK exchanges that are performed on the 989 TLS server. The state diagram is provided in section Section 10.1 991 6.1. c_binder_key 993 The c_binder_key LURK exchange is initiates a LURK session when the 994 TLS client is willing to propose a PSK for PSK or PSK-ECDHE 995 authentication. 997 The handshake_context is empty as the ClientHello is under 998 construction. 1000 When a LURK client proposes multiple PSK, multiple binder_keys are 1001 requested. 1003 The c_binder_key is equivalent to a secret request LURK exchange and 1004 there is no creation of a ks_ctx. 1006 ``` struct{ SecretRequest secret_request } BinderKeyRequest 1008 struct{ SecretResponse secret_response } BinderKeyResposne ``` 1010 6.2. c_init_early_secret 1012 c_init_early_secret on the TLS client side works similarly as the 1013 s_init_early_secret LURK exchange on the TLS server as described in 1014 section Section 5.1. One key difference is that the c_binder_key is 1015 not requested during that LURK exchange, as a result, this LURK 1016 exchange MAY be omited even when PSK or PSK-ECDHE authentication has 1017 been chosen by the TLS client. The c_init_early_secret will only be 1018 performed in the case of 0-RTT handshake or when early exporters are 1019 required. 1021 6.3. c_hand_secret 1023 The c_hand_secret is performed after an c_init_early_secret LURK 1024 exchange. This exchange is performed in the case of an PSK or PSK- 1025 ECDHE authentication and coherence with the Handshake Context MUST be 1026 checked by the LURK client as well as by the CS as described in 1027 Section 6.2 and section Section 5.3. 1029 The structures of the c_hand_secret follow those of the 1030 s_hand_and_app_secret described in section Section 5.3. 1032 6.4. c_init_hand_secret 1034 Coherence between with the Handshake Context and the authentication 1035 ECDHE versus PSK or PSK-ECDHE) is performed as described in section 1036 Section 6.2 and section Section 5.3. The LURK client and the CS MUST 1037 ensure such coherence. A Signing sub exchange MUST only be performed 1038 when ECDHE authentication has been selected which is determined by 1039 the presence of a key_share extension as well as the absence of a 1040 pre_shared_key extension in the ServerHello. 1042 Only the client_handshake_traffic_secret_0 and 1043 server_handshake_traffic_secret_0 secrets MAY be requested. 1045 struct{ 1046 SecretRequest secret_request 1047 select (handshake_context.ecdhe_selected){ 1048 case : 1049 SigningRequest signing_request 1050 }; 1051 }InitHandshakeRequest 1053 struct{ 1054 SecretResponse secret_response 1055 select (handshake_context.ecdhe_selected){ 1056 case : 1057 SigningResponse signing_response 1058 }; 1059 }InitHandsahkeResponse 1061 6.5. c_app_secret 1063 The c_app_secret LURK exchange is performed when no TLS client 1064 authentication has been requested, i.e. CertificateRequest message is 1065 not provided in the flight of the ServerHello. The LURK client and 1066 the CS MUST ensure no CertificateRequest is present in the Handshake 1067 Context. 1069 Only the client_application_traffic_secret_0 and 1070 server_application_traffic_secret_0 secrets MAY be requested. 1072 The structure follows the one of the c_hand_secret described in 1073 section Section 6.3. 1075 After the c_app_secret LURK exchange, unless the TLS client supports 1076 session resumption or post_handshake, the LURK session is finished. 1077 The support for post_handshake by the TLS client is indicated by the 1078 post_handshake_auth extension. 1080 6.6. c_cert_verify 1082 The c_cert_verify LURK exchange is performed when TLS client 1083 authentication has been requested by the TLS server. When performed, 1084 the LURK client and the CS MUST check the presence of a 1085 CertificateRequest structure in the Handshake Context. When not 1086 present, a invalid_handshake error SHOULD be returned. 1088 After the c_app_secret LURK exchange, unless the TLS client supports 1089 session resumption or post_handshake, the LURK session is finished. 1091 The support for post_handshake by the TLS client is indicated by the 1092 post_handshake_auth extension. 1094 The CertVerifyRequest and CertVerifyResponse structures are used for 1095 this LURK exchange. 1097 struct{ 1098 SessionID session_id_cs 1099 InitCertVerifyRequest cert_request 1100 }CertVerifyRequest 1102 struct{ 1103 SessionID session_id_client 1104 InitCertVerifyRequest cert_response 1105 }CertVerifyResponse 1107 6.7. c_register_tickets 1109 The c_register_ticket is only used when the TLS client intend to 1110 perform session resumption. This LURK exchange has three functions. 1111 First, it is used to register the handshake in order to provide the 1112 full TLS handshake. Such information will be necessary to generate 1113 the PSK value during the future session resumptions. Second, the 1114 LURK client MAY provide one or multiple NewSessionTickets. These 1115 tickets will be helpful for the session resumption to bind the PSK 1116 value to some identities. Third, the LURK client MAY retrieve the 1117 resumption_master_secret when session resumption is being delegated 1118 by the CS to the TLS client. 1120 The first c_register_ticket MUST carry the TLS handshake and future 1121 c_register_ticket LURK exchange MUST have a handshake_context of zero 1122 length. If these conditions are not met, the CS SHOULD return a 1123 invalid_handshake error. 1125 The first c_register_ticket MAY request the 1126 session_resumption_master. Next register_new_session MUST not 1127 request that secret.If these conditions are not met, a 1128 invalid_key_request error is returned. 1130 The ticket_list MAY have zero NewSessionTickets for the first 1131 register_new_Session_ticket. Next LURK exchanges MUST have at least 1132 one NewSessionTickets. 1134 struct { 1135 SessionID session_id_cs 1136 Handshake handshake_context<0..2^32>; //RFC8446 section 4. 1137 NewSessionTicket ticket_list<0..2^16-1>; //RFC8446 section 4.6.1. 1138 uint16 key_request; 1139 } RegisterTicketRequest; 1141 struct { 1142 SessionID session_id_client 1143 } RegisterTicketResponse; 1145 crypto_service_session_id, crypto_service_cookie, 1146 lurk_client_session_id, and lurk_client_cookie are defined in section 1147 Section 5.3. handshake_contex is defined in section Section 4.3. 1148 NewSessionTicket is defined in [RFC8466] section 4.6.1. key_request 1149 is defined in Section 4.1. 1151 6.8. c_post_hand 1153 The c_post_hand LURK exchange is performed in order to the client to 1154 authenticate after the TLS handshake has complete. The TLS client 1155 MUST NOT proceed to this exchange if post handshake support has not 1156 been announced in the ClientHello with the post_handshake_auth 1157 extension. When such extension is not found the CS MUST return a 1158 invalid_handshake error. 1160 struct { 1161 SessionID session_id_cs 1162 Handshake handshake_context<0..2^32>; //RFC8446 section 4. 1163 int16 app_n; 1164 } PostHandRequest; 1166 struct { 1167 SessionID session_id_client 1168 } PostHandResponse; 1170 handshake_context is defined in section Section 4.3 1172 app_n: describes the number of iteration of the session keys. 1174 7. Security Considerations 1176 Security credentials as per say are the private key used to sign the 1177 CertificateVerify when ECDHE authentication is performed as well as 1178 the PSK when PSK or PSK-ECDHE authentication is used. 1180 The protection of these credentials means that someone gaining access 1181 to the CS MUST NOT be able to use that access from anything else than 1182 the authentication of an TLS being established. In other way, it 1183 MUST NOT leverage this for: * any operations outside the scope of TLS 1184 session establishment. * any operations on past established TLS 1185 sessions * any operations on future TLS sessions * any operations on 1186 establishing TLS sessions by another LURK client. 1188 The CS outputs are limited to secrets as well as NewSessionTickets. 1189 The design of TLS 1.3 make these output of limited use outside the 1190 scope of TLS 1.3. Signature are signing data specific to TLS 1.3 1191 that makes the signature facility of limited interest outside the 1192 scope of TLS 1.3. NewSessionTicket are only useful in a context of 1193 TLS 1.3 authentication. 1195 ECDHE and PSK-ECDHE provides perfect forward secrecy which prevents 1196 past session to be decrypted as long as the secret keys that 1197 generated teh ECDHE share secret are deleted after every TLS 1198 handshake. PSK authentication does not provide perfect forward 1199 secrecy and authentication relies on the PSK remaining sercet. The 1200 Cryptographic Service does not reveal the PSK and instead limits its 1201 disclosure to secrets that are generated from the PSK and hard to be 1202 reversed. 1204 Future session may be impacted if an attacker is able to authenticate 1205 a future session based on what it learns from a current session. 1206 ECDHE authentication relies on cryptographic signature and an ongoing 1207 TLS handshake. The robustness of the signature depends on the 1208 signature scheme and the unpredictability of the TLS Handshake. PSK 1209 authentication relies on not revealing the PSK. The CS does not 1210 reveal the PSK. TLS 1.3 has been designed so secrets generated do 1211 not disclose the PSK as a result, secrets provided by the 1212 Cryptographic do not reveal the PSK. NewSessionTicket reveals the 1213 identity (ticket) of a PSK. NewSessionTickets.ticket are expected to 1214 be public data. It value is bound to the knowledge of the PSK. The 1215 Cryptographic does not output any material that could help generate a 1216 PSK - the PSK itself or the resumption_master_secret. In addition, 1217 the Cryptographic only generates NewSessionTickets for the LURK 1218 client that initiates the key schedule with CS with a specific way to 1219 generate ctx_id. This prevents the leak of NewSessionTickets to an 1220 attacker gaining access to a given CS. 1222 If an the attacker get the NewSessionTicket, as well as access to the 1223 CS of the TLS client it will be possible to proceed to the 1224 establishment of a TLS session based on the PSK. In this case, the 1225 CS cannot make the distinction between the legitimate TLS client and 1226 teh attacker. This corresponds to the case where the TLS client is 1227 corrupted. 1229 Note that when access to the CS on the TLS server side, a similar 1230 attack may be performed. However the limitation to a single re-use 1231 of the NewSessionTicket prevents the TLS server to proceed to the 1232 authentication. 1234 Attacks related to other TLS sessions are hard by design of TLS 1.3 1235 that ensure a close binding between the TLS Handshake and the 1236 generated secrets. In addition communications between the LURK 1237 client and the CS cannot be derived from an observed TLS handshake 1238 (freshness function). This makes attacks on other TLS sessions 1239 unlikely. 1241 8. IANA Considerations 1243 9. Acknowledgments 1245 10. Annex 1247 10.1. LURK state diagrams on TLS client 1249 The state diagram sums up the LURK exchanges. The notations used are 1250 defined below: 1252 LURK exchange indicates a LURK exchange is stated by the LURK client 1253 or is received by the CS ---> (resp. <---) indicates a TLS message is 1254 received (resp. received). These indication are informative to 1255 illustrates the TLS state machine. 1257 CAPITAL LETTER indicates potential configuration parameters or policy 1258 applied by the LURK client or the CS. The following have been 1259 considered: 1261 o PSK, PSK-ECDHE, ECDHE that designates the authentication method. 1262 This choice is made by the LURK client. The choice is expressed 1263 by a specific LURK exchange as well as from the TLS Handshake 1264 Context. 1266 o SESSION_RESUMPTION indicates the session resumption has been 1267 enabled on the LURK client or the CS. As a consequence the TLS 1268 client is considered performing session resumption and the TLS 1269 server MUST make session resumption possible. 1271 o POST_HANDSHAKE_AUTH indicates that post handshake authentication 1272 proposed by the TLS client in a post_handshake_auth extension is 1273 not ignored by the LURK client or on the CS. 1275 Note that SESSION_RESUMPTION, POST_HANDSAHKE_AUTH are mostly 1276 informative and the current specification does not mandate to have 1277 such configuration parameters. By default, these SHOULD be enabled. 1279 Other potential configuration could be proposed for configuring LURK 1280 client or CS policies. These have not been represented in the state 1281 diagram and the specification does not mandate to have these 1282 parameters implemented. 1284 o CLIENT_EARLY_TRAFFIC indicates that client early traffic MAY be 1285 sent by the TLS client and the notification by the TLS client in 1286 the ClientHello via the early_data extension MUST be considered. 1288 o EARLY_EXPORTER_MASTER_SECRET indicates whether or not 1289 early_exporter_master_secret MUST be requested by the LURK client 1290 and responded by the CS. 1292 o MASTER_EXPORTER indicates whether or not exporter_master_secret 1293 MUST be requested by the LURK client and responded by the CS. 1295 o SESSION_RESUMPTION_DELEGATION indicates whether or not 1296 session_resumption_master is requested by the LURK client and 1297 responded by the CS. 1299 o MAX_SESSION_TICKET_NBR indicates the maximum number of tickers 1300 that can be requested or provided by the LURK client and provided 1301 by the CS. It is strongly RECOMMENDED to have such limitations 1302 being configurable. 1304 The analysis of the TLS Handshake Context enables to set some 1305 variables that can be used by the LURK client to determine which LURK 1306 exchange to proceed as well as by the CS to determine which secret 1307 MAY be responded. The following variables used are: 1309 psk_proposed: The TLS Client is proposing PSK authentication by 1310 including a pre_shared_key and a psk_key_exchange_mode extensions in 1311 the ClientHello. 1313 dhe_proposed: The received or to be formed ClientHello contains a 1314 key_share extensions. 1316 psk_accepted: The chosen authentication method is pSK or PSK-ECDHE 1317 which is indicated via the pre_shared_key extension in the 1318 ServerHello. 1320 0rtt_proposed: Indicates the TLS client supports early data which is 1321 indicated by the early_data extension in the ClientHello. 1323 post_handshake_proposed: indicates the TLS client supports post 1324 handshake authentication which is indicated by the presence of a 1325 post_handshake_auth extension in the ClientHello. 1327 finished: indicates that the LURK client or the CS has determined the 1328 session shoudl be closed an ks_ctx are deleted. 1330 The CS contains three databases: 1332 CTX_ID_DB: database that contains the valid ctx_id of type opaque. 1334 PSK_DB: contains the list of PSKs, with associated parameters such as 1335 Hash function. This database includes the session resumption 1336 tickets. 1338 Key_DB: contains the asymetric signing keys with supported signing 1339 algorithms. 1341 10.1.1. LURK client 1342 TLS Client Policy for authentication 1343 PSK, PSK-ECDHE ECDHE 1344 | | 1345 | | 1346 v | 1347 psk ---> +--------------------+ | 1348 | c_binder_key | | 1349 +--------------------+ | 1350 EARLY_EXPORTER, 0-RTT | | 1351 v | | 1352 /------------------------\ NO | 1353 \------------------------/----+ | 1354 YES v | | 1355 +---------------------+ | | 1356 | c_init_early_secret | | | 1357 +---------------------+ | | 1358 ClientHello | | | 1359 <---- +<-----------------+--------+ 1360 ServerHello YES v 1361 ----> +-------------------------------------+ 1362 | c_init_hand_secret or c_hand_secret | 1363 +-------------------------------------+ 1364 | 1365 /--------------------\ NO 1366 | CertificateRequest |------+ 1367 \--------------------/ | 1368 YES v v 1369 +-------------------+------------------+ 1370 | c_cert_verify | c_app_secret | 1371 +-------------------+------------------+ 1372 client Finished | | 1373 <---- +-----------+---------+ 1374 | 1375 +--------------------------------------+ 1376 | LURK client post handshake exchanges | 1377 +--------------------------------------+ 1379 The LURK client post handshake diagram is represented below: 1381 POST_HANDSHAKE_AUTH | 1382 v v 1383 /-------------------------\ NO 1384 | post_hand_auth_proposed |------+ 1385 \-------------------------/ | 1386 YES v | 1387 +-----------------------------+ | 1388 | c_register_tickets | | 1389 | (empty NewSessionTickets) | | 1390 +-----------------------------+ | 1391 | | 1392 +<-----------------+ 1393 | 1394 +<-----------------------------------------------+ 1395 | | 1396 +------------------------------+ | 1397 SESSION_RESUMPTION | POST_HANDSHAKE_AUTH | | 1398 client Finished | | CertificateRequest | | | 1399 NewSessionTickets| | | v v | 1400 | v v | /-------------------------\NO | 1401 | /-------------\ NO +---> | post_hand_auth_proposed |--+ | 1402 +----> \-------------/---------+ \-------------------------/ | | 1403 YES v | YES v | | 1404 +-----------------------------+ | +-------------------------+ | | 1405 | c_register_ticket | | | c_post_hand | | | 1406 +-----------------------------+ | +-------------------------+ | | 1407 v v v | | 1408 +-----------------+----------+---+----------------+ | 1409 v | 1410 /--------------------\ NO | 1411 | finished |----------+ 1412 \--------------------/ 1413 YES v 1414 +-------------------------+ 1415 | LURK exchanges Finished | 1416 +-------------------------+ 1418 10.1.2. Cryptographic Service 1419 TLS13Request 1420 | 1421 /---------------------------\NO /-------------------------------\NO 1422 | type is c_init_early_secret|-->| type is c_init_hand_secret |-+ 1423 \---------------------------/ \-------------------------------/ | 1424 | | +------------------+ 1425 | +------------+ | 1426 | v | 1427 | /-------------------\NO /----------------\NO 1428 | | psk_selected |-+ | session,cookie | +-------+ 1429 | \------------------ / | | consistent |---| ERROR | 1430 | YES | | \----------------/ +-------+ 1431 +----------------+ | | 1432 PSK, PSK-ECDHE | | ECHDE | 1433 v +-------------+ | 1434 /-------------------\NO +-------+ | | 1435 | psk_key in PSK_DB |---| ERROR | | | 1436 \-------------------/ +-------+ | | 1437 +-------------------------+ | 1438 | | 1439 +-------------+ | 1440 | Init ks_ctx | | 1441 +-------------+ | 1442 | | 1443 +---------------------------+ 1444 | 1445 v 1446 +---------------------------+ 1447 | process the request | 1448 | update CTX_DB, PSK_DB | 1449 +---------------------------+ 1451 10.2. LURK state diagrams on TLS server 1453 10.2.1. LURK client 1454 TLS Server Policy for authentication 1455 received PSK, PSK-ECDHE, ECDHE 1456 ClientHello | | 1457 ----> v v 1458 psk ---->+----------------------+ +----------------------+ 1459 | Init ks_ctx | | Init ks_ctx | 1460 +----------------------+ +----------------------+ 1461 v | 1462 +---------------------+ | 1463 | s_init_early_secret | | 1464 +---------------------+ | 1465 | | 1466 to be formed YES v v 1467 ServerHello +--------------------------+ +-------------------------+ 1468 ----> | s_hand_and_app_secret | | s_init_cert_verify | 1469 +--------------------------+ +-------------------------+ 1470 | | 1471 +---------------------------+ 1472 | 1473 v 1474 +--------------------------------------+ 1475 | LURK client post handshake exchanges | 1476 +--------------------------------------+ 1478 10.2.2. Cryptographic Service 1479 TLS13Request 1480 | 1481 /---------------------------\NO /---------------------------\NO 1482 |type is s_init_early_secret|-->| type is s_init_cert_verify |-+ 1483 \---------------------------/ \---------------------------/ | 1484 PSK, | +--------------------+ 1485 PSK-ECDHE v | 1486 /-------------------\NO +-------+ /----------------\NO 1487 | psk_key in PSK_DB |---| ERROR | | session,cookie | +-------+ 1488 \-------------------/ +-------+ | consistent |---| ERROR | 1489 | \----------------/ +-------+ 1490 v | 1491 +-------------+ | 1492 | Init ks_ctx | | 1493 +-------------+ | 1494 | | 1495 +-----------------------------+ 1496 | 1497 v 1498 +---------------------------+ 1499 | process the request | 1500 | update CTX_DB, PSK_DB | 1501 +---------------------------+ 1503 10.3. TLS handshakes with Cryptographic Service 1505 This section is non normative. It illustrates the use of LURK in 1506 various configurations. 1508 The TLS client may propose multiple ways to authenticate the server 1509 (ECDHE, PSK or PSK-ECDHE). The TLS server may chose one of those, 1510 and this choice is reflected by the LURK client on the TLS server. 1511 In other words, this decision is out of scope of the CS. 1513 The derivation of the secrets is detailed in {{!RFC8446)) section 1514 7.1. Secrets are derived using Transcript-Hash and HKDF, PSK and 1515 ECDHE secrets as well as some Handshake Context. 1517 The Hash function: When PSK or PSK-ECDHE authentication is selected, 1518 the Hash function is a parameter associated to the PSK. When ECDHE, 1519 the hash function is defined by the cipher suite algorithm 1520 negotiated. Such algorithm is defined in the cipher_suite extension 1521 provided in the ServerHello which is provided by the LURK client in 1522 the first request when ECDHE authentication is selected. 1524 PSK secret: When PSK or PSK-ECDHE authentication is selected, the PSK 1525 is the PSK value identified by the identity. When ECDHE 1526 authentication is selected, the PSK takes a default value of string 1527 of Hash.length bytes set to zeros. 1529 ECDHE secret: When PSK or PSK-ECDHE authentication is selected, the 1530 ECDHE secret takes the default value of a string of Hash.length bytes 1531 set to zeros. The Hash is always known as a parameter associated to 1532 the selected PSK. When ECDHE authentication is selected, the ECDHE 1533 secret is generated from the secret key (ephemeral_sercet) provided 1534 by the LURK client and the counter part public key in the key_share 1535 extension. When the LURK client is on the TLS client, the public key 1536 is provided in the ServerHello. When the LURK client is on the TLS 1537 Server, the public key is provided in the ClientHello. When ECDHE 1538 secret is needed, ClientHello...ServerHello is always provided to the 1539 CS. 1541 Handshake Context: is a subset of Handshake messages that are 1542 necessary to generated the requested secrets. The various Handshake 1543 Contexts are summarized below: 1545 +------------------------------------+--------------------------------+ 1546 | Key Schedule secret or key | Handshake Context | 1547 +---------------------------------------------------------------------+ 1548 | binder_key | None | 1549 | client_early_traffic_secret | ClientHello | 1550 | early_exporter_master_secret | ClientHello | 1551 | client_handshake_traffic_secret | ClientHello...ServerHello | 1552 | server_handshake_traffic_secret | ClientHello...ServerHello | 1553 | client_application_traffic_secret_0 | ClientHello...server Finished | 1554 | server_application_traffic_secret_0 | ClientHello...server Finished | 1555 | exporter_master_secret | ClientHello...server Finished | 1556 | resumption_master_secret | ClientHello...client Finished | 1557 +---------------------------------------------------------------------+ 1559 The CS has always the Hash function, the PSK and ECDHE secrets and 1560 the only remaining parameter is the Handshake Context. The remaining 1561 sections will only focus on checking the Handshake Context available 1562 to the CS is sufficient to perform the key schedule. 1564 When ECDHE authentication is selected both for the TLS server or the 1565 TLS client, a CertificateVerify structure is generated as described 1566 in [RFC8446] section 4.4.3.. CertificateVerify consists in a 1567 signature over a context that includes the output of Transcript- 1568 Hash(Handshake Context, Certificate) as well as a context string. 1569 Both Handshake Context and context string depends on the Mode which 1570 is set to server in this case via the configuration of the LURK 1571 server. Similarly to the key schedule, the Hash function is defined 1572 by the PSK or the ServerHello. The values for the Handshake Context 1573 are represented below: 1575 +-----------+-------------------------+-----------------------------+ 1576 | Mode | Handshake Context | Base Key | 1577 +-----------+-------------------------+-----------------------------+ 1578 | Server | ClientHello ... later | server_handshake_traffic_ | 1579 | | of EncryptedExtensions/ | secret | 1580 | | CertificateRequest | | 1581 | | | | 1582 | Client | ClientHello ... later | client_handshake_traffic_ | 1583 | | of server | secret | 1584 | | Finished/EndOfEarlyData | | 1585 | | | | 1586 | Post- | ClientHello ... client | client_application_traffic_ | 1587 | Handshake | Finished + | secret_N | 1588 | | CertificateRequest | | 1589 +-----------+-------------------------+-----------------------------+ 1591 When ECDHE authentication is selected, the CS generates a Finished 1592 message, which is a MAC over the value Transcript-Hash(Handshake 1593 Context, Certificate, CertificateVerify) using a MAC key derived from 1594 the Base Key. As a result, the same Base Key and Handshake Context 1595 are required for its computation describe din [RFC8466] section 1596 4.4.4.. 1598 10.4. TLS 1.3 ECDHE Full Handshake 1600 This example illustrates the case of a TLS handshake where the TLS 1601 server is authenticated using ECDHE only, that is not PSK or PSK- 1602 ECDHE authentication is provided and so session resumption is 1603 provided either. 1605 10.4.1. TLS Client: ClientHello 1607 The TLS client does not provides any PSK and omits the pre_shared_key 1608 as well as the psk_key_exchange_mode extensions. Note that omitting 1609 the psk_key_exchange_mode extension prevents the TLS client to 1610 perform further session resumption. 1612 The TLS client does not need any interaction with the Cryptographic 1613 Service to generate and send the ClientHello message to the TLS 1614 server. 1616 TLS Client TLS Server 1618 Key ^ ClientHello 1619 Exch | + key_share 1620 v + signature_algorithms ---------> 1622 10.4.2. TLS Server: ServerHello 1624 Upon receiving the ClientHello, the TLS server determines the TLS 1625 client requests an ECDHE authentication. The TLS server initiates a 1626 LURK session to provide ECDHE authentication as represented below: 1628 TLS Client TLS Server 1630 ServerHello ^ Key 1631 + key_share | Exch 1632 {EncryptedExtensions} ^ Server 1633 {CertificateRequest*} v Params 1634 {Certificate} ^ 1635 {CertificateVerify} | Auth 1636 {Finished} v 1637 <-------- [Application Data*] 1639 The LURK Client on the TLS server initiates a s_init_cert_verify to 1640 retrieves the necessary secrets to finish the exchange and request 1641 the generation of the signature (certificate_verify) carried by the 1642 CertificateVerify TLS structure. 1644 The s_init_cert_verify request uses a InitCertVerifyRequest structure 1645 which is composed of two substructures: A SecretRequest structure 1646 (secret_request) is in charge of requesting the necessary secrets to 1647 decrypt and encrypt the TLS handshake as well as the applications 1648 carried over the TLS session. Finally a SigningRequest substructure 1649 (signing_request) is used to request the certificate_verify payload. 1651 The secret_request carries the requested secrets as well as the 1652 necessary parameters to generate the secrets. In our case, the 1653 requested secrets are the handshake secrets (h_c, h_s) as well as the 1654 application secrets (a_c, a_s). This corresponds to the most 1655 expected use cases, though other use case may require different 1656 secrets to be requested. Theses requests are indicated in the 1657 key_request. The necessary Handshake Context is provided through 1658 handshake_context which is set to ClientHello ... 1659 EncryptedExtensions. The ECDHE shared secret is provided in this 1660 example via the ephemeral extension. In our case, the secret key is 1661 provided directly thought other means may be used. In particularly 1662 providing the secret key implies the dhe parameters have been 1663 generated outside the CS. The freshness function is provided through 1664 the freshness extension. 1666 The signing_request provides the key_id that identifies the private 1667 key used to generate the signature, the algorithm use dto generate 1668 the signature (sig_algo) as well as the certificate. The certificate 1669 carries information to generate the Certificate structure of the 1670 ServerHello, and may not be the complete certificate chain but only 1671 an index. 1673 TLS Server 1674 Lurk Client CS 1675 InitCertVerifyRequest 1676 secret_request 1677 key_request = h_c, h_s, a_c, a_s 1678 handshake_context = ClientHello ... EncryptedExtensions 1679 ext 1680 ephemeral = dhe_secret 1681 freshness 1682 session_id 1683 signing_request 1684 key_id, 1685 sig_algo 1686 certificate 1687 --------> 1688 InitCertVerifyResponse 1689 secret_response 1690 keys 1691 ext 1692 session_id 1693 signing_response 1694 certificate_verify 1695 <--------- 1697 Upon receiving the InitCertificateRequest, the CS initiates a context 1698 associated to the newly created LURK session. 1700 The secrets are generated from the TLS 1.3 key schedule describe din 1701 [RFC8446] and requires as input PSK, ECDHE as well as some context 1702 handshake. 1704 The CS determine that ECDHE without specific PSK is used from the 1705 ClientHello and associated extensions. As a result, the default PSK 1706 value is used. The ECDHE share secret is derived, in our case from 1707 the dhe_secret of the TLS server and the public dhe value provided by 1708 the ClientHello shared_key extension. 1710 The CS reads the freshness extension and generates the 1711 handshake_context that will be used further. 1713 The necessary Handshake Context to generate the handshake secrets is 1714 ClientHello...ServerHello which is provided by the handshake_context. 1715 The CS uses the freshness function provided in the freshness 1716 extension to derive the appropriated server.random. 1718 The generation of the CertificateVerify is described in [RFC8446] 1719 section 4.4.3. and consists in a signature over a context that 1720 includes the output of Transcript-Hash(Handshake Context, 1721 Certificate) as well as a context string. Both Handshake Context and 1722 context string depends on the Mode which is set to server in this 1723 case via the configuration of the LURK server. 1725 The necessary Handshake Context to generate the CertificateVerify is 1726 ClientHello ... later of EncryptedExtensions / CertificateRequest. 1727 In our case, this is exactly handshake_context, that is ClientHello 1728 ... EncryptedExtensions. The Certificate payload is generated from 1729 the information provided in the certificate extension. 1731 Once the certificate_verify value has been defined, the LURK server 1732 generates the server Finished message in order to have the necessary 1733 Handshake Context ClientHello...server Finished to generate the 1734 application secrets. 1736 The LURK server returns the requested keys, the certificate_verify in 1737 a InitCertVerifyResponse structure. This structure is composed of 1738 the two substructures: SecretResponse that contains the secrets and 1739 SigningResponse that contains the certificate_verify. 1741 The TLS server can complete the ServerHello response, that is proceed 1742 to the encryption and generates the Finished message. 1744 As session resumption is not provided, the LURK server goes into a 1745 finished state and delete the ks_ctx. The special case described in 1746 this session does not use LURK session and as such may be stateless. 1748 10.4.3. TLS client: client Finished 1750 Upon receiving the ServerHello message, the TLS client retrieve the 1751 handshake and application secrets to decrypt the messages received 1752 from server as well as to encrypt its own messages and application 1753 data as represented below: 1755 TLS Client TLS Server 1757 {Finished} --------> 1758 [Application Data] <-------> [Application Data] 1760 To retrieves these secrets, the TLS client proceeds successively to 1761 an c_init_hand_secret LURK exchange followed by a c_app_secret LURK 1762 exchange. 1764 The c_init_hand_secret exchange is composed of one substructure: 1765 (secret_request) to request the secrets. Optionally, a 1766 SigningRequest (signing_request) when the TLS server requests the TLS 1767 client to authenticate itself. The indication of a request for TLS 1768 client authentication is performed by the TLS server by providing a 1769 CertificateRequest message associated to the ServerHello. We 1770 consider that such request has not been provided here so the 1771 SigingRequest structure is not present. 1773 The secret_request specifies the secrets requested via the 1774 key_request. In our case only the handshake secrets are requested 1775 (h_c, h_s). In this example the ECDHE share secret is provided via 1776 the ephemeral extension. In this case the ECDHE secrets have been 1777 generated by the TLS client, and the TLS client chooses to provide 1778 the ephemeral secret (dhe_secret) to the CS via the ephemeral 1779 extension. The TLS client also provides the freshness function via 1780 the freshness extension so the handshake_context can be appropriately 1781 be interpreted. The handshake context is provided via the 1782 handshake_context and is set to ClientHello ... ServerHello. 1784 Note that if the TLS client would have like the CS to generate the 1785 ECDHE public and private keys, the generation of the keys would have 1786 been made before the ClientHello is sent, that is in our case during 1787 a c_init_early_secret LURK exchange. If that had been the case a 1788 c_hand_secret LURK exchange would have followed and not a 1789 c_init_hand_secret exchange. 1791 TLS Client 1792 Lurk Client Cryptographic Service 1793 InitHandshakeSecretRequest 1794 secret_request 1795 key_request = h_c, h_s 1796 handshake_context = ClientHello ... ServerHello 1797 ext 1798 ephemeral = dhe_secret 1799 freshness 1800 session_id 1801 -------> 1803 InitHandshakeSecretResponse 1804 secret_response 1805 ext 1806 session_id 1807 <-------- keys 1808 TLS Client 1809 Lurk Client Cryptographic Service 1810 AppSecretRequest 1811 session_id 1812 cookie 1813 secret_Request 1814 key_request 1815 handshake_context 1816 -------> 1818 AppSecretResponse 1819 session_id 1820 cookie 1821 secret_response 1822 <-------- keys 1824 Upon receiving the InitHandshakeSecretRequest, the servers initiates 1825 a LURK session context (ks_ctx) and initiates a key schedule. The 1826 key schedule requires PSK, ECDHE as well as Handshake Context to be 1827 complete. As no pre_shared_key and psk_key exchange_modes are found 1828 in the ClientHello the CS determines that ECDHE is used for the 1829 authentication. The PSK is set to its default value. The ECHDE 1830 shared secret is generated from the ephemeral extension as well as 1831 the public value provided in the ClientHello. The CS takes the 1832 freshness function and generates the appropriated handshake context. 1833 The necessary Handshake Context to generate handshake secrets is 1834 ClientHello...ServerHello which is provided by the handshake_context. 1836 The handshake secrets are returned in the secret_response to the TLS 1837 client. The TLS client decrypt the encrypted extensions and messages 1838 of the ServerHello exchange. 1840 As no CertificateREquest appears, the LURK client initiates an 1841 app_secret LURK exchange decrypt and encrypt application data while 1842 finishing the TLS handshake. 1844 The AppSecretRequest structure uses session_id and cookies as agreed 1845 in the previous c_init_hand_secret exchange. The AppSecretRequest 1846 embeds a SecretRequest sub structure. The application secrets 1847 requested are indicated by the key_request (a_s, a_s). The Handshake 1848 Context (handshake_context) is set to server EncryptedExtensions ... 1849 server Finished. 1851 Upon receiving the AppSecretRequest, the CS checks the session_id. 1852 The CS has now the ClientHello ... server Finished which enables it 1853 to compute the application secrets. 1855 As no session resumption is provided, the CS and the LURK client goes 1856 into a finished state and delete their ks_ctx. 1858 10.5. TLS 1.3 Handshake with session resumption 1860 This scenario considers that the TLS server is authenticated using 1861 ECDHE only in the first time and that further TLS handshake use the 1862 session resumption mechanism. The first TLS Handshake is very 1863 similar as the previous one. The only difference is that 1864 psk_key_exchange_mode extension is added to the ClientHello. 1865 However, as no PSK identity is provided, the Full exchange is 1866 performed as described in section Section 10.4. 1868 The only change is that session resumption is activated, and thus 1869 LURK client and LURK servers do not go in a finished state and close 1870 the LURK session after the exchanges are completed. Instead further 1871 exchanges are expected. Typically, on the TLS server side 1872 new_Session_ticket exchanges are expected while 1873 registered_session_ticket are expected on the client side. 1875 When session resumption is performed, a new LURK session is 1876 initiated. 1878 10.5.1. Full Handshake 1880 The Full TLS Handshake use ECDHE authentication. It is very similar 1881 to the logic described in section Section 10.4. The TLS handshake is 1882 specified below for convenience. 1884 TLS Client TLS Server 1886 Key ^ ClientHello 1887 Exch | + key_share 1888 | + psk_key_exchange_mode 1889 v + signature_algorithms ---------> 1890 ServerHello ^ Key 1891 + key_share | Exch 1892 {EncryptedExtensions} Server Param 1893 {Certificate} ^ 1894 {CertificateVerify} | Auth 1895 {Finished} v 1896 <-------- [Application Data*] 1897 {Finished} --------> 1898 [Application Data] <-------> [Application Data] 1900 10.5.2. TLS server: NewSessionTicket 1902 As session resumption has been activated by the 1903 psk_key_exchange_mode, the TLS Server is expected to provide the TLS 1904 client NewSessionTickets as mentioned below: 1906 TLS Client TLS Server 1907 <-------- [NewSessionTicket] 1909 The LURK client and LURK server on the TLS server does not go into a 1910 finished state. Instead, the LURK client continues the LURK session 1911 with a NewTicketRequest to enable the CS to generate the 1912 resumption_master_secret necessary to generate the PSK and generate a 1913 NewTicketSession. ticket_nbr indicates the number of 1914 NewSessionTickets and handshake_context is set to earlier of client 1915 Certificate client CertificateVerify ... client Finished. As we do 1916 not consider TLS client authentication, the handshake_context is set 1917 to client Finished as represented below. 1919 TLS Server 1920 Lurk Client Cryptographic Service 1921 NewTicketRequest 1922 session_id 1923 cookie 1924 ticket_nbr 1925 handshake_context=client Finished --------> 1926 NewTicketResponse 1927 session_id 1928 cookie 1929 <--------- tickets 1931 The necessary Handshake Context to generate the 1932 resumption_master_secret is ClientHello...client Finished. From the 1933 InitCerificateVerify the context_handshake was set to 1934 ClientHello...server Finished. The additional handshake_context 1935 enables the CS to generate the NewSessionTickets. 1937 Note that the LURK client on the TLS server may send multiple 1938 NewTicketRequest. Future request have an empty handshake_context. 1940 Upon receiving the NewTicketRequest, the LURK server checks the 1941 session_id and cookie. It then generates the 1942 resumption_master_secret, NewSessionTickets. NewSessionTickets are 1943 stored into the PSK_DB under NewSessionTicket.ticket. Note that PSK 1944 is associated with the authentication mode as well as the Hash 1945 function negotiated for the cipher suite. The CS responds with 1946 NewSessionTickets that are then transmitted back to the TLS client. 1947 The TLS server is ready for session resumption. 1949 10.5.3. TLS client: NewSessionTicket 1951 Similarly, the LURK client on the TLS client will have to provide 1952 sufficient information to the CS the necessary PSK can be generated 1953 in case of session resumption. This includes the remaining Handshake 1954 Context to generate the resumption_master_secret as well as 1955 NewSessionTickets provided by the TLS server. The LURK client uses 1956 the c_register_ticket exchange. 1958 Note that the LURK client may provide the handshake_context with an 1959 empty list of NewSessionTickets, and later provide the 1960 NewSessionTickets as they are provided by the TLS server. The 1961 Handshake Context only needs to be provided for the first 1962 RegisterTicketRequest. 1964 TLS Client 1965 Lurk Client Cryptographic Service 1966 NewTicketRequest 1967 session_id 1968 cookie 1969 handshake_context=client Finished 1970 ticket_list --------> 1971 NewTicketResponse 1972 session_id 1973 cookie 1974 <--------- tickets 1976 Both TLS client and TLS Servers are ready for further session 1977 resumption. On both side the CS stores the PSK in a database 1978 designated as PSK_DB. Each PSK is associated to a Hash function as 1979 well as authentication modes. Each PSK is designated by an identity. 1980 The identity may be a label, but in our case the identity is derived 1981 from the NewSessionTicket.ticket. 1983 10.5.4. Session Resumption 1985 Session resumption is initiated by the TLS client. Session 1986 resumption is based on PSK authentication and different PSK may be 1987 proposed by the TLS client. The TLS handshake is presented below. 1989 TLS Client TLS Server 1990 ClientHello 1991 + key_share 1992 + psk_key_exchange_mode 1993 + pre_shared_key --------> 1994 ServerHello 1995 + pre_shared_key 1996 + key_share 1997 {EncryptedExtensions} 1998 {Finished} 1999 <-------- [Application Data*] 2001 The TLS client may propose to the TLS Server multiple PSKs. Each of 2002 these PSKs is associated a PskBindersEntry defined in [RFC8446] 2003 section 4.2.11.2. PskBindersEntry is computed similarly to the 2004 Finished message using the binder_key and the partial ClientHello. 2006 The TLS server is expected to pick a single PSK and validate the 2007 binder. In case the binder does not validate the TLS Handshake is 2008 aborted. As a result, only one binder_key is expected to be 2009 requested by the TLS server as opposed to the TLS client. 2011 In this example we assume the psk_key_exchange_mode indicated by the 2012 TLS client supports PSK-ECDHE as well as PSK authentication. The 2013 presence of a pre_shared_key and a key_share extension in the 2014 ServerHello inidcates that PSK-ECDHE has been selected. 2016 10.5.4.1. TLS client: ClientHello 2018 To compute binders, the TLS Client needs to request the binder_key 2019 associated to each proposed PSK. These binder_keys are retrieved to 2020 the CS using the BinderKeyRequest. The key_request is set to 2021 binder_key, and the PSK_id extension indicates the PSK's identity 2022 (PSKIdentity.identity or NewSessionTicket.ticket). No Handsahke 2023 Context is needed and handshake_context is empty. 2025 TLS Client 2026 Lurk Client Cryptographic Service 2027 BinderKeyRequest 2028 key_request=binder_key 2029 handshake_context="" 2030 ext 2031 PSK_id 2032 BinderKeyResponse 2033 <--------- key 2035 Upon receiving the BinderKeyRequest, the CS checks the psk is in the 2036 PSK_DB and returns the binder_key. 2038 With the binder keys, the TLS Client is able to send it ClientHello 2039 message. 2041 We assume in this example that the ECDHE secrets is generated by the 2042 TLS client and not the Cryptographic service. As a result, the TLS 2043 client does not need an extra exchange to request the necessary 2044 parameters to derive the key_shared extension. 2046 10.5.4.2. TLS server: ServerHello 2048 The TLS server is expected to select a PSK, check the associated 2049 binder and proceed further. If the binder fails, it is not expected 2050 to proceed to another PSK, as a result, the TLS server is expected to 2051 initiates a single LURK session. 2053 The binder_key is requested by the TLS server via and 2054 s_init_early_secret LURK exchange. The InitEarlySecretRequest 2055 structure is composed of a SecretRequest structure (secret_request). 2057 In our case, only the binder_key is requested so key_request is set 2058 to binder_key only. Similarly, to the TLS client, the 2059 handshake_context is not needed to generate the binder_key. However, 2060 the EarlySecret exchange requires the ClientHello to be provided so 2061 early secrets may be computed in the same round during 0-RTT 2062 handshake. The chosen PSK is indicated in the PSK_id extension and 2063 the freshness function is indicated in the freshness extension. 2065 TLS Server 2066 Lurk Client Cryptographic Service 2067 InitEarlySecretRequest 2068 secret_Request 2069 key_request=binder_key 2070 handshake_context=ClientHello 2071 ext 2072 freshenss 2073 PSK_id 2074 session_id 2075 InitEarlySecretResponse 2076 secret_response 2077 <--------- key 2078 ext 2079 session_id 2081 To complete to the ServerHello exchange, the TLS server needs the 2082 handshake and application secrets. These secrets are requested via 2083 an s_hand_and_app_secret LURK exchange. The 2084 HandshakeAndAppSecretRequest is composed of SecretRequest structure. 2085 The key_request is set to handshake (h_c, h_s) and application 2086 secrets (a_s, a_c). The Handshake Context (handshake_context) is set 2087 to ServerHello ... EncryptedExtensions as their is no authentication 2088 of the TLS client. Finally, the ephemeral ECDHE is provided or 2089 requested via the ephemeral extension. In our case, we assume the 2090 ephemeral secrets is generated by the tLS client is provided to the 2091 CS. 2093 The necessary Handshake Context to generate the handshake secrets is 2094 ClientHello ... ServerHello, so the CS can generate the handshake 2095 secrets. The necessary Handshake Context to generate the application 2096 secrets is ClientHello ... server Finished. So the CS needs to 2097 generate the Finished message before as in the case of the 2098 InitCerificateVerify exchange detailed in Section 10.5.1. 2100 TLS Server 2101 Lurk Client Cryptographic Service 2102 HandshakeAndAppRequest 2103 session_id 2104 secret_request 2105 key_request = h_c, h_s, a_c, a_s 2106 handshake_context = ServerHello ... EncryptedExtensions 2107 ext 2108 ephemeral = dhe_secret --------> 2109 HandshakeAndAppResponse 2110 session_id 2111 secret_response 2112 keys 2113 <--------- 2115 The CS returns the necessary secret to the TLS server to complete the 2116 ServerHello response. 2118 The remaining of the TLS handshake is proceeded similarly as 2119 described in the Full Handshake in section Section 10.5. 2121 10.6. TLS 1.3 0-RTT handshake 2123 The 0-RTT Handshake is a PSK or PSK-ECDHE authentication that enables 2124 the TLS client to provide application data during the first round 2125 trip. The main differences to the PSK PSK-ECDHE authentication 2126 described in the case of session resumption is that: 2128 o Application Data is encrypted in the ClientHello based on the 2129 client_early_secret 2131 o Generation of the client_early_secret requires the Cryptographic 2132 Service to be provisioned with the ClientHello which does not need 2133 to be re-provisioned later to generate the handshake secrets 2135 o An additional message EndOfEarlyData needs to be considered to 2136 compute the client Finished message. 2138 TLS Client TLS Server 2140 ClientHello 2141 + early_data 2142 + key_share* 2143 + psk_key_exchange_modes 2144 + pre_shared_key 2145 (Application Data*) --------> 2146 ServerHello 2147 + pre_shared_key 2148 + key_share* 2149 {EncryptedExtensions} 2150 + early_data 2151 {Finished} 2152 <-------- [Application Data*] 2153 (EndOfEarlyData) 2154 {Finished} --------> 2155 [Application Data] <-------> [Application Data] 2157 10.6.1. TLS client: ClientHello 2159 With 0-RTT handshake, the TLS client builds binders as in session 2160 resumption described in section Section 10.5.4. The binder_key is 2161 retrieved for each proposed PSK with a BinderKeyRequest. When early 2162 application data is sent it is encrypted using the 2163 client_early_traffic_secret. This secret is retrieved using the 2164 c_init_early_secret LURK exchange. 2166 The InitEarlySecretRequest is composed of a SecretRequest 2167 (secret_request) substructure. The TLS Client sets the key_request 2168 to client_early_traffic_secret (e_s). The handshake is set to 2169 ClientHello. The PSK is indicated via the the PSK_id extension, the 2170 freshness function is indicated via the freshness extension. If the 2171 TLS client is willing to have the ECDHE keys generated by the CS an 2172 ephemeral extension MAY be added also. 2174 When multiple PSK are proposed by the TLS client, the first proposed 2175 PSK is used to encrypt the application data. 2177 TLS Client 2178 Lurk Client Cryptographic Service 2179 InitEarlySecretRequest 2180 secret_request 2181 key_request=e_s 2182 handshake_context=ClientHello 2183 ex 2184 PSK_id 2185 fresness 2186 session_id 2187 InitEarlySecretResponse 2188 secret_response 2189 <--------- keys=e_s 2190 ext 2191 session_id 2193 Upon receiving the InitEarlySecretRequest, the CS generates the 2194 client_early_traffic_secret. 2196 The TLS client is able to send its ClientHello with associated 2197 binders and application data. 2199 10.6.2. TLS server: ServerHello 2201 If the TLS server accepts the early data. It proceeds as described 2202 in session resumption described in section Section 10.5.4. In 2203 addition to the binder_key, the TLS server also request the 2204 client_early_traffic_secret to decrypt the early data as well as to 2205 proceed to the ServerHello exchange. 2207 10.6.3. TLS client: Finished 2209 The TLS client proceeds as described in handshake based on ECDHE, PSK 2210 or PSK-ECDHE authentications described in Section 10.4 and 2211 Section 10.5. The main difference is that upon requesting handshake 2212 and application secrets, using an HandAndAppRequest the TLS client 2213 will not provide the ClientHello as part as the handshake_context. 2214 The Client as already been provided during the EarlySercret exchange. 2216 10.7. TLS client authentication 2218 TLS client authentication can be performed during the Full TLS 2219 handshake or after the TLS handshake as a post handshake 2220 authentication. In both cases, the TLS client authentication is 2221 initiated by the TLS server sending a CertificateRequest. The 2222 authentication is performed via a CertificateVerify message generated 2223 by the TLS client but such verification does not involve the CS on 2224 the TLS server. 2226 10.8. TLS Client:Finished (CertificateRequest) 2228 The ServerHello MAY carry a CertificateRequest encrypted with the 2229 handshake sercets. 2231 Upon receiving the ServerHello response, the TLS client decrypts the 2232 ServerHello response. If a CertificateRequest message is found, the 2233 TLS Client requests the Cryptographic to compute the 2234 CertificateVerify in addition to the application secrets via a 2235 certificate_verify LURK exchange. The CertVerifyRequest is composed 2236 of a Secret Request structure and a SigningRequest structure. 2238 The key_request is set to the application secrets (a_c, a_s) and the 2239 handshake_context is set to server EncryptedExtensions ... later of 2240 server Finished/EndOfEarlyData. As the request follows a (BinderKey, 2241 EarlySecret, HandshakeSecret) or HandshakeSecret the Handshake 2242 Context on the CS now becomes: ClientHello ... later of server 2243 Finished/EndOfEarlyData which is the Handshake Context required to 2244 generate the CertificateVerify on the TLS client side and includes 2245 the Handshake Context required to generate the application secrets 2246 (ClientHello...server Finished). 2248 TLS Client 2249 Lurk Client Cryptographic Service 2250 CertVerifyRequest 2251 session_id 2252 secret_request 2253 key_request 2254 handshake_context = EncryptedExtensions ... 2255 later of server Finished/EndOfEarlyData 2256 signing_request 2257 CertVerifyResponse 2258 session_id 2259 secret_response 2260 keys 2261 signing_response 2262 <--------- certificate_verify 2264 Upon receiving the CertificateRequest, the CS checks the session_id 2265 and cookie. 2267 10.9. TLS Client Authentication (PostHandshake) 2269 When post-handshake is enabled by the TLS client, the TLS client may 2270 receive at any time after the handshake a CertificateRequest message. 2271 When post handshake is enabled by the TLS client, as soon as the 2272 client Finished message has been sent, the TLS client sends a 2273 RegisteredNewSessionTicketRequest with an empty NewSessionTicket to 2274 register the remaining Handshake Context to the CS. ctx_id is set to 2275 opaque, handshake_context is set to earlier of client Certificate 2276 client CertificateVerify ... client Finished. 2278 Upon receiving the RegisteredNewSessionTicketsRequest the 2279 Cryptographic is aware of the full Handshake Context. It updates 2280 ks_ctx.next_request to c_post_hand or c_register_ticket. 2282 TLS Client 2283 Lurk Client Cryptographic Service 2284 RegisteredNewSessionTicketRequest 2285 session_id 2286 handshake_context 2287 ticket_list (empty) 2288 <--------- RegisteredNewSessionTicketResponse 2289 session_id 2290 cookie 2292 When the TLS client receives a CertificateRequest message from the 2293 TLS server, the TLS client sends a PostHandshakeRequest to the 2294 Cryptographic Service to generate certificate_verify. The 2295 handshake_context is set to CertificateRequest. The index N of the 2296 client_application_traffic_N key is provided as well as the 2297 Cryptographic so it can generate the appropriated key. 2299 TLS Client 2300 Lurk Client Cryptographic Service 2301 PostHandshakeRequest 2302 session_id 2303 handshake_context=CertificateRequest 2304 app_n=N 2305 PostHandshakeResponse 2306 session_id 2307 <--------- certificate_verify 2309 Upon receiving the PostHandshakeRequest the CS checks session_id and 2310 cookie. The necessary Handshake Context to generate the 2311 certificate_verify is ClientHello ... client Finished + 2312 CertificateRequest. Once the PostHandshakeResponse. Next requests 2313 expected are c_post_hand or c_register_ticket. 2315 11. References 2317 11.1. Normative References 2319 [I-D.mglt-lurk-tls12] 2320 Migault, D. and I. Boureanu, "LURK Extension version 1 for 2321 (D)TLS 1.2 Authentication", draft-mglt-lurk-tls12-02 (work 2322 in progress), January 2020. 2324 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2325 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2326 . 2328 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2329 Data Model for Layer 2 Virtual Private Network (L2VPN) 2330 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2331 2018, . 2333 11.2. Informative References 2335 [I-D.mglt-lurk-lurk] 2336 Migault, D., "LURK Protocol version 1", draft-mglt-lurk- 2337 lurk-00 (work in progress), February 2018. 2339 [I-D.mglt-lurk-tls-use-cases] 2340 Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios, 2341 "LURK TLS/DTLS Use Cases", draft-mglt-lurk-tls-use- 2342 cases-02 (work in progress), June 2016. 2344 Author's Address 2346 Daniel Migault 2347 Ericsson 2348 8275 Trans Canada Route 2349 Saint Laurent, QC 4S 0B6 2350 Canada 2352 EMail: daniel.migault@ericsson.com