idnits 2.17.1 draft-mglt-lurk-tls13-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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: '... [RFC8446] section 7.1, these secret MAY requires similar protection...' RFC 2119 keyword, line 128: '...ssion resumption MAY also be delegated...' RFC 2119 keyword, line 212: '...ptographic Service MAY be optimized by...' RFC 2119 keyword, line 214: '... implementations MAY not implement the...' RFC 2119 keyword, line 217: '... of the Cryptographic Service MAY also...' (98 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 Cryptographic Service 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. While the ctx_request and ctx_responses MAY be ignored, their associated overhead is limited and for sake of simplicity, we did not consider creating a different LURK exchange. == 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 register_session_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 (July 22, 2019) is 1739 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) -- Looks like a reference, but probably isn't: '4' on line 681 == Missing Reference: 'NewSessionTicket' is mentioned on line 1930, but not defined == Outdated reference: A later version (-05) exists of draft-mglt-lurk-tls12-01 == Outdated reference: A later version (-01) exists of draft-mglt-lurk-lurk-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 July 22, 2019 5 Expires: January 23, 2020 7 LURK Extension version 1 for (D)TLS 1.3 Authentication 8 draft-mglt-lurk-tls13-01 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 January 23, 2020. 33 Copyright Notice 35 Copyright (c) 2019 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. LURK Header . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Generic structures . . . . . . . . . . . . . . . . . . . . . 5 53 3.1. key_request . . . . . . . . . . . . . . . . . . . . . . . 6 54 3.2. secrets . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.3. handshake_context . . . . . . . . . . . . . . . . . . . . 8 56 3.4. Secret Sub Exchange . . . . . . . . . . . . . . . . . . . 9 57 3.4.1. Ephemeral Extension . . . . . . . . . . . . . . . . . 10 58 3.4.2. PSK_id Extension . . . . . . . . . . . . . . . . . . 12 59 3.4.3. Freshness Extension . . . . . . . . . . . . . . . . . 13 60 3.5. Context Agreement Sub-Exchange . . . . . . . . . . . . . 14 61 3.6. Signing Sub-Exchange . . . . . . . . . . . . . . . . . . 16 62 4. LURK exchange on the TLS server . . . . . . . . . . . . . . . 18 63 4.1. early_secret . . . . . . . . . . . . . . . . . . . . . . 18 64 4.2. init_certificate_verify . . . . . . . . . . . . . . . . . 19 65 4.3. handshake_and_app_secret . . . . . . . . . . . . . . . . 21 66 4.4. new_session_tickets . . . . . . . . . . . . . . . . . . . 22 67 5. LURK exchange on the TLS client . . . . . . . . . . . . . . . 23 68 5.1. binder_key . . . . . . . . . . . . . . . . . . . . . . . 23 69 5.2. early_secret . . . . . . . . . . . . . . . . . . . . . . 23 70 5.3. handshake_secret . . . . . . . . . . . . . . . . . . . . 23 71 5.4. init_handshake_secret . . . . . . . . . . . . . . . . . . 23 72 5.5. app_secret . . . . . . . . . . . . . . . . . . . . . . . 24 73 5.6. certificate_verify . . . . . . . . . . . . . . . . . . . 25 74 5.7. register_session_tickets . . . . . . . . . . . . . . . . 25 75 5.8. post_handshake . . . . . . . . . . . . . . . . . . . . . 26 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 79 9. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 80 9.1. LURK state diagrams on TLS on TLS client . . . . . . . . 28 81 9.1.1. LURK client . . . . . . . . . . . . . . . . . . . . . 30 82 9.1.2. Cryptographic Service . . . . . . . . . . . . . . . . 32 83 9.2. LURK state diagrams on TLS on TLS server . . . . . . . . 33 84 9.2.1. LURK client . . . . . . . . . . . . . . . . . . . . . 33 85 9.2.2. Cryptographic Service . . . . . . . . . . . . . . . . 34 86 9.3. TLS handshakes with Cryptographic Service . . . . . . . . 35 87 9.4. TLS 1.3 ECDHE Full Handshake . . . . . . . . . . . . . . 37 88 9.4.1. TLS Client: ClientHello . . . . . . . . . . . . . . . 37 89 9.4.2. TLS Server: ServerHello . . . . . . . . . . . . . . . 38 90 9.4.3. TLS client: client Finished . . . . . . . . . . . . . 40 91 9.5. TLS 1.3 Handshake with session resumption . . . . . . . . 43 92 9.5.1. Full Handshake . . . . . . . . . . . . . . . . . . . 43 93 9.5.2. TLS server: NewSessionTicket . . . . . . . . . . . . 44 94 9.5.3. TLS client: NewSessionTicket . . . . . . . . . . . . 45 95 9.5.4. Session Resumption . . . . . . . . . . . . . . . . . 46 97 9.6. TLS 1.3 0-RTT handshake . . . . . . . . . . . . . . . . . 49 98 9.6.1. TLS client: ClientHello . . . . . . . . . . . . . . . 50 99 9.6.2. TLS server: ServerHello . . . . . . . . . . . . . . . 51 100 9.6.3. TLS client: Finished . . . . . . . . . . . . . . . . 51 101 9.7. TLS client authentication . . . . . . . . . . . . . . . . 51 102 9.8. TLS Client:Finished (CertificateRequest) . . . . . . . . 52 103 9.9. TLS Client Authentication (PostHandshake) . . . . . . . . 53 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 54 106 10.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 can be performed by the 120 TLS Client as well as by the TLS Server. 122 LURK defines an interface to a Cryptographic Service that stores the 123 security credentials which include the PSK involved in a PSK or PSK- 124 ECDHE authentication or the key used for signing in an ECDHE 125 authentication. As in the case of session resumption the PSK is 126 derived from the resumption_master_secret during the key schedule 127 [RFC8446] section 7.1, these secret MAY requires similar protection 128 as well. On the other session resumption MAY also be delegated as in 129 the 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 Cryptographic Service on the TLS server as 133 well as on the TLS client and the Cryptographic Service can operate 134 in non delegating scenarios. 136 2. LURK Header 138 LURK / TLS 1.3 is a LURK Extension that introduces a new designation 139 "tls13". This document assumes that Extension is defined with 140 designation set to "tls13" and version set to 1. The LURK Extension 141 extends the LURKHeader structure defined in [I-D.mglt-lurk-lurk] as 142 follows: 144 enum { 145 tls13 (2), (255) 146 } Designation; 148 enum { 149 capabilities(0), ping(1), binder_key(2), 150 early_secrets(3), handshake_and_app_secrets(4), 151 init_handshake_secret(5), handshake_secrets(6), 152 app_secrets(7), init_certificate_verify(8), 153 certificate_verify(9), post_handshake(10), 154 new_session_ticket(11), register_session_ticket(12) (255) 155 }TLS13Type; 157 enum { 158 // generic values reserved or aligned with the 159 // LURK Protocol 160 request (0), success (1), undefined_error (2), 161 invalid_payload_format (3), 163 invalid_psk 164 invalid_freshness_funct 165 invalid_h_opaque 166 invalid_ctx_type 168 invalid_request 169 invalid_key_id_type 170 invalid_key_id 171 invalid_signature_scheme 172 invalid_certificate_type 173 invalid_certificate 174 invalid_certificate_verify 175 invalid_key_request 176 invalid_handshake 177 invalid_extension 178 invalid_ephemeral 179 invalid_cookie_h 181 }TLS13Status 183 struct { 184 Designation designation = "tls13"; 185 int8 version = 1; 186 } Extension; 188 struct { 189 Extension extension; 190 select( Extension ){ 191 case ("tls13", 1): 193 TLS13Type; 194 } type; 195 select( Extension ){ 196 case ("tls13", 1): 197 TLS13Status; 198 } status; 199 uint64 id; 200 unint32 length; 201 } LURKHeader; 203 3. Generic structures 205 The Cryptographic Service is not expected to perform any policies 206 such as choosing the appropriated authentication method. Such 207 choices are performed by the TLS client or TLS server that instruct 208 the LURK client accordingly. These policies performed by TLS client 209 or TLS server are not different from those performed on a standard 210 TLS exchange. 212 On the other hand, some Cryptographic Service MAY be optimized by 213 implementing a subset of the specified possibilities described in 214 this document. Typically some implementations MAY not implement the 215 session resumption or the post handshake authentication to avoid 216 keeping states of a given session once the handshake has been 217 performed. These capabilities of the Cryptographic Service MAY also 218 in return impact the policies of the TLS client or TLS server. 220 These limitations are mentioned throughout the document, and even 221 represented in the state diagrams, the recommendation is that the 222 Cryptographic Service SHOULD NOT impact the policies of the TLS 223 client or TLS server. Instead they SHOULD be able to optimize the 224 Cryptographic Service to their policies via some configuration 225 parameters presented in section Section 9.1. Such parameters are 226 implementation dependent and only provided here as informative 227 information. 229 This document defines the term role to specify whether the 230 Cryptographic runs on a TLS client or a TLS service. 232 LURK exchanges falls into three categories: 1) request of keys or 233 secrets, 2) request of signing operations, and 3) requests for ticket 234 (NewSessionTicket) management purposes. In some cases, these 235 operations are combined into a single LURK exchange. Table Figure 1 236 below summarizes the operations associated for each exchange. 238 +--------+--------------------------+------------------------+ 239 | Role | LURK exchange | secret | sign | ticket | 240 +--------+--------------------------+------------------------+ 241 | server | early_secret | yes | - | - | 242 | server | init_certificate_verify | yes | yes | - | 243 | server | handshake_and_app_secret | yes | - | - | 244 | server | new_session_ticket | yes | - | yes | 245 | client | binder_key | yes | - | - | 246 | client | early_secret | yes | - | - | 247 | client | init_handshake_secret | yes | - | - | 248 | client | handshake_secret | yes | - | - | 249 | client | app_secret | yes | - | - | 250 | client | certificate_verify | yes | yes | - | 251 | client | register_session_ticket | yes | - | yes | 252 | client | post_handshake | - | yes | - | 253 +--------+--------------------------+------------------------+ 255 Figure 1: Operation associated to LURK exchange 257 This section describes structures that are widely re-used across the 258 multiple LURK exchanges. 260 3.1. key_request 262 key_request is a 16 bit structure described in Table Figure 2 that 263 indicates the requested key or secrets by the LURK client. The same 264 structure is used across all LURK exchanges, but each LURK exchange 265 only permit a subset of values described in Table Figure 3. 267 A LURK client MUST NOT set key_request to key or secrets that are not 268 permitted. The Cryptographic Service MUST check the key_request has 269 only permitted values and has all mandatory key or secrets set. If 270 these two criteria are not met the Cryptographic Service MUST NOT 271 perform the LURK exchange and SHOULD return a invalid_key_request 272 error. If the Cryptographic Service is not able to to compute an 273 optional key or secret, the Cryptographic Service MUST proceed the 274 LURK exchange and ignore the optional key or secret. 276 +------+-------------------------------------------+ 277 | Bit | key or secret (designation) | 278 +------+-------------------------------------------+ 279 | 0 | binder_key (b) | 280 | 1 | client_early_traffic_secret (e_s) | 281 | 2 | early_exporter_master_secret (e_x) | 282 | 3 | client_handshake_traffic_secret (h_c) | 283 | 4 | server_handshake_traffic_secret (h_s) | 284 | 5 | client_application_traffic_secret_0 (a_c) | 285 | 6 | server_application_traffic_secret_0 (a_s) | 286 | 7 | exporter_master_secret (x) | 287 | 8 | resumption_master_secret (r) | 288 | 9-15 | reserved and set to zero | 289 +------+-------------------------------------------+ 291 Figure 2: key_request structure 293 +--------+--------------------------+--------------------------+ 294 | Role | LURK exchange | Permitted key/secrets | 295 +--------+--------------------------+--------------------------+ 296 | server | early_secret | b,e_c*, e_x* | 297 | server | init_certificate_verify | h_c, h_s, a_c*, a_s*, x* | 298 | server | handshake_and_app_secret | h_c, h_s, a_c*, a_s*, x* | 299 | server | new_session_ticket | r* | 300 | client | binder_key | b | 301 | client | early_secret | e_c*, e_x* | 302 | client | init_handshake_secret | h_c, h_s | 303 | client | handshake_secret | h_c, h_s | 304 | client | app_secret | a_c*, a_s*, x* | 305 | client | certificate_verify | a_c*, a_s*, x* | 306 | client | register_session_ticket | r* | 307 | client | post_handshake | | 308 +--------+--------------------------+--------------------------+ 310 (*) indicates an optional value, other values are mandatory 312 Figure 3: key_request permitted values per LURK exchange 314 3.2. secrets 316 The Secret structure carries a secret designated by its type and 317 value. 319 enum { 320 binder_key (0), 321 client_early_traffic_secret(1), 322 early_exporter_master_secret(2), 323 client_handshake_traffic_secret(3), 324 server_handshake_traffic_secret(4), 325 client_application_traffic_secret_0(5), 326 server_application_traffic_secret_0(6), 327 exporter_master_secret(7), 328 esumption_master_secret(8), 329 (255) 330 } SecretType; 332 struct { 333 SecretType secret_type; 334 opaque secret_data<0..2^8-1>; 335 } Secret; 337 secret_type: The type of the secret or key 339 secret_data: The value of the secret. 341 3.3. handshake_context 343 Secrets derivation takes Handshake Context as input. It is the 344 responsibility of the Cryptographic Service to maintain this variable 345 in an internal variable. On the other hand it is the responsibility 346 of the LURK client to provide the necessary element so the 347 Cryptographic Service got the necessary Handshake Context. The 348 Handshake Context evolves during the key derivation schedule, the 349 LURK client implements a incremental approach where only the missing 350 part of the Handshake Context are provided. The main intention is to 351 prevent the LURK client from providing multiple time the same 352 information as well as to perform extensive compatibility checks 353 between the duplicated information provided. 355 The handshake_context variable is based on the Handshake structure 356 defined in [RFC8446] section 4. The table below lists the values of 357 the handshake_context associated to each LURK exchange. 359 +--------+--------------------------+----------------------------------+ 360 | Role | LURK exchange | handshake_context | 361 +--------+--------------------------+----------------------------------+ 362 | server | early_secret | ClientHello | 363 | server | init_certificate_verify | ClientHello ... later of | 364 | | | server EncryptedExtensions / | 365 | | | CertificateRequest | 366 | server | handshake_and_app_secret | ServerHello ... later of | 367 | | | server EncryptedExtensions / | 368 | | | CertificateRequest | 369 | server | new_session_ticket | earlier of client Certificate | 370 | client | binder_key | | 371 | client | early_secret | ClientHello | 372 | client | init_handshake_secret | ClientHello ... ServerHello | 373 | client | handshake_secret | ServerHello | 374 | client | app_secret | server EncryptedExtensions ... | 375 | | | server Finished | 376 | client | certificate_verify | server EncryptedExtensions ... | 377 | | | later of server Finished/ | 378 | | | EndOfEarlyData | 379 | client | register_session_ticket | earlier of client Certificate | 380 | | | client CertificateVerify ... | 381 | | | client Finished | 382 | client | post_handshake | CertificateRequest | 383 +--------+--------------------------+----------------------------------+ 385 Figure 4: handshake values per LURK exchange 387 3.4. Secret Sub Exchange 389 Secrets are derived from the key schedule of [RFC8446] section 7. 391 The derivation of secrets requires an optional PSK that is provided 392 in the psk_id extension described in section Section 3.4.2 as well as 393 a ECDHE value which is provided by the ecdhe extension described in 394 section Section 3.4.1. 396 The extensions considered in this document are defined as below: 398 enum { psk_id(1), ephemeral(2), freshness(3) ... (255) } ExtensionType; 400 struct { 401 ExtensionType extension_type; 402 opaque extension_data<0..2^16-1>; 403 } Extension 405 struct { 406 uint16 key_request; 407 Handshake handshake_context<0..2^32> //RFC8446 section 4. 408 Extension extention_list<0...2^16> 409 } SecretsRequest; 411 struct { 412 Secret secret_list<0..2^16-1>; 413 Extension extention_list<0...2^16> 414 } SecretsResponse; 416 key_request: designates the requested secrets (see section 417 Section 3.1). 419 handshake_context: designates the necessary messages so the 420 Cryptographic Service is aware of the appropriated Handshake Context 421 to generate the secrets (see section Section 3.3). 423 extension_list: the list of extensions. 425 secret_list: the list of requested secrets (see section Section 3.2). 427 3.4.1. Ephemeral Extension 429 The Ephemeral structure carries the necessary information to generate 430 the ECDHE input used to derive the secrets. Multiple ways are 431 envisioned to generate the ECDHE value: 433 secret_provided: The LURK client MAY provide its secret value to the 434 Cryptographic Service. In the case, the ephemeral extension MUST be 435 provided. In this case the ECDHE value is derived using the public 436 value of the peer read from Handshake Context. The Cryptographic 437 MUST NOT return any data. 439 secret_generated: The LURK client MAY request the Cryptographic 440 Service to generate the secret value, in which case only the public 441 value would be returned to the LURK client, which in turn would 442 transmit it to the other peer. Note that in such cases the 443 Cryptographic Service would receive an incomplete Handshake Context 444 from the LURK client with the public part of the ECDHE missing. The 445 Cryptographic Service MUST check the public value is missing and 446 complete the Handshake Context accordingly before generating the 447 secrets. The Cryptographic Service MUST return an Ephemeral 448 extension with the associated public values, using a KeyShareEntry as 449 defined in section 4.2.8 of [RFC8446]. 451 Other methods may be defined in the future. 453 When the extension is not found, the default values specified by 454 [RFC8446] are used instead. 456 This extension MUST NOT be sent outside the LURK exchanges mentioned 457 below. When received outside these exchanges, the Cryptographic 458 Service SHOULD return an invalid_extension error. When the ephemeral 459 is not supported, an invalid_ephemeral error SHOULD be returned. 460 The ephemeral extension MUST NOT appear more than once in a LURK 461 session. When the extensions appears in more than one LURK exchange 462 an invalid_ephemeral error SHOULD be returned 464 +--------+--------------------------+----------+ 465 | Role | LURK exchange | Presence | 466 +--------+--------------------------+----------+ 467 | server | early_secret | - | 468 | server | init_certificate_verify | M | 469 | server | handshake_and_app_secret | * | 470 | server | new_session_ticket | - | 471 | client | binder_key | * | 472 | client | early_secret | - | 473 | client | init_handshake_secret | * | 474 | client | handshake_secret | * | 475 | client | app_secret | - | 476 | client | certificate_verify | - | 477 | client | register_session_ticket | - | 478 | client | post_handshake | - | 479 +--------+--------------------------+----------+ 480 M indicates the extension is mandatory 481 - indictaes the extension MUST NOT be provided 482 * indicates the extension MAY be provided 484 Figure 5: Ephemeral Extension presence per LURK exchange 486 The extension data is defined as follows: 488 enum { secret_provided(0), secret_generated(1) (255)}; 490 EphemeralData{ 491 uint8 method 492 opaque secret<0..2^16> 493 } 495 3.4.2. PSK_id Extension 497 The psk_id indicates the identity of the PSK used in the key 498 schedule. 500 The LURK client MUST provide this extension only when PSK or PSK- 501 authentication is envisioned and when the PSK has not been provided 502 earlier. These exchanges are early_secret on the TLS server. On the 503 TLS client side, these exchanges are binder_key, early_secret and 504 init_handshake_secret. The LURK client MUST NOT provide this 505 extension outside these exchanges. When receiving the PSK extension 506 outside these messages, the Cryptographic Service MUST NOT proceed to 507 the exchange and SHOULD return a invalid_format error. 509 +--------+--------------------------+----------+ 510 | Role | LURK exchange | Presence | 511 +--------+--------------------------+----------+ 512 | server | early_secret | M | 513 | server | init_certificate_verify | - | 514 | server | handshake_and_app_secret | - | 515 | server | new_session_ticket | - | 516 | client | binder_key | M | 517 | client | early_secret | M | 518 | client | init_handshake_secret | * | 519 | client | handshake_secret | - | 520 | client | app_secret | - | 521 | client | certificate_verify | - | 522 | client | register_session_ticket | - | 523 | client | post_handshake | - | 524 +--------+--------------------------+----------+ 525 M indicates the extension is mandatory 526 - indictaes the extension MUST NOT be provided 527 * indicates the extension MAY be provided 529 Figure 6: psk extension presence per LURK exchange 531 The extension data is defined as follows: 533 PskIdentity psk_id; //RFC8446 section 4.2.11 534 When the psk extension is provided in LURK exchange that is not 535 permitted an invalid_extension error SHOULD be returned. 537 Upon receiving this extension in the permitted LURK exchange the 538 Cryptographic Service checks the PSK is available. In case the PSK 539 is not available, an invalid_psk error is returned. If the PSK is 540 not provided, a default PSK is generated as described in [RFC8446] 541 section 7.1. If the default PSK is not allowed then an invalid_psk 542 is returned. 544 3.4.3. Freshness Extension 546 The freshness_function provides perfect forward secrecy (PFS) and is 547 used by the LURK client on the TLS client to generate the 548 ClientHello.random or by the LURK client on the TLS server to 549 generate the ServerHello.random. When these randoms are provided to 550 the Cryptographic Service, the freshness_function MUST be provided as 551 well. 553 Table Figure 7 lists the LURK exchange that MUST include the 554 freshness function extension as well as those where the extension may 555 be provided. 557 +--------+--------------------------+------------+ 558 | Role | LURK exchange | Presence | 559 +--------+--------------------------+------------+ 560 | server | early_secret | - | 561 | server | init_certificate_verify | M | 562 | server | handshake_and_app_secret | M | 563 | server | new_session_ticket | - | 564 | client | binder_key | - | 565 | client | early_secret | M | 566 | client | init_handshake_secret | M | 567 | client | handshake_secret | - | 568 | client | app_secret | - | 569 | client | certificate_verify | - | 570 | client | register_session_ticket | - | 571 | client | post_handshake | - | 572 +--------+--------------------------+------------+ 573 * indicates the extension MAY be provided 574 M indicates the extension is mandatory 575 - indictaes the extension MUST NOT be provided 577 Figure 7: freshness_funct extension presence per LURK exchange 579 The extension data is defined as follows: 581 PFSAlgorithm freshness_funct; // {{I-D.mglt-lurk-tls12}} section 4.1 582 If the Cryptographic Service does not support the freshness_funct, an 583 invalid_freshness_funct error is returned. 585 Perfect forward secrecy is implemented in a similar manner as with 586 the TLS 1.2 extension described in [I-D.mglt-lurk-tls12] section 587 4.1.1. As ServerHello.random in TLS 1.3 do not include time, it is 588 not considered here. In addition, we use a specific context related 589 to TLS 1.3. 591 As a result, the ServerHello.random is generated as follows on the 592 TLS server. 594 ServerHello.random = freshness_funct( server_random + "tls13 pfs srv" ); 596 The ClientHello.random is generated as follows on the TLS client 597 side: 599 ClientHello.random = freshness_funct( server_random + "tls13 pfs clt" ); 601 Perfect forward secrecy applies to the ServerHello.random on the TLS 602 server and on the ClientHello.random on the TLS client. As a result, 603 PFS is provided on the TLS server as long as the ServerHello is part 604 of the Handshake Context. Similarly PFS is provided on the TLS 605 client as long as ClientHello is part of the Handshake Context. On 606 the TLS server, early_secret exchange do not have the ServerHello so 607 this exchange is not protected by PFS later exchanges are. On the 608 TLS client side, binder_key does not have any Handshake Context so 609 this exchange is not protected by PFS. Later exchanges are. 611 3.5. Context Agreement Sub-Exchange 613 The LURK client and the Cryptographic Service perform an ordered 614 sequence of LURK exchange in order to complete a TLS handshake. This 615 suite of LURK exchange performed within a session identified by a 616 session_id on both side. Each side uses a specific session_id used 617 for inbound traffic. In addition, a cookie mechanism provides means 618 to ensure that the suite of LURK messages come from the same LURK 619 client. 621 The management of this session is managed via a key schedule context 622 (ks_ctx). This context contains the session_id used for inbound 623 traffic, the session_id used for the outbound traffic as well as the 624 necessary cryptographic material to generate the cookies (cookie_h). 626 ContextAgreementRequest and ContextAgreementResponse are present in 627 all LURK exchange initiating a session as represented in 628 Table Figure 8. 630 The structure is represented below: 632 struct { 633 PFSAlgorithm cookie_h; //{!I-D.mglt-lurk-tls12}} section 4.1 634 unint32 lurk_client_session_id; 635 unint32 lurk_client_cookie_init; 636 } ContexAgreementRequest; 638 struct { 639 uint32 crypto_service_session_id 640 uint32 crypto_service_cookie_init 641 } ContextAgreementResponse 643 cookie_h: The hash function used to generate the cookies throughout 644 the session. 646 lurk_client_session_id: the session_id used by the LURK client. 647 Packets from the Cryptographic Service to the LURK client are 648 expected to have this value as session_id. The session_id MUST be 649 generated randomly for each session. 651 lurk_client_cookie_init: A random value that characterizes the 652 exchange and that is not visible in the next LURK exchange of the 653 session. 655 crypto_service_session_id: the session_id used by the Cryptographic 656 Service. Packets from the LURK client to the Cryptographic Service 657 are expected to have this value as session_id. The session_id MUST 658 be generated randomly for each session. 660 crypto_service_cookie_init: A random value that characterizes the 661 exchange and that is not visible in the next LURK exchange of the 662 session. 664 If the Cryptographic Service does not support cookie_h an 665 invalid_cookie_h error is returned. Otherwise, the Cryptographic 666 Service initiates a context (ks_ctx). 668 The cookie mechanism is intended to prevent an attacker to perform an 669 exchange within a session established between the LURK client and the 670 Cryptographic Service. Cookies are generated as represented below by 671 the LURK client and the Cryptographic Service. The cookie MUST be 672 checked against its expected value. When the Cryptographic Service 673 does not receive the expected cookie, the request is discarded or an 674 invalid_request error is sent. 676 The cookie is represented below: 678 salt_0 = LURK exchange 679 salt_n+1 = HKDF-Expand-Label(salt_n, 680 label, "", cookie_h.length) 681 cookie_n+1 = cookie_h(salt_n+1)[4] 683 salt_0 is initialized by the LURK exchange initiating the session, 684 i.e the early_secret, the init_certificate_verify, binder_key or 685 handshake_secret. Next saltz are derived iteratively and the 686 corresponding cookie takes the 32 most significant bits of the 687 resulting hash of the salt_n with cookie_h. The first cookie sent is 688 sent for n=1. The label is set to "cs_cookie" for request sent to 689 the Cryptographic Service. The resulting cookie is designated as 690 crypto_service_cookie. The label is set to "clt_cookie" for 691 responses sent to the LURK client. The resulting cookie is 692 designated a lurk_client_cookie. 694 +--------+--------------------------+----------+ 695 | Role | LURK exchange | Presence | 696 +--------+--------------------------+----------+ 697 | server | early_secret | M | 698 | server | init_certificate_verify | M | 699 | server | handshake_and_app_secret | - | 700 | server | new_session_ticket | - | 701 | client | binder_key | - | 702 | client | early_secret | M | 703 | client | init_handshake_secret | M | 704 | client | handshake_secret | | 705 | client | app_secret | - | 706 | client | certificate_verify | - | 707 | client | register_session_ticket | - | 708 | client | post_handshake | - | 709 +--------+--------------------------+----------+ 710 * indicates the extension MAY be provided 711 M indicates the extension is mandatory 712 - indictaes the extension MUST NOT be provided 714 Figure 8: Presence of the Context Agreement structure in the various 715 LURK exchanges 717 3.6. Signing Sub-Exchange 719 The signature requires the signature scheme (sig_algo), the 720 designated private key (key_id), as well as sufficient context to 721 generate the necessary data to be signed. In our case the necessary 722 context is provided by the LURKCertificate, assuming the 723 Cryptographic Service will have the necessary Handshake Context. The 724 latest may be provided in a combination of a secret request. 726 key_id is processed as described in [I-D.mglt-lurk-tls12] section 727 4.1. If the Cryptographic Service does not support the KeyPairIdType 728 an invalid_key_id_type is returned. If the Cryptographic Service 729 does not recognize the key, an invalid_key_id error is returned. 731 sig_algo designates the signature algorithm scheme, and it is defined 732 in {{!RFC8446} section 4.2.3. When the Cryptographic Service does 733 not support the signature scheme an invalid_signature_scheme error is 734 returned. 736 The certificate is a public data that may repeat over multiple 737 distinct TLS handshakes. To limit the load of unnecessary 738 information being transmitted multiple times, the LURKCertificate 739 enables to carry the index of the Certificate structure rather than 740 the structure itself. When the lurk_certificate_type is set to 741 sha256_32, the index of the Certificate structure is sent. The 742 current specification generates the index using sha256_32 as defined 743 in [I-D.mglt-lurk-tls12], that is the first 32 bits of the hash of 744 the Certificate structure using SHA256 as the hashing function. When 745 lurk_certificate_type is set to tls13 the Certificate structure is 746 expected. When the Cryptographic Service does not support the 747 certificate_type, an invalid_certificate_type error is returned. 748 When the Certificate structure does not match the private key, an 749 invalid_certificate error is returned. 751 Signing operations are described in [RFC8446] section 4.4.3. The 752 context string is derived from the role and the type of the LURK 753 exchange as described below. The Handshake Context is taken from the 754 key schedule context. 756 +--------+-------------------------+-------------------------------------+ 757 | role | type | context | 758 +--------+-------------------------+-------------------------------------+ 759 | server | init_certificate_verify | "TLS 1.3, server CertificateVerify" | 760 | client | certificate_verify | "TLS 1.3, client CertificateVerify" | 761 +--------+-------------------------+-------------------------------------+ 763 The Cryptographic Service computes the signature as described in 764 [RFC8446] section 4.4.3. and returns signature in SigningResponse. 765 When the Cryptographic Service does not have the necessary Handshake 766 Context, context or is unable to proceeds to the signing operation, 767 an invalid_certificate_verify error is returned. 769 The structure is represented below: 771 enum { tls13(0), sha256_32(1) (255)}; LURKCertificateType 773 struct { 774 lurk_certificate_type; 775 select (lurk_certificate_type) { 776 case sha256_32: 777 uint32 hash_cert; 778 case tls13: 779 Certificate tls13_certificate; // RFC8446 section 4.4.2 780 }; 781 } LURKCertificate; 783 struct { 784 KeyPairId key_id; // draft-mglt-lurk-tls12 section 4.1 785 SignatureScheme sig_algo; //RFC8446 section 4.2.3. 786 LURKCertificate certificate; 787 } SigningRequest; 789 struct { 790 opaque signature<0..2^16-1>; //RFC8446 section 4.4.3. 791 } SigningResponse; 793 4. LURK exchange on the TLS server 795 This section describes the LURK exchanges that are performed on the 796 TLS server. The state diagram is provided in section Section 9.2 798 4.1. early_secret 800 A TLS server MAY receive a ClientHello that proposes PSK or PSK-ECDHE 801 authentication via the pre_shared_key and psk_key_exchange_modes 802 extensions. Depending on its policies, the TLS server MAY decide to 803 proceed to such authentication. It chooses a PSK identity so the 804 LURK client initiates a key schedule context (ks_ctx) that will 805 manage the session with the Cryptographic Service. This session is 806 initiated with a early_secret exchange. 808 The binder_key MUST be requested, since it is used to validate the 809 PSK. 811 The TLS client MAY indicate support for early application data via 812 the early_data extension. Depending on the TLS server policies, it 813 MAY accept early data and request the client_early_traffic_secret. 815 The TLS server MAY have specific policies and request 816 early_exporter_master_secret. 818 Upon receiving an early_secret request, the Cryptographic Service 819 proceeds the ContextAgreementRequest as described in Section 3.5 as 820 well as the SecretRequest as described in section Section 3.4. 822 The Cryptographic Service MUST check pre_shared_key and 823 psk_key_exchange_modes extensions are present in the ClientHello. If 824 these extensions are not present, a invalid_handshake error SHOULD be 825 returned. The Cryptographic Service MUST ignore the 826 client_early_traffic_secret if early_data extension is not found in 827 the ClientHello. The Cryptographic Service MAY ignore the request 828 for client_early_traffic_secret, in any case. The Cryptographic 829 Service MAY ignored the request for early_exporter_master_secret. 831 struct{ 832 ContextAgreementRequest ctx_request 833 SecretRequest secret_request 834 } EarlySecretRequest 836 struct{ 837 ContextAgreementResponse ctx_response 838 SecretResponse secret_response 839 } EarlySecretResponse 841 ctx_request: The structure associated to the context agreement 842 request defined in section Section 3.5 844 secret_request: The structure associated to the secret request 845 defined in section Section 3.4 847 ctx_response: The structure associated to the context agreement 848 response defined in section Section 3.5 850 secret_response: The structure associated to the secret request 851 defined in section Section 3.4. 853 4.2. init_certificate_verify 855 A TLS server MAY receive a ClientHello that proposes ECDHE 856 authentication with a key_share extension. Depending on its 857 policies, the TLS server MAY decide to proceed to such authentication 858 and indicate it to the LURK client so it initiates a key schedule 859 context (ks_ctx) that will manage the session with the Cryptographic 860 Service. This session is initiated with a init_certificate_verify 861 exchange. 863 The Cryptographic MUST ensure the ServerHello has selected the ECDHE 864 authentication that is a key_share extension is present and no 865 pre_shared_key extension is present. If these conditions are not 866 met, a invalid_handshake error SHOULD be returned. 868 In order to provide generate the client_application_traffic_secret_0 869 and server_application_traffic_secret_0, the Cryptographic Service 870 generates the server Finished. This value is computed to avoid 871 multiple round trips. This value is not returned to the LURK client 872 and needs to be computed again by the TLS server. 874 After the exchange is completed, the TLS server is able to build and 875 return the ServeHello and complete the TLS handshake. 877 If the Cryptographic Service has been configured not to handle 878 session resumption. The session is finished and ks_ctx SHOULD be 879 deleted and some implementations MAY NOT create the ks_ctx. While 880 the ctx_request and ctx_responses MAY be ignored, their associated 881 overhead is limited and for sake of simplicity, we did not consider 882 creating a different LURK exchange. 884 struct{ 885 SecretRequest secret_request 886 SigingRequest signing_request 887 }CertificateVerifyRequest 889 struct{ 890 ContextAgreementRequest ctx_request 891 CertificateVerifyRequest cert_request 892 }InitCertificateVerifyRequest 894 struct{ 895 SecretResponse secret_response 896 SigningResponse signing_response 897 }CertificateVerifyResponse 899 struct{ 900 ContextAgreementResponse ctx_response 901 CertificateVerifyRequest cert_response 902 }InitCertificateVerifyResponse 904 ctx_request, ctx_response, secret_request and secret_response are 905 defined in section Section 4.1. 907 4.3. handshake_and_app_secret 909 The handshake_and_app_secret is necessary to complete the ServerHello 910 and always follows an early_secret LURK exchange. Such sequence is 911 guaranteed by the session_id and cookie mechanism. In case of 912 unknown session_id or an unexpected cookie value, an invalid_request 913 error SHOULD be returned. 915 The LURK client MUST ensure that PSK or PSK-ECDHE authentication has 916 been selected via the presence of the pre_shared_key extension in the 917 the ServerHello. In addition, the selected identity MUST be the one 918 provided in the psk extension of the previous early_secret exchange. 920 The LURK client MAY request the exporter_master_secret depending on 921 its policies. The Cryptographic Service MAY ignore the request based 922 on its policies. 924 Similarly to the init_certificate_verify, if session resumption is 925 not provided by the Cryptographic Service, the LURK session ends 926 after this exchange and ks_ctx SHOULD be removed. 928 struct{ 929 uint32 crypto_service_session_id 930 uint32 crypto_service_cookie 931 SecretRequest secret_request 932 } HandshakeRequest 934 struct{ 935 uint32 lurk_client_session_id 936 uint32 lurk_client_cookie 937 SecretResponse secret_response 938 } HandshakeResponse 940 crypto_service_session_id: value provided in the 941 ContexAgreementResponse - see section Section 3.5. 943 crypto_service_cookie: cookie value generated as described in section 944 Section 3.5. 946 lurk_client_session_id: value provided in the ContexAgreementRequest 947 - see section Section 3.5. 949 lurk_client_cookie: cookie value generated as described in section 950 Section 3.5. 952 4.4. new_session_tickets 954 new_session ticket handles session resumption. It enables to 955 retrieve NewSessionTickets that will be forwarded to the TLS client 956 by the TLS server to be used later when session resumption is used. 957 It also provides the ability to delegate the session resumption 958 authentication from the Cryptographic Service to the TLS server. In 959 fact, if the LURK client requests and receives the 960 resumption_master_secret it is able to emit on its own 961 NewSessionTicket. As a result new_session_ticket LURK exchanges are 962 only initiated if the TLS server expects to perform session 963 resumption and the Cryptographic Service responds only if if 964 session_resumption is enabled. If session resumption is not enabled, 965 the Cryptographic MAY have ended the LURK session and the 966 new_session_ticket will be ignored or responded with a 967 invalid_request error. 969 The Cryptographic Service MAY responds with a 970 resumption_master_secret based on its policies. 972 The LURK client MAY perform multiple new_session_ticket exchanges 973 before the session between the LURK client and the Cryptographic 974 Service is in a finished state with ks_ctx deleted. 976 struct { 977 uint32 crypto_service_session_id 978 uint32 crypto_service_cookie 979 uint8 ticket_nbr; 980 unint16 key_request; 981 Handshake handshake_context<0..2^32> //RFC8446 section 4. 982 } NewSessionTicketRequest; 984 struct { 985 uint32 lurk_client_session_id 986 uint32 lurk_client_cookie 987 NewSessionTicket ticket_list<0..2^16-1>; //RFC8446 section 4.6.1. 988 } NewSessionTicketResponse; 990 crypto_service_session_id, crypto_service_cookie, 991 lurk_client_session_id, and lurk_client_cookie are defined in section 992 Section 4.3. key_request is defined in section Section 3.1. 994 ticket_nbr: designates the requested number of NewSessionTicket. In 995 the case of delegation this number MAY be set to zero. The 996 Cryptographic Service MAY responds with less tickets when the value 997 is too high. 999 5. LURK exchange on the TLS client 1001 This section describes the LURK exchanges that are performed on the 1002 TLS server. The state diagram is provided in section Section 9.1 1004 5.1. binder_key 1006 The binder_key LURK exchange is initiates a LURK session when the TLS 1007 client is willing to propose a PSK for PSK or PSK-ECDHE 1008 authentication. 1010 The handshake_context is empty as the ClientHello is under 1011 construction. 1013 When a LURK client proposes multiple PSK, multiple binder_keys are 1014 requested. 1016 The binder_key is equivalent to a secret LURK exchange and there is 1017 no creation of a ks_ctx. 1019 5.2. early_secret 1021 early_secret on the TLS client side works similarly as the 1022 early_secret LURK exchange on the TLS server as described in section 1023 Section 4.1. One key difference is that the binder_key is not 1024 requested during that LURK exchange, as a result, this LURK exchange 1025 MAY be omited even when PSK or PSK-ECDHE authentication has been 1026 chosen by the TLS client. The early_secret will only be performed in 1027 the case of 0-RTT handshake or when early exporters are required. 1029 5.3. handshake_secret 1031 The handshake_secret is performed after an early_secret LURK 1032 exchange. This exchange is performed in the case of an PSK or PSK- 1033 ECDHE authentication and coherence with the Handshake Context MUST be 1034 checked by the LURK client as well as by the Cryptographic Service as 1035 described in Section 4.1 and section Section 4.3. 1037 The structures of the handshake_secret follow those of the 1038 handshake_and_app_secret described in section Section 4.3. 1040 5.4. init_handshake_secret 1042 The handshake_secret LURK exchange MAY be initiating a session 1043 between the LURK client and the Cryptographic Service in which case 1044 it contains a ctx_agreement structures. 1046 Coherence between with the Handshake Context and the authentication 1047 ECDHE versus PSK or PSK-ECDHE) is performed as described in section 1048 Section 4.1 and section Section 4.3. The LURK client and the 1049 Cryptographic Service MUST ensure such coherence. A Signing sub 1050 exchange MUST only be performed when ECDHE authentication has been 1051 selected which is determined by the presence of a key_share extension 1052 as well as the absence of a pre_shared_key extension in the 1053 ServerHello. 1055 Only the client_handshake_traffic_secret_0 and 1056 server_handshake_traffic_secret_0 secrets MAY be requested. 1058 struct{ 1059 ContextAgreementRequest ctx_request 1060 SecretRequest secret_request 1061 select (handshake_context.ecdhe_selected){ 1062 case : 1063 SigningRequest signing_request 1064 }; 1065 }InitHandshakeRequest 1067 struct{ 1068 ContextAgreementResponse ctx_response 1069 SecretResponse secret_response 1070 select (handshake_context.ecdhe_selected){ 1071 case : 1072 SigningResponse signing_response 1073 }; 1074 }InitHandsahkeResponse 1076 5.5. app_secret 1078 The app_secret LURK exchange is performed when no TLS client 1079 authentication has been requested, i.e. CertificateRequest message is 1080 not provided in the flight of the ServerHello. The LURK client and 1081 the Cryptographic Service MUST ensure no CertificateRequest is 1082 present in the Handshake Context. 1084 Only the client_application_traffic_secret_0 and 1085 server_application_traffic_secret_0 secrets MAY be requested. 1087 The structure follows the one of the handshake_secret described in 1088 section Section 5.3. 1090 After the app_secret LURK exchange, unless the TLS client supports 1091 session resumption or post_handshake, the LURK session is finished. 1093 The support for post_handshake by the TLS client is indicated by the 1094 post_handshake_auth extension. 1096 5.6. certificate_verify 1098 The certificate_verify LURK exchange is performed when TLS client 1099 authentication has been requested by the TLS server. When performed, 1100 the LURK client and the Cryptographic Service MUST check the presence 1101 of a CertificateRequest structure in the Handshake Context. When not 1102 present, a invalid_handshake error SHOULD be returned. 1104 After the app_secret LURK exchange, unless the TLS client supports 1105 session resumption or post_handshake, the LURK session is finished. 1106 The support for post_handshake by the TLS client is indicated by the 1107 post_handshake_auth extension. 1109 The CertificateVerifyRequest and CertificateVerifyResponse structures 1110 are used for this LURK exchange. 1112 5.7. register_session_tickets 1114 The register_session_ticket is only used when the TLS client intend 1115 to perform session resumption. This LURK exchange has three 1116 functions. First, it is used to register the handshake in order to 1117 provide the full TLS handshake. Such information will be necessary 1118 to generate the PSK value during the future session resumptions. 1119 Second, the LURK client MAY provide one or multiple 1120 NewSessionTickets. These tickets will be helpful for the session 1121 resumption to bind the PSK value to some identities. Third, the LURK 1122 client MAY retrieve the resumption_master_secret when session 1123 resumption is being delegated by the Cryptographic Service to the TLS 1124 client. 1126 The first register_session_ticket MUST carry the TLS handshake and 1127 future register_session_ticket LURK exchange MUST have a 1128 handshake_context of zero length. If these conditions are not met, 1129 the Cryptographic Service SHOULD return a invalid_handshake error. 1131 The first register_session_ticket MAY request the 1132 session_resumption_master. Next register_new_session MUST not 1133 request that secret.If these conditions are not met, a 1134 invalid_key_request error is returned. 1136 The ticket_list MAY have zero NewSessionTickets for the first 1137 register_new_Session_ticket. Next LURK exchanges MUST have at least 1138 one NewSessionTickets. 1140 struct { 1141 uint32 crypto_service_session_id 1142 uint32 crypto_service_cookie 1143 Handshake handshake_context<0..2^32>; //RFC8446 section 4. 1144 NewSessionTicket ticket_list<0..2^16-1>; //RFC8446 section 4.6.1. 1145 uint16 key_request; 1146 } RegisterSessionTicketRequest; 1148 struct { 1149 uint32 lurk_client_session_id 1150 uint32 lurk_client_cookie 1151 } RegisterSessionTicketResponse; 1153 crypto_service_session_id, crypto_service_cookie, 1154 lurk_client_session_id, and lurk_client_cookie are defined in section 1155 Section 4.3. handshake_contex is defined in section Section 3.3. 1156 NewSessionTicket is defined in [RFC8466] section 4.6.1. key_request 1157 is defined in Section 3.1. 1159 5.8. post_handshake 1161 The post_handshake LURK exchange is performed in order to the client 1162 to authenticate after the TLS handshake has complete. The TLS client 1163 MUST NOT proceed to this exchange if post handshake support has not 1164 been announced in the ClientHello with the post_handshake_auth 1165 extension. When such extension is not found the Cryptographic 1166 Service MUST return a invalid_handshake error. 1168 struct { 1169 uint32 crypto_service_session_id 1170 uint32 crypto_service_cookie 1171 Handshake handshake_context<0..2^32>; //RFC8446 section 4. 1172 int16 app_n; 1173 } PostHandshakeRequest; 1175 struct { 1176 uint32 lurk_client_session_id 1177 uint32 lurk_client_cookie 1178 } PostHandshakeResponse; 1180 handshake_context is defined in section Section 3.3 1182 app_n: describes the number of iteration of the session keys. 1184 6. Security Considerations 1186 Security credentials as per say are the private key used to sign the 1187 CertificateVerify when ECDHE authentication is performed as well as 1188 the PSK when PSK or PSK-ECDHE authentication is used. 1190 The protection of these credentials means that someone gaining access 1191 to the Cryptographic Service MUST NOT be able to use that access from 1192 anything else than the authentication of an TLS being established. 1193 In other way, it MUST NOT leverage this for: * any operations outside 1194 the scope of TLS session establishment. * any operations on past 1195 established TLS sessions * any operations on future TLS sessions * 1196 any operations on establishing TLS sessions by another LURK client. 1198 The Cryptographic Service outputs are limited to secrets as well as 1199 NewSessionTickets. The design of TLS 1.3 make these output of 1200 limited use outside the scope of TLS 1.3. Signature are signing data 1201 specific to TLS 1.3 that makes the signature facility of limited 1202 interest outside the scope of TLS 1.3. NewSessionTicket are only 1203 useful in a context of TLS 1.3 authentication. 1205 ECDHE and PSK-ECDHE provides perfect forward secrecy which prevents 1206 past session to be decrypted as long as the secret keys that 1207 generated teh ECDHE share secret are deleted after every TLS 1208 handshake. PSK authentication does not provide perfect forward 1209 secrecy and authentication relies on the PSK remaining sercet. The 1210 Cryptographic Service does not reveal the PSK and instead limits its 1211 disclosure to secrets that are generated from the PSK and hard to be 1212 reversed. 1214 Future session may be impacted if an attacker is able to authenticate 1215 a future session based on what it learns from a current session. 1216 ECDHE authentication relies on cryptographic signature and an ongoing 1217 TLS handshake. The robustness of the signature depends on the 1218 signature scheme and the unpredictability of the TLS Handshake. PSK 1219 authentication relies on not revealing the PSK. The Cryptographic 1220 Service does not reveal the PSK. TLS 1.3 has been designed so 1221 secrets generated do not disclose the PSK as a result, secrets 1222 provided by the Cryptographic do not reveal the PSK. 1223 NewSessionTicket reveals the identity (ticket) of a PSK. 1224 NewSessionTickets.ticket are expected to be public data. It value is 1225 bound to the knowledge of the PSK. The Cryptographic does not output 1226 any material that could help generate a PSK - the PSK itself or the 1227 resumption_master_secret. In addition, the Cryptographic only 1228 generates NewSessionTickets for the LURK client that initiates the 1229 key schedule with Cryptographic Service with a specific way to 1230 generate ctx_id. This prevents the leak of NewSessionTickets to an 1231 attacker gaining access to a given Cryptographic Service. 1233 If an the attacker get the NewSessionTicket, as well as access to the 1234 Cryptographic Service of the TLS client it will be possible to 1235 proceed to the establishment of a TLS session based on the PSK. In 1236 this case, the Cryptographic Service cannot make the distinction 1237 between the legitimate TLS client and teh attacker. This corresponds 1238 to the case where the TLS client is corrupted. 1240 Note that when access to the Cryptographic Service on the TLS server 1241 side, a similar attack may be performed. However the limitation to a 1242 single re-use of the NewSessionTicket prevents the TLS server to 1243 proceed to the authentication. 1245 Attacks related to other TLS sessions are hard by design of TLS 1.3 1246 that ensure a close binding between the TLS Handshake and the 1247 generated secrets. In addition communications between the LURK 1248 client and the Cryptographic Service cannot be derived from an 1249 observed TLS handshake (freshness function). This makes attacks on 1250 other TLS sessions unlikely. 1252 7. IANA Considerations 1254 8. Acknowledgments 1256 9. Annex 1258 9.1. LURK state diagrams on TLS on TLS client 1260 The state diagram sums up the LURK exchanges. The notations used are 1261 defined below: 1263 LURK exchange indicates a LURK exchange is stated by the LURK client 1264 or is received by the Cryptographic Service ---> (resp. <---) 1265 indicates a TLS message is received (resp. received). These 1266 indication are informative to illustrates the TLS state machine. 1268 CAPITAL LETTER indicates potential configuration parameters or policy 1269 applied by the LURK client or the Cryptographic Service. The 1270 following have been considered: 1272 o PSK, PSK-ECDHE, ECDHE that designates the authentication method. 1273 This choice is made by the LURK client. The choice is expressed 1274 by a specific LURK exchange as well as from the TLS Handshake 1275 Context. 1277 o SESSION_RESUMPTION indicates the session resumption has been 1278 enabled on the LURK client or the Cryptographic Service. As a 1279 consequence the TLS client is considered performing session 1280 resumption and the TLS server MUST make session resumption 1281 possible. 1283 o POST_HANDSHAKE_AUTH indicates that post handshake authentication 1284 proposed by the TLS client in a post_handshake_auth extension is 1285 not ignored by the LURK client or on the Cryptographic Service. 1287 Note that SESSION_RESUMPTION, POST_HANDSAHKE_AUTH are mostly 1288 informative and the current specification does not mandate to have 1289 such configuration parameters. By default, these SHOULD be enabled. 1291 Other potential configuration could be proposed for configuring LURK 1292 client or Cryptographic Service policies. These have not been 1293 represented in the state diagram and the specification does not 1294 mandate to have these parameters implemented. 1296 o CLIENT_EARLY_TRAFFIC indicates that client early traffic MAY be 1297 sent by the TLS client and the notification by the TLS client in 1298 the ClientHello via the early_data extension MUST be considered. 1300 o EARLY_EXPORTER_MASTER_SECRET indicates whether or not 1301 early_exporter_master_secret MUST be requested by the LURK client 1302 and responded by the Cryptographic Service. 1304 o MASTER_EXPORTER indicates whether or not exporter_master_secret 1305 MUST be requested by the LURK client and responded by the 1306 Cryptographic Service. 1308 o SESSION_RESUMPTION_DELEGATION indicates whether or not 1309 session_resumption_master is requested by the LURK client and 1310 responded by the Cryptographic Service. 1312 o MAX_SESSION_TICKET_NBR indicates the maximum number of tickers 1313 that can be requested or provided by the LURK client and provided 1314 by the Cryptographic Service. It is strongly RECOMMENDED to have 1315 such limitations being configurable. 1317 The analysis of the TLS Handshake Context enables to set some 1318 variables that can be used by the LURK client to determine which LURK 1319 exchange to proceed as well as by the Cryptographic Service to 1320 determine which secret MAY be responded. The following variables 1321 used are: 1323 psk_proposed: The TLS Client is proposing PSK authentication by 1324 including a pre_shared_key and a psk_key_exchange_mode extensions in 1325 the ClientHello. 1327 dhe_proposed: The received or to be formed ClientHello contains a 1328 key_share extensions. 1330 psk_accepted: The chosen authentication method is pSK or PSK-ECDHE 1331 which is indicated via the pre_shared_key extension in the 1332 ServerHello. 1334 0rtt_proposed: Indicates the TLS client supports early data which is 1335 indicated by the early_data extension in the ClientHello. 1337 post_handshake_proposed: indicates the TLS client supports post 1338 handshake authentication which is indicated by the presence of a 1339 post_handshake_auth extension in the ClientHello. 1341 finished: indicates that the LURK client or the Cryptographic Service 1342 has determined the session shoudl be closed an ks_ctx are deleted. 1344 The Cryptographic Service contains three databases: 1346 CTX_ID_DB: database that contains the valid ctx_id of type opaque. 1348 PSK_DB: contains the list of PSKs, with associated parameters such as 1349 Hash function. This database includes the session resumption 1350 tickets. 1352 Key_DB: contains the asymetric signing keys with supported signing 1353 algorithms. 1355 9.1.1. LURK client 1356 TLS Client Policy for authentication 1357 PSK, PSK-ECDHE ECDHE 1358 | | 1359 | | 1360 v | 1361 psk ---> +--------------------+ | 1362 | binder_key | | 1363 +--------------------+ | 1364 EARLY_EXPORTER, 0-RTT | | 1365 v | | 1366 /------------------------\ NO | 1367 \------------------------/----+ | 1368 YES v | | 1369 +--------------------+ | | 1370 | early_secret | | | 1371 +--------------------+ | | 1372 ClientHello | | | 1373 <---- +<-----------------+--------+ 1374 ServerHello YES v 1375 ----> +-------------------------------------------+ 1376 | init_handshake_secret or handshake_secret | 1377 +-------------------------------------------+ 1378 | 1379 /--------------------\ NO 1380 | CertificateRequest |------+ 1381 \--------------------/ | 1382 YES v v 1383 +--------------------+-----------------+ 1384 | certificate_verify | app_secret | 1385 +--------------------+-----------------+ 1386 client Finished | | 1387 <---- +------------+--------+ 1388 | 1389 +--------------------------------------+ 1390 | LURK client post handshake exchanges | 1391 +--------------------------------------+ 1393 The LURK client post handshake diagram is represented below: 1395 POST_HANDSHAKE_AUTH | 1396 v v 1397 /-------------------------\ NO 1398 | post_hand_auth_proposed |------+ 1399 \-------------------------/ | 1400 YES v | 1401 +-----------------------------+ | 1402 | register_session_tickets | | 1403 | (empty NewSessionTickets) | | 1404 +-----------------------------+ | 1405 | | 1406 +<-----------------+ 1407 | 1408 +<-----------------------------------------------+ 1409 | | 1410 +------------------------------+ | 1411 SESSION_RESUMPTION | POST_HANDSHAKE_AUTH | | 1412 client Finished | | CertificateRequest | | | 1413 NewSessionTickets| | | v v | 1414 | v v | /-------------------------\NO | 1415 | /-------------\ NO +---> | post_hand_auth_proposed |--+ | 1416 +----> \-------------/---------+ \-------------------------/ | | 1417 YES v | YES v | | 1418 +-----------------------------+ | +-------------------------+ | | 1419 | register_session_ticket | | | post_handshake | | | 1420 +-----------------------------+ | +-------------------------+ | | 1421 v v v | | 1422 +-----------------+----------+---+----------------+ | 1423 v | 1424 /--------------------\ NO | 1425 | finished |----------+ 1426 \--------------------/ 1427 YES v 1428 +-------------------------+ 1429 | LURK exchanges Finished | 1430 +-------------------------+ 1432 9.1.2. Cryptographic Service 1433 TLS13Request 1434 | 1435 /---------------------------\NO /-------------------------------\NO 1436 | type is early_data |-->| type is init_handshake_secret |-+ 1437 \---------------------------/ \-------------------------------/ | 1438 | | +------------------+ 1439 | +------------+ | 1440 | v | 1441 | /-------------------\NO /----------------\NO 1442 | | psk_selected |-+ | session,cookie | +-------+ 1443 | \------------------ / | | consistent |---| ERROR | 1444 | YES | | \----------------/ +-------+ 1445 +----------------+ | | 1446 PSK, PSK-ECDHE | | ECHDE | 1447 v +-------------+ | 1448 /-------------------\NO +-------+ | | 1449 | psk_key in PSK_DB |---| ERROR | | | 1450 \-------------------/ +-------+ | | 1451 +-------------------------+ | 1452 | | 1453 +-------------+ | 1454 | Init ks_ctx | | 1455 +-------------+ | 1456 | | 1457 +---------------------------+ 1458 | 1459 v 1460 +---------------------------+ 1461 | process the request | 1462 | update CTX_DB, PSK_DB | 1463 +---------------------------+ 1465 9.2. LURK state diagrams on TLS on TLS server 1467 9.2.1. LURK client 1468 TLS Server Policy for authentication 1469 received PSK, PSK-ECDHE, ECDHE 1470 ClientHello | | 1471 ----> v v 1472 psk ---->+----------------------+ +----------------------+ 1473 | Init ks_ctx | | Init ks_ctx | 1474 +----------------------+ +----------------------+ 1475 v | 1476 +---------------------+ | 1477 | early_secret | | 1478 +---------------------+ | 1479 | | 1480 to be formed YES v v 1481 ServerHello +--------------------------+ +-------------------------+ 1482 ----> | handshake_and_app_secret | | init_certificate_verify | 1483 +--------------------------+ +-------------------------+ 1484 | | 1485 +---------------------------+ 1486 | 1487 v 1488 +--------------------------------------+ 1489 | LURK client post handshake exchanges | 1490 +--------------------------------------+ 1492 9.2.2. Cryptographic Service 1493 TLS13Request 1494 | 1495 /---------------------------\NO /--------------------------------\NO 1496 | type is early_data |-->| type is init_certificate_verify |-+ 1497 \---------------------------/ \--------------------------------/ | 1498 PSK, | +-------------------------+ 1499 PSK-ECDHE v | 1500 /-------------------\NO +-------+ /----------------\NO 1501 | psk_key in PSK_DB |---| ERROR | | session,cookie | +-------+ 1502 \-------------------/ +-------+ | consistent |---| ERROR | 1503 | \----------------/ +-------+ 1504 v | 1505 +-------------+ | 1506 | Init ks_ctx | | 1507 +-------------+ | 1508 | | 1509 +-----------------------------+ 1510 | 1511 v 1512 +---------------------------+ 1513 | process the request | 1514 | update CTX_DB, PSK_DB | 1515 +---------------------------+ 1517 9.3. TLS handshakes with Cryptographic Service 1519 This section is non normative. It illustrates the use of LURK in 1520 various configurations. 1522 The TLS client may propose multiple ways to authenticate the server 1523 (ECDHE, PSK or PSK-ECDHE). The TLS server may chose one of those, 1524 and this choice is reflected by the LURK client on the TLS server. 1525 In other words, this decision is out of scope of the Cryptographic 1526 Service. 1528 The derivation of the secrets is detailed in {{!RFC8446)) section 1529 7.1. Secrets are derived using Transcript-Hash and HKDF, PSK and 1530 ECDHE secrets as well as some Handshake Context. 1532 The Hash function: When PSK or PSK-ECDHE authentication is selected, 1533 the Hash function is a parameter associated to the PSK. When ECDHE, 1534 the hash function is defined by the cipher suite algorithm 1535 negotiated. Such algorithm is defined in the cipher_suite extension 1536 provided in the ServerHello which is provided by the LURK client in 1537 the first request when ECDHE authentication is selected. 1539 PSK secret: When PSK or PSK-ECDHE authentication is selected, the PSK 1540 is the PSK value identified by the identity. When ECDHE 1541 authentication is selected, the PSK takes a default value of string 1542 of Hash.length bytes set to zeros. 1544 ECDHE secret: When PSK or PSK-ECDHE authentication is selected, the 1545 ECDHE secret takes the default value of a string of Hash.length bytes 1546 set to zeros. The Hash is always known as a parameter associated to 1547 the selected PSK. When ECDHE authentication is selected, the ECDHE 1548 secret is generated from the secret key (ephemeral_sercet) provided 1549 by the LURK client and the counter part public key in the key_share 1550 extension. When the LURK client is on the TLS client, the public key 1551 is provided in the ServerHello. When the LURK client is on the TLS 1552 Server, the public key is provided in the ClientHello. When ECDHE 1553 secret is needed, ClientHello...ServerHello is always provided to the 1554 Cryptographic Service. 1556 Handshake Context: is a subset of Handshake messages that are 1557 necessary to generated the requested secrets. The various Handshake 1558 Contexts are summarized below: 1560 +------------------------------------+--------------------------------+ 1561 | Key Schedule secret or key | Handshake Context | 1562 +---------------------------------------------------------------------+ 1563 | binder_key | None | 1564 | client_early_traffic_secret | ClientHello | 1565 | early_exporter_master_secret | ClientHello | 1566 | client_handshake_traffic_secret | ClientHello...ServerHello | 1567 | server_handshake_traffic_secret | ClientHello...ServerHello | 1568 | client_application_traffic_secret_0 | ClientHello...server Finished | 1569 | server_application_traffic_secret_0 | ClientHello...server Finished | 1570 | exporter_master_secret | ClientHello...server Finished | 1571 | resumption_master_secret | ClientHello...client Finished | 1572 +---------------------------------------------------------------------+ 1574 The Cryptographic Service has always the Hash function, the PSK and 1575 ECDHE secrets and the only remaining parameter is the Handshake 1576 Context. The remaining sections will only focus on checking the 1577 Handshake Context available to the Cryptographic Service is 1578 sufficient to perform the key schedule. 1580 When ECDHE authentication is selected both for the TLS server or the 1581 TLS client, a CertificateVerify structure is generated as described 1582 in [RFC8446] section 4.4.3.. CertificateVerify consists in a 1583 signature over a context that includes the output of Transcript- 1584 Hash(Handshake Context, Certificate) as well as a context string. 1585 Both Handshake Context and context string depends on the Mode which 1586 is set to server in this case via the configuration of the LURK 1587 server. Similarly to the key schedule, the Hash function is defined 1588 by the PSK or the ServerHello. The values for the Handshake Context 1589 are represented below: 1591 +-----------+-------------------------+-----------------------------+ 1592 | Mode | Handshake Context | Base Key | 1593 +-----------+-------------------------+-----------------------------+ 1594 | Server | ClientHello ... later | server_handshake_traffic_ | 1595 | | of EncryptedExtensions/ | secret | 1596 | | CertificateRequest | | 1597 | | | | 1598 | Client | ClientHello ... later | client_handshake_traffic_ | 1599 | | of server | secret | 1600 | | Finished/EndOfEarlyData | | 1601 | | | | 1602 | Post- | ClientHello ... client | client_application_traffic_ | 1603 | Handshake | Finished + | secret_N | 1604 | | CertificateRequest | | 1605 +-----------+-------------------------+-----------------------------+ 1607 When ECDHE authentication is selected, the Cryptographic Service 1608 generates a Finished message, which is a MAC over the value 1609 Transcript-Hash(Handshake Context, Certificate, CertificateVerify) 1610 using a MAC key derived from the Base Key. As a result, the same Base 1611 Key and Handshake Context are required for its computation describe 1612 din [RFC8466] section 4.4.4.. 1614 9.4. TLS 1.3 ECDHE Full Handshake 1616 This example illustrates the case of a TLS handshake where the TLS 1617 server is authenticated using ECDHE only, that is not PSK or PSK- 1618 ECDHE authentication is provided and so session resumption is 1619 provided either. 1621 9.4.1. TLS Client: ClientHello 1623 The TLS client does not provides any PSK and omits the pre_shared_key 1624 as well as the psk_key_exchange_mode extensions. Note that omitting 1625 the psk_key_exchange_mode extension prevents the TLS client to 1626 perform further session resumption. 1628 The TLS client does not need any interaction with the Cryptographic 1629 Service to generate and send the ClientHello message to the TLS 1630 server. 1632 TLS Client TLS Server 1634 Key ^ ClientHello 1635 Exch | + key_share 1636 v + signature_algorithms ---------> 1638 9.4.2. TLS Server: ServerHello 1640 Upon receiving the ClientHello, the TLS server determines the TLS 1641 client requests an ECDHE authentication. The TLS server initiates a 1642 LURK session to provide ECDHE authentication as represented below: 1644 TLS Client TLS Server 1646 ServerHello ^ Key 1647 + key_share | Exch 1648 {EncryptedExtensions} ^ Server 1649 {CertificateRequest*} v Params 1650 {Certificate} ^ 1651 {CertificateVerify} | Auth 1652 {Finished} v 1653 <-------- [Application Data*] 1655 The LURK Client on the TLS server initiates a init_certificate_verify 1656 to retrieves the necessary secrets to finish the exchange and request 1657 the generation of the signature (certificate_verify) carried by the 1658 CertificateVerify TLS structure. 1660 The init_certificate_verify request uses a 1661 InitCertificateVerifyRequest structure which is composed of three 1662 substructures: a ContextAgreementRequest structure (ctx_request) that 1663 is in charge of setting up the LURK session. The parameters 1664 associated to the LURK session are designated as context. A 1665 SecretRequest structure (secret_request) is in charge of requesting 1666 the necessary secrets to decrypt and encrypt the TLS handshake as 1667 well as the applications carried over the TLS session. Finally a 1668 SigningRequest substructure (signing_request) is used to request the 1669 certificate_verify payload. 1671 The secret_request carries the requested secrets as well as the 1672 necessary parameters to generate the secrets. In our case, the 1673 requested secrets are the handshake secrets (h_c, h_s) as well as the 1674 application secrets (a_c, a_s). This corresponds to the most 1675 expected use cases, though other use case may require different 1676 secrets to be requested. Theses requests are indicated in the 1677 key_request. The necessary Handshake Context is provided through 1678 handshake_context which is set to ClientHello ... 1679 EncryptedExtensions. The ECDHE shared secret is provided in this 1680 example via the ephemeral extension. In our case, the secret key is 1681 provided directly thought other means may be used. In particularly 1682 providing the secret key implies the dhe parameters have been 1683 generated outside the Cryptographic Service. The freshness function 1684 is provided through the freshness extension. 1686 The signing_request provides the key_id that identifies the private 1687 key used to generate the signature, the algorithm use dto generate 1688 the signature (sig_algo) as well as the certificate. The certificate 1689 carries information to generate the Certificate structure of the 1690 ServerHello, and may not be the complete certificate chain but only 1691 an index. 1693 TLS Server 1694 Lurk Client Cryptographic Service 1695 InitCertificateVerifyRequest 1696 ctx_request 1697 secret_request 1698 key_request = h_c, h_s, a_c, a_s 1699 handshake_context = ClientHello ... EncryptedExtensions 1700 ext 1701 ephemeral = dhe_secret 1702 freshness 1703 signing_request 1704 key_id, 1705 sig_algo 1706 certificate 1707 --------> 1708 InitCertificateVerifyResponse 1709 ctx_response 1710 secret_response 1711 keys 1712 signing_response 1713 certificate_verify 1714 <--------- 1716 Upon receiving the InitCertificateRequest, the Cryptographic Service 1717 initiates a context associated to the newly created LURK session. 1719 The secrets are generated from the TLS 1.3 key schedule describe din 1720 [RFC8446] and requires as input PSK, ECDHE as well as some context 1721 handshake. 1723 The Cryptographic Service determine that ECDHE without specific PSK 1724 is used from the ClientHello and associated extensions. As a result, 1725 the default PSK value is used. The ECDHE share secret is derived, in 1726 our case from the dhe_secret of the TLS server and the public dhe 1727 value provided by the ClientHello shared_key extension. 1729 The Cryptographic Service reads the freshness extension and generates 1730 the handshake_context that will be used further. 1732 The necessary Handshake Context to generate the handshake secrets is 1733 ClientHello...ServerHello which is provided by the handshake_context. 1734 The Cryptographic Service uses the freshness function provided in the 1735 freshness extension to 1737 The generation of the CertificateVerify is described in [RFC8446] 1738 section 4.4.3. and consists in a signature over a context that 1739 includes the output of Transcript-Hash(Handshake Context, 1740 Certificate) as well as a context string. Both Handshake Context and 1741 context string depends on the Mode which is set to server in this 1742 case via the configuration of the LURK server. 1744 The necessary Handshake Context to generate the CertificateVerify is 1745 ClientHello ... later of EncryptedExtensions / CertificateRequest. 1746 In our case, this is exactly handshake_context, that is ClientHello 1747 ... EncryptedExtensions. The Certificate payload is generated from 1748 the information provided in the certificate extension. 1750 Once the certificate_verify value has been defined, the LURK server 1751 generates the server Finished message in order to have the necessary 1752 Handshake Context ClientHello...server Finished to generate the 1753 application secrets. 1755 The LURK server returns the requested keys, the certificate_verify in 1756 a InitCertificateVerifyResponse structure. This structure is 1757 composed of the three substructures ContextAgreementResponse 1758 (ctx_response), SecretResponse that contains the secrets and 1759 SigningResponse that contains the certificate_verify. 1761 The TLS server can complete the ServerHello response, that is proceed 1762 to the encryption and generates the Finished message. 1764 As session resumption is not provided, the LURK server goes into a 1765 finished state and delete the ks_ctx. The special case described in 1766 this session does not use LURK session and as such may be stateless. 1768 9.4.3. TLS client: client Finished 1770 Upon receiving the ServerHello message, the TLS client retrieve the 1771 handshake and application secrets to decrypt the messages received 1772 from server as well as to encrypt its own messages and application 1773 data as represented below: 1775 TLS Client TLS Server 1777 {Finished} --------> 1778 [Application Data] <-------> [Application Data] 1780 To retrieves these secrets, the TLS client proceeds successively to 1781 an init_handshake_secret LURK exchange followed by a app_secret LURK 1782 exchange. 1784 The init_handshake_secret exchange is composed of two substructures. 1785 The ContextAgreement (ctx_request) to set a LURK session between the 1786 TLS client and the Cryptographic Service and a SecretRequest 1787 (secret_request) to request the secrets. Optionally, a 1788 SigningRequest (signing_request) when the TLS server requests the TLS 1789 client to authenticate itself. The indication of a request for TLS 1790 client authentication is performed by the TLS server by providing a 1791 CertificateRequest message associated to the ServerHello. We 1792 consider that such request has not been provided here so the 1793 SigingRequest structure is not present. 1795 The secret_request specifies the secrets requested via the 1796 key_request. In our case only the handshake secrets are requested 1797 (h_c, h_s). In this example the ECDHE share secret is provided via 1798 the ephemeral extension. In this case the ECDHE secrets have been 1799 generated by the TLS client, and the TLS client chooses to provide 1800 the ephemeral secret (dhe_secret) to the Cryptographic Service via 1801 the ephemeral extension. The TLS client also provides the freshness 1802 function via the freshness extension so the handshake_context can be 1803 appropriately be interpreted. The handshake context is provided via 1804 the handshake_context and is set to ClientHello ... ServerHello. 1806 Note that if the TLS client would have like the Cryptographic Service 1807 to generate the ECDHE public and private keys, the generation of the 1808 keys would have been made before the ClientHello is sent, that is in 1809 our case during a early_secret LURK exchange. If that had been the 1810 case a handshake_secret LURK exchange would have followed and not a 1811 init_handshake_secret exchange. 1813 TLS Client 1814 Lurk Client Cryptographic Service 1815 InitHandshakeSecretRequest 1816 ctx_request 1817 secret_request 1818 key_request = h_c, h_s 1819 handshake_context = ClientHello ... ServerHello 1820 ext 1821 ephemeral = dhe_secret 1822 freshness 1823 -------> 1825 InitHandshakeSecretResponse 1826 ctx_response 1827 secret_response 1828 <-------- keys 1829 TLS Client 1830 Lurk Client Cryptographic Service 1831 AppSecretRequest 1832 session_id 1833 cookie 1834 secret_Request 1835 key_request 1836 handshake_context 1837 -------> 1839 AppSecretResponse 1840 session_id 1841 cookie 1842 secret_response 1843 <-------- keys 1845 Upon receiving the InitHandshakeSecretRequest, the servers initiates 1846 a LURK session context (ks_ctx) and initiates a key schedule. The 1847 key schedule requires PSK, ECDHE as well as Handshake Context to be 1848 complete. As no pre_shared_key and psk_key exchange_modes are found 1849 in the ClientHello the Cryptographic Service determines that ECDHE is 1850 used for the authentication. The PSK is set to its default value. 1851 The ECHDE shared secret is generated from the ephemeral extension as 1852 well as the public value provided in the ClientHello. The 1853 Cryptographic Service takes the freshness function and generates the 1854 appropriated handshake context. The necessary Handshake Context to 1855 generate handshake secrets is ClientHello...ServerHello which is 1856 provided by the handshake_context. 1858 The handshake secrets are returned in the secret_response to the TLS 1859 client. The TLS client decrypt the encrypted extensions and messages 1860 of the ServerHello exchange. 1862 As no CertificateREquest appears, the LURK client initiates an 1863 app_secret LURK exchange decrypt and encrypt application data while 1864 finishing the TLS handshake. 1866 The AppSecretRequest structure uses session_id and cookies as agreed 1867 in the previous init_handshake_secret exchange. The AppSecretRequest 1868 embeds a SecretRequest sub structure. The application secrets 1869 requested are indicated by the key_request (a_s, a_s). The Handshake 1870 Context (handshake_context) is set to server EncryptedExtensions ... 1871 server Finished. 1873 Upon receiving the AppSecretRequest, the Cryptographic Service checks 1874 the session_id and cookies. The Cryptographic Service has now the 1875 ClientHello ... server Finished which enables it to compute the 1876 application secrets. 1878 As no session resumption is provided, the Cryptographic Service and 1879 the LURK client goes into a finished state and delete their ks_ctx. 1881 9.5. TLS 1.3 Handshake with session resumption 1883 This scenario considers that the TLS server is authenticated using 1884 ECDHE only in the first time and that further TLS handshake use the 1885 session resumption mechanism. The first TLS Handshake is very 1886 similar as the previous one. The only difference is that 1887 psk_key_exchange_mode extension is added to the ClientHello. 1888 However, as no PSK identity is provided, the Full exchange is 1889 performed as described in section Section 9.4. 1891 The only change is that session resumption is activated, and thus 1892 LURK client and LURK servers do not go in a finished state and close 1893 the LURK session after the exchanges are completed. Instead further 1894 exchanges are expected. Typically, on the TLS server side 1895 new_Session_ticket exchanges are expected while 1896 registered_session_ticket are expected on the client side. 1898 When session resumption is performed, a new LURK session is 1899 initiated. 1901 9.5.1. Full Handshake 1903 The Full TLS Handshake use ECDHE authentication. It is very similar 1904 to the logic described in section Section 9.4. The TLS handshake is 1905 specified below for convenience. 1907 TLS Client TLS Server 1909 Key ^ ClientHello 1910 Exch | + key_share 1911 | + psk_key_exchange_mode 1912 v + signature_algorithms ---------> 1913 ServerHello ^ Key 1914 + key_share | Exch 1915 {EncryptedExtensions} Server Param 1916 {Certificate} ^ 1917 {CertificateVerify} | Auth 1918 {Finished} v 1919 <-------- [Application Data*] 1920 {Finished} --------> 1921 [Application Data] <-------> [Application Data] 1923 9.5.2. TLS server: NewSessionTicket 1925 As session resumption has been activated by the 1926 psk_key_exchange_mode, the TLS Server is expected to provide the TLS 1927 client NewSessionTickets as mentioned below: 1929 TLS Client TLS Server 1930 <-------- [NewSessionTicket] 1932 The LURK client and LURK server on the TLS server does not go into a 1933 finished state. Instead, the LURK client continues the LURK session 1934 with a NewSessionTicketRequest to enable the Cryptographic Service to 1935 generate the resumption_master_secret necessary to generate the PSK 1936 and generate a NewTicketSession. ctx_id is of type opaque, ticket_nbr 1937 indicate sthe number of NewSessionTickets and handshake_context is 1938 set to earlier of client Certificate client CertificateVerify ... 1939 client Finished. As we do not consider TLS client authentication, 1940 the handshake_context is set to client Finished as represented below. 1942 TLS Server 1943 Lurk Client Cryptographic Service 1944 NewSessionTicketRequest 1945 session_id 1946 cookie 1947 ticket_nbr 1948 handshake_context=client Finished --------> 1949 NewSessionTicketResponse 1950 session_id 1951 cookie 1952 <--------- tickets 1954 The necessary Handshake Context to generate the 1955 resumption_master_secret is ClientHello...client Finished. From the 1956 InitCerificateVerify the context_handshake was set to 1957 ClientHello...server Finished. The additional handshake_context 1958 enables the Cryptographic Service to generate the NewSessionTickets. 1960 Note that the LURK client on the TLS server may send multiple 1961 NewSessionTicketRequest. Future request have an empty 1962 handshake_context. 1964 Upon receiving the NewSessionTicketRequest, the LURK server checks 1965 the session_id and cookie. It then generates the 1966 resumption_master_secret, NewSessionTickets. NewSessionTickets are 1967 stored into the PSK_DB under NewSessionTicket.ticket. Note that PSK 1968 is associated with the authentication mode as well as the Hash 1969 function negotiated for the cipher suite. The Cryptographic Service 1970 responds with NewSessionTickets that are then transmitted back to the 1971 TLS client. The TLS server is ready for session resumption. 1973 9.5.3. TLS client: NewSessionTicket 1975 Similarly, the LURK client on the TLS client will have to provide 1976 sufficient information to the Cryptographic Service the necessary PSK 1977 can be generated in case of session resumption. This includes the 1978 remaining Handshake Context to generate the resumption_master_secret 1979 as well as NewSessionTickets provided by the TLS server. The LURK 1980 client uses the register_session_ticket exchange. 1982 Note that the LURK client may provide the handshake_context with an 1983 empty list of NewSessionTickets, and later provide the 1984 NewSessionTickets as they are provided by the TLS server. The 1985 Handshake Context only needs to be provided for the first 1986 RegisterSessionTicketRequest. 1988 TLS Client 1989 Lurk Client Cryptographic Service 1990 NewSessionTicketRequest 1991 session_id 1992 cookie 1993 handshake_context=client Finished 1994 ticket_list --------> 1995 NewSessionTicketResponse 1996 session_id 1997 cookie 1998 <--------- tickets 2000 Both TLS client and TLS Servers are ready for further session 2001 resumption. On both side the Cryptographic Service stores the PSK in 2002 a database designated as PSK_DB. Each PSK is associated to a Hash 2003 function as well as authentication modes. Each PSK is designated by 2004 an identity. The identity may be a label, but in our case the 2005 identity is derived from the NewSessionTicket.ticket. 2007 9.5.4. Session Resumption 2009 Session resumption is initiated by the TLS client. Session 2010 resumption is based on PSK authentication and different PSK may be 2011 proposed by the TLS client. The TLS handshake is presented below. 2013 TLS Client TLS Server 2014 ClientHello 2015 + key_share 2016 + psk_key_exchange_mode 2017 + pre_shared_key --------> 2018 ServerHello 2019 + pre_shared_key 2020 + key_share 2021 {EncryptedExtensions} 2022 {Finished} 2023 <-------- [Application Data*] 2025 The TLS client may propose to the TLS Server multiple PSKs. Each of 2026 these PSKs is associated a PskBindersEntry defined in [RFC8446] 2027 section 4.2.11.2. PskBindersEntry is computed similarly to the 2028 Finished message using the binder_key and the partial ClientHello. 2030 The TLS server is expected to pick a single PSK and validate the 2031 binder. In case the binder does not validate the TLS Handshake is 2032 aborted. As a result, only one binder_key is expected to be 2033 requested by the TLS server as opposed to the TLS client. 2035 In this example we assume the psk_key_exchange_mode indicated by the 2036 TLS client supports PSK-ECDHE as well as PSK authentication. The 2037 presence of a pre_shared_key and a key_share extension in the 2038 ServerHello inidcates that PSK-ECDHE has been selected. 2040 9.5.4.1. TLS client: ClientHello 2042 To compute binders, the TLS Client needs to request the binder_key 2043 associated to each proposed PSK. These binder_keys are retrieved to 2044 the Cryptographic Service using the BinderKeyRequest. The 2045 key_request is set to binder_key, and the PSK_id extension indicates 2046 the PSK's identity (PSKIdentity.identity or NewSessionTicket.ticket). 2047 No Handsahke Context is needed and handshake_context is empty. 2049 TLS Client 2050 Lurk Client Cryptographic Service 2051 BinderKeyRequest 2052 key_request=binder_key 2053 handshake_context="" 2054 ext 2055 PSK_id 2056 BinderKeyResponse 2057 <--------- key 2059 Upon receiving the BinderKeyRequest, the Cryptographic Service checks 2060 the psk is in the PSK_DB and returns the binder_key. 2062 With the binder keys, the TLS Client is able to send it ClientHello 2063 message. 2065 We assume in this example that the ECDHE secrets is generated by the 2066 TLS client and not the Cryptographic service. As a result, the TLS 2067 client does not need an extra exchange to request the necessary 2068 parameters to derive the key_shared extension. 2070 9.5.4.2. TLS server: ServerHello 2072 The TLS server is expected to select a PSK, check the associated 2073 binder and proceed further. If the binder fails, it is not expected 2074 to proceed to another PSK, as a result, the TLS server is expected to 2075 initiates a single LURK session. 2077 The binder_key is requested by the TLS server via and early_secret 2078 LURK exchange. The EarlySecretRequest structure is composed of a 2079 ContextAgreementRequest (ctx_request) and a SecretRequest structure 2080 (secret_request). 2082 In our case, only the binder_key is requested so key_request is set 2083 to binder_key only. Similarly, to the TLS client, the 2084 handshake_context is not needed to generate the binder_key. However, 2085 the EarlySecret exchange requires the ClientHello to be provided so 2086 early secrets may be computed in the same round during 0-RTT 2087 handshake. The chosen PSK is indicated in the PSK_id extension and 2088 the freshness function is indicated in the freshness extension. 2090 TLS Server 2091 Lurk Client Cryptographic Service 2092 EarlySecretRequest 2093 ctx_request 2094 secret_Request 2095 key_request=binder_key 2096 handshake_context=ClientHello 2097 ext 2098 freshenss 2099 PSK_id 2100 EarlySecretResponse 2101 ctx_response 2102 secret_response 2103 <--------- key 2105 To complete to the ServerHello exchange, the TLS server needs the 2106 handshake and application secrets. These secrets are requested via 2107 an handshake_and_app_secret LURK exchange. The 2108 HandshakeAndAppSecretRequest is composed of SecretRequest structure. 2109 The key_request is set to handshake (h_c, h_s) and application 2110 secrets (a_s, a_c). The Handshake Context (handshake_context) is set 2111 to ServerHello ... EncryptedExtensions as their is no authentication 2112 of the TLS client. Finally, the ephemeral ECDHE is provided or 2113 requested via the ephemeral extension. In our case, we assume the 2114 ephemeral secrets is generated by the tLS client is provided to the 2115 Cryptographic Service. 2117 The necessary Handshake Context to generate the handshake secrets is 2118 ClientHello ... ServerHello, so the Cryptographic Service can 2119 generate the handshake secrets. The necessary Handshake Context to 2120 generate the application secrets is ClientHello ... server Finished. 2121 So the Cryptographic Service needs to generate the Finished message 2122 before as in the case of the InitCerificateVerify exchange detailed 2123 in Section 9.5.1. 2125 TLS Server 2126 Lurk Client Cryptographic Service 2127 HandshakeAndAppRequest 2128 session_id 2129 cookie 2130 secret_request 2131 key_request = h_c, h_s, a_c, a_s 2132 handshake_context = ServerHello ... EncryptedExtensions 2133 ext 2134 ephemeral = dhe_secret --------> 2135 HandshakeAndAppResponse 2136 session_id 2137 cookie 2138 secret_response 2139 keys 2140 <--------- 2142 The Cryptographic Service returns the necessary secret to the TLS 2143 server to complete the ServerHello response. 2145 The remaining of the TLS handshake is proceeded similarly as 2146 described in the Full Handshake in section Section 9.5. 2148 9.6. TLS 1.3 0-RTT handshake 2150 The 0-RTT Handshake is a PSK or PSK-ECDHE authentication that enables 2151 the TLS client to provide application data during the first round 2152 trip. The main differences to the PSK PSK-ECDHE authentication 2153 described in the case of session resumption is that: 2155 o Application Data is encrypted in the ClientHello based on the 2156 client_early_secret 2158 o Generation of the client_early_secret requires the Cryptographic 2159 Service to be provisioned with the ClientHello which does not need 2160 to be re-provisioned later to generate the handshake secrets 2162 o An additional message EndOfEarlyData needs to be considered to 2163 compute the client Finished message. 2165 TLS Client TLS Server 2167 ClientHello 2168 + early_data 2169 + key_share* 2170 + psk_key_exchange_modes 2171 + pre_shared_key 2172 (Application Data*) --------> 2173 ServerHello 2174 + pre_shared_key 2175 + key_share* 2176 {EncryptedExtensions} 2177 + early_data 2178 {Finished} 2179 <-------- [Application Data*] 2180 (EndOfEarlyData) 2181 {Finished} --------> 2182 [Application Data] <-------> [Application Data] 2184 9.6.1. TLS client: ClientHello 2186 With 0-RTT handshake, the TLS client builds binders as in session 2187 resumption described in section Section 9.5.4. The binder_key is 2188 retrieved for each proposed PSK with a BinderKeyRequest. When early 2189 application data is sent it is encrypted using the 2190 client_early_traffic_secret. This secret is retrieved using the 2191 early_secret LURK exchange. 2193 The EarlySecretRequest is composed of a ContextAgreementRequest 2194 (ctx_request) and a SecretRequest (secret_request) substructure. The 2195 TLS Client sets the key_request to client_early_traffic_secret (e_s). 2196 The handshake is set to ClientHello. The PSK is indicated via the 2197 the PSK_id extension, the freshness function is indicated via the 2198 freshness extension. If the TLS client is willing to have the ECDHE 2199 keys generated by the Cryptographic Service an ephemeral extension 2200 MAY be added also. 2202 When multiple PSK are proposed by the TLS client, the first proposed 2203 PSK is used to encrypt the application data. 2205 TLS Client 2206 Lurk Client Cryptographic Service 2207 EarlySecretRequest 2208 ctx_request 2209 secret_request 2210 key_request=e_s 2211 handshake_context=ClientHello 2212 ex 2213 PSK_id 2214 fresness 2215 EarlySecretResponse 2216 ctx_response 2217 secret_response 2218 <--------- keys=e_s 2220 Upon receiving the EarlySecretRequest, the Cryptographic Service 2221 generates the client_early_traffic_secret. 2223 The TLS client is able to send its ClientHello with associated 2224 binders and application data. 2226 9.6.2. TLS server: ServerHello 2228 If the TLS server accepts the early data. It proceeds as described 2229 in session resumption described in section Section 9.5.4. In 2230 addition to the binder_key, the TLS server also request the 2231 client_early_traffic_secret to decrypt the early data as well as to 2232 proceed to the ServerHello exchange. 2234 9.6.3. TLS client: Finished 2236 The TLS client proceeds as described in handshake based on ECDHE, PSK 2237 or PSK-ECDHE authentications described in Section 9.4 and 2238 Section 9.5. The main difference is that upon requesting handshake 2239 and application secrets, using an HandshakeRequest the TLS client 2240 will not provide the ClientHello as part as the handshake_context. 2241 The Client as already been provided during the EarlySercret exchange. 2243 9.7. TLS client authentication 2245 TLS client authentication can be performed during the Full TLS 2246 handshake or after the TLS handshake as a post handshake 2247 authentication. In both cases, the TLS client authentication is 2248 initiated by the TLS server sending a CertificateRequest. The 2249 authentication is performed via a CertificateVerify message generated 2250 by the TLS client but such verification does not involve the 2251 Cryptographic Service on the TLS server. 2253 9.8. TLS Client:Finished (CertificateRequest) 2255 The ServerHello MAY carry a CertificateRequest encrypted with the 2256 handshake sercets. 2258 Upon receiving the ServerHello response, the TLS client decrypts the 2259 ServerHello response. If a CertificateRequest message is found, the 2260 TLS Client requests the Cryptographic to compute the 2261 CertificateVerify in addition to the application secrets via a 2262 certificate_verify LURK exchange. The CertificateVerifyRequest is 2263 composed of a Secret Request structure and a SigningRequest 2264 structure. 2266 The key_request is set to the application secrets (a_c, a_s) and the 2267 handshake_context is set to server EncryptedExtensions ... later of 2268 server Finished/EndOfEarlyData. As the request follows a (BinderKey, 2269 EarlySecret, HandshakeSecret) or HandshakeSecret the Handshake 2270 Context on the Cryptographic Service now becomes: ClientHello ... 2271 later of server Finished/EndOfEarlyData which is the Handshake 2272 Context required to generate the CertificateVerify on the TLS client 2273 side and includes the Handshake Context required to generate the 2274 application secrets (ClientHello...server Finished). 2276 TLS Client 2277 Lurk Client Cryptographic Service 2278 CertificateVerifyRequest 2279 session_id 2280 cookie 2281 secret_request 2282 key_request 2283 handshake_context = EncryptedExtensions ... 2284 later of server Finished/EndOfEarlyData 2285 signing_request 2286 CertificateVerifyResponse 2287 session_id 2288 cookie 2289 secret_response 2290 keys 2291 signing_response 2292 <--------- certificate_verify 2294 Upon receiving the CertificateRequest, the Cryptographic Service 2295 checks the session_id and cookie. 2297 9.9. TLS Client Authentication (PostHandshake) 2299 When post-handshake is enabled by the TLS client, the TLS client may 2300 receive at any time after the handshake a CertificateRequest message. 2301 When post handshake is enabled by the TLS client, as soon as the 2302 client Finished message has been sent, the TLS client sends a 2303 RegisteredNewSessionTicketRequest with an empty NewSessionTicket to 2304 register the remaining Handshake Context to the Cryptographic 2305 Service. ctx_id is set to opaque, handshake_context is set to earlier 2306 of client Certificate client CertificateVerify ... client Finished. 2308 Upon receiving the RegisteredNewSessionTicketsRequest the 2309 Cryptographic is aware of the full Handshake Context. It updates 2310 ks_ctx.next_request to post_handshake or register_session_ticket. 2312 TLS Client 2313 Lurk Client Cryptographic Service 2314 RegisteredNewSessionTicketRequest 2315 session_id 2316 cookie 2317 handshake_context 2318 ticket_list (empty) 2319 <--------- RegisteredNewSessionTicketResponse 2320 session_id 2321 cookie 2323 When the TLS client receives a CertificateRequest message from the 2324 TLS server, the TLS client sends a PostHandshakeRequest to the 2325 Cryptographic Service to generate certificate_verify. The 2326 handshake_context is set to CertificateRequest. The index N of the 2327 client_application_traffic_N key is provided as well as the 2328 Cryptographic so it can generate the appropriated key. 2330 TLS Client 2331 Lurk Client Cryptographic Service 2332 PostHandshakeRequest 2333 session_id 2334 cookie 2335 handshake_context=CertificateRequest 2336 app_n=N 2337 PostHandshakeResponse 2338 session_id 2339 cookie 2340 <--------- certificate_verify 2342 Upon receiving the PostHandshakeRequest the Cryptographic Service 2343 checks session_id and cookie. The necessary Handshake Context to 2344 generate the certificate_verify is ClientHello ... client Finished + 2345 CertificateRequest. Once the PostHandshakeResponse. Next requests 2346 expected are post_handshake or register_session_ticket. 2348 10. References 2350 10.1. Normative References 2352 [I-D.mglt-lurk-tls12] 2353 Migault, D. and I. Boureanu, "LURK Extension version 1 for 2354 (D)TLS 1.2 Authentication", draft-mglt-lurk-tls12-01 (work 2355 in progress), July 2018. 2357 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2358 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2359 . 2361 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2362 Data Model for Layer 2 Virtual Private Network (L2VPN) 2363 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2364 2018, . 2366 10.2. Informative References 2368 [I-D.mglt-lurk-lurk] 2369 Migault, D., "LURK Protocol version 1", draft-mglt-lurk- 2370 lurk-00 (work in progress), February 2018. 2372 [I-D.mglt-lurk-tls-use-cases] 2373 Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios, 2374 "LURK TLS/DTLS Use Cases", draft-mglt-lurk-tls-use- 2375 cases-02 (work in progress), June 2016. 2377 Author's Address 2379 Daniel Migault 2380 Ericsson 2381 8275 Trans Canada Route 2382 Saint Laurent, QC 4S 0B6 2383 Canada 2385 EMail: daniel.migault@ericsson.com