idnits 2.17.1 draft-mglt-lurk-tls13-00.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 3 instances of too long lines in the document, the longest one being 10 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 112: '...t the TLS Server MAY interact with a s...' RFC 2119 keyword, line 172: '...ographic Service MAY be required when ...' RFC 2119 keyword, line 227: '... OfferedPsks MUST represent a sing...' RFC 2119 keyword, line 240: '...andshake_context MUST be ClientHello.....' RFC 2119 keyword, line 294: '...ternative is NOT RECOMMENDED, as it me...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 213 has weird spacing: '...sk_type indic...' == Line 219 has weird spacing: '... pfs the on...' == Line 225 has weird spacing: '...red_psk reuse...' == Line 229 has weird spacing: '...ke_mode defin...' == Line 234 has weird spacing: '...h_group reuse...' == (10 more instances...) -- The document date (July 02, 2018) is 2122 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) == Outdated reference: A later version (-01) exists of draft-mglt-lurk-lurk-00 == Outdated reference: A later version (-05) exists of draft-mglt-lurk-tls12-00 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LURK D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track July 02, 2018 5 Expires: January 3, 2019 7 LURK Extension version 1 for (D)TLS 1.3 Authentication 8 draft-mglt-lurk-tls13-00 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 3, 2019. 33 Copyright Notice 35 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. LURK Header . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. handshake_server_key . . . . . . . . . . . . . . . . . . . . 4 53 3.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 5 54 3.2. Response Payload . . . . . . . . . . . . . . . . . . . . 6 55 3.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 6 56 3.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 7 57 4. auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 4.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 9 59 4.2. Response Payload . . . . . . . . . . . . . . . . . . . . 10 60 4.3. LURK Client Behavior (TLS Server) . . . . . . . . . . . . 10 61 4.4. LURK Client Behavior (TLS Client) . . . . . . . . . . . . 12 62 4.4.1. Local Ticket . . . . . . . . . . . . . . . . . . . . 13 63 4.5. LURK Server Behavior . . . . . . . . . . . . . . . . . . 14 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 67 8. Normative References . . . . . . . . . . . . . . . . . . . . 16 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 70 1. Introduction 72 This document defines a LURK extension for TLS 1.3. This document 73 assume s the reader is familiar with [I-D.mglt-lurk-lurk] that 74 describes the LURK architecture as well as the LURK Protocol and the 75 integration of the LURK extensions. The motivations for the LURK 76 Extension TLS 1.3 are similar to those for the LURK extension of TLS 77 1.2 [I-D.mglt-lurk-tls12]. 79 LURK defines an interface to a Cryptographic Service that stores the 80 security credentials - Typically the PSKs and private keys. 81 Interactions with the Cryptographic Service can be performed by the 82 TLS Client as well as by the TLS Server. 84 The TLS Server expects from the Cryptographic Service: 86 o To retrieve the necessary keys to complete the handshake. This 87 typically includes the [sender]_handshake_traffic_secret to 88 generate the keys necessary to encrypt the handshake extensions 89 and messages, the [sender]_application_traffic_secret_N keys to 90 protect the application data or the exporter_master_secret when 91 needed. 93 o To generate of Handshake message or extensions that authenticate 94 the TLS Server. This typically includes the CertificateVerify and 95 Finished message. 97 o To retrieve NewSessionTicket to enable the TLS Client to perform 98 session resumption. 100 The TLS Client expetcs from the Cryptographic Service: 102 o To retrieve the necessary keys to complete the handshake. 104 o To "provision" resumption_master_secret, so the PSK can be used 105 when the TLS Client is using session resumption using a NewSession 106 ticket. 108 o To generate of Handshake message or extensions that authenticate 109 the TLS Client. This typically includes the CertificateVerify and 110 Finished message. 112 Note that the TLS Server MAY interact with a single exchange with the 113 Cryptographic Service, the TLS Client is expected to retrieve the 114 [sender]_handshake_traffic_secret to generate the keys encrypt the 115 handshake extensions and messages to decrypt the messages/extensions 116 received from the TLS Server, prior to request for the generation of 117 the CertificateVerify or Finished message. 119 2. LURK Header 121 LURK / TLS 1.3 is a LURK Extension that introduces a new designation 122 "tls13". This document assumes that Extension is defined with 123 designation set to "tls13" and version set to 1. The LURK Extension 124 extends the LURKHeader structure defined in [I-D.mglt-lurk-lurk] as 125 follows: 127 enum { 128 tls13 (2), (255) 129 } Designation; 131 enum { 132 capabilities (0), ping (1), rsa_master (2), 133 rsa_extended_master (3), ecdhe (4), (255) 134 }TLS13Type; 136 enum { 137 // generic values reserved or aligned with the 138 // LURK Protocol 139 request (0), success (1), undefined_error (2), 140 invalid_payload_format (3), 142 //code points for ecdhe authentication 143 invalid_ec_type (9), invalid_ec_curve (10), 144 invalid_poo_prf (11), invalid_poo (12), (255) 145 }TLS13Status 147 struct { 148 Designation designation = "tls12"; 149 int8 version = 1; 150 } Extension; 152 struct { 153 Extension extension; 154 select( Extension ){ 155 case ("tls13", 1): 156 TLS12Type; 157 } type; 158 select( Extension ){ 159 case ("tls13", 1): 160 TLS13Status; 161 } status; 162 uint64 id; 163 unint32 length; 164 } LURKHeader; 166 3. handshake_server_key 168 This exchange is only expected to be performed by a TLS Client. The 169 server_handshake_key is necessary for the TLS Client to decrypt the 170 handshake message/extensions encrypted by the TLS Server. 172 Interaction with a Cryptographic Service MAY be required when the PSK 173 is protected by the Cryptographic Service. 175 3.1. Request Payload 177 enum { sha256 (0), (255) } TranscriptHash; 179 enum { psk_raw (0), psk_ticket (1), (255) } PSKType 181 struct { 182 PSKType psk_type; 183 select( psk_type ){ 184 case raw_psk : 185 opaque raw_psk<0..2^16-1>; 186 case identity_psk : 187 OfferedPsks offered_psk // {{I-D.ietf-tls-tls13}} section 4.2.11 188 } PSK 190 struct { 191 select ( ke_mode ){ // {{I-D.ietf-tls-tls13}} section 4.2.9 192 case psk_ke : 193 PSK psk 194 case psk_dhe_ke : 195 PSK psk 196 NamedGroup dh_group; // {{I-D.ietf-tls-tls13}} section 4.2.7 197 opaque dhe_secret<1..2^16-1>; 198 } 199 } KeyScheduleInputSecrets 201 enum { 202 sha256 (0) (255) 203 } PFSAlgorithm 205 struct { 206 PFSAlgorithm pfs; // {{I-D.mglt-lurk-tls12}} section 4.1 207 TranscriptHash h; 208 PskKeyExchangeMode ke_mode // {{I-D.ietf-tls-tls13}} section 4.2.9 209 opaque handshake_context<0..2^32-1> 210 KeyScheduleInputSecrets secrets 211 } HandshakeServerKeyRequest 213 psk_type indicates how the PSK is provisioned to initiate the key 214 schedule as described in [I-D.ietf-tls-tls13] section 7.1. The 215 type psk_raw indicates the PSK is explicitly provided. The type 216 psk_ticket indicates the PSK is generated from the ticket as 217 described in [I-D.ietf-tls-tls13] section 4.6.1. 219 pfs the one-way hash function (OWHF) used by LURK to implement 220 Perfect Forward Secrecy. 222 h the hash function used by the Transcript-Hash [I-D.ietf-tls-tls13] 223 section 4.4.1. 225 offered_psk reuses the OfferedPsks described in [I-D.ietf-tls-tls13] 226 section 4.2.11. The PSK structure only allow a single PSK, thus 227 OfferedPsks MUST represent a single PSK. 229 ke_mode defines pre shared key exchange defined in 230 [I-D.ietf-tls-tls13] section 4.2.9. It indicates whether the key 231 exchange considers a (EC)DHE key establishment or not in addition 232 to the PSK. 234 dh_group reuses the structure NamedGroup of [I-D.ietf-tls-tls13] 235 section 4.2.7 to indicate the curve or the group used in (EC)DHE 236 key establishment. 238 handshake_context the necessary handshake context to generate the 239 key as described in [I-D.ietf-tls-tls13] section 7.1. The 240 handshake_context MUST be ClientHello...ServerHello. 242 secrets the necessary secret inputs (PSK, (EC)DHE) secret necessary 243 for the key schedule of [I-D.ietf-tls-tls13] section 7.1. 245 3.2. Response Payload 247 struct { 248 opaque server_handshake_key<0..2^32-1> 249 } HandshakeServerKeyResponse 251 server_handshake_key the server_handshake_key 253 3.3. LURK Client Behavior 255 The TLS Client establishing a TLS session with a TLS Server receives 256 from the TLS Server a ServerHello message with additional encrypted 257 messages such as the EncryptedExtensions, the Finished as well as the 258 optional Certificate, CertificateVerify and Application Data message. 259 The TLS Client needs to retrieve the server_handshake_key in order to 260 decrypt these messages. 262 With ServerHello as the input message, the LURK Client initiates the 263 exchange as described below: 265 Perfect Forward Secrecy Setting: 267 o Perfect Forward Secrecy is performed as described in 268 [I-D.mglt-lurk-tls12] section 4.1.1 over the client_random. There 269 is no gmt_unix_time as such ServerHello.random is generated as 270 follows: ~~~ ClientHello.random = pfs( client_random + "tls13_c 271 pfs" ); ~~~ 273 Transcript Hash Setting: 275 o the value for transcript hash is provided by the configuration. 277 PSK Key Exchange Mode Setting: 279 o if the input message does not contains any key_share extension, 280 the LURK Client sets ke_mode to psk_ke. 282 o if a key_share extension is present the LURK Client sets ke_mode 283 to psk_dhe_ke. 285 Key Schedule Input Secret Setting: 287 o if the input message has no pre_shared_key extension, the LURK 288 Client sets psk_type to psk_raw with a psk of length 0. 290 o if the input message has a pre_shared_key extension, the LURK 291 Client provides the PSK that is not a PSK of zero length, as 292 follows: ..* the PSK is provided explicitly by using the psk_type 293 set to psk_raw with the explicit value of the PSK. This 294 alternative is NOT RECOMMENDED, as it means the PSK is not known 295 by the Cryptographic Service and is known outside this service. 296 It may happen when the TLS Client is configured with a PSK while 297 the Cryptographic Service is not provisioned with that PSK. The 298 case where the PSK is provided for a session resumption is outside 299 the scope of this document as the session_resumption_secret is 300 never shared outside the Cryptographic Service. ..* the PSK is 301 provided via NewSessionTicket. Upon receiving a selected_identity 302 in the pre_shared_key extension, the LURK Client selects the 303 corresponding local_ticket previously provided by the LURK Server 304 during the previous handshake. local_ticket are internal structure 305 used by LURK detailled in Section 4.4.1 307 3.4. LURK Server Behavior 309 Upon receiving a handshake_server_key request, the LURK server 310 proceeds as follows: 312 Perfect Forward Secrecy Check: 314 o if pfs is not supported, an invalid_pfs erroro is returned. 316 o ClientHello.random is generated as described in Section 3.3 and 317 the value is provided in handshake_context. 319 Transcript-Hash Check: 321 o if h is not a supported transcript-hash function and 322 invalid_transcript_hash error is returned. 324 Handshake Check: 326 o if handshake does not contains a ClientHello...ServerHello an 327 invalid_handshake error is returned. 329 PSKExchangeMode Check: 331 o if ke_mode is not supported an invalid_ke_mode error is returned. 333 KeyScheduleInputSecret Check check the validity of the secrets as 334 well as the coherence wit the pre shared key exchange. These 335 checking operations are subdivided into (EC)DHE Check and PSK Check 336 operations: 338 (EC)DHE Check: 340 o if ke_mode is set to psk_dhe_ke and secret does not contain a 341 (EC)DHE secret an invalid_secret error is returned. 343 o if the (EC)DHE secret does not match the expected length or the 344 curve is not supported an invalid_ecdhe_secret error is returned. 346 PSK Check: 348 o if the psk type is not supported a invalid_psk_type is returned. 350 o if psk_type is psk_raw and the format of the psk is unexpected an 351 invalid_psk_format error is returned. 353 o if the psk_type is psk_ticket: 355 ..* if the number of psk or associated binder is more than 1, an 356 invalid_ticket_format error is returned ..* there is no corresponding 357 identity, an invalid_psk_ticket error is returned. * if the psk_type 358 is identity_psk binder_key is generated as described in 359 [I-D.ietf-tls-tls13] section 7.1. ..* if the binder associated to 360 the psk does not match the one provided in the offered_psk and 361 invalid_binder error is returned. The binder is computed as 362 described in [I-D.ietf-tls-tls13] section 4.2.11.2. with the 363 binder_key generated as described in [I-D.ietf-tls-tls13] section 364 7.1. 366 Key Generation: 368 o server_handshake_key is generated as described in 369 [I-D.ietf-tls-tls13] section 7.1 and returned to the LURK Client. 371 4. auth 373 This exchange provides interactions with a Cryptographic Service both 374 on the TLS Client side as well as the TLS Server side. 376 4.1. Request Payload 378 enum { server (0), client (1), post-handshake (2) } HandshakeMode; 380 struct { 381 PFSAlgorithm pfs; // {{I-D.mglt-lurk-tls12}} section 4.1 382 TranscriptHash h; // c, f 383 PskKeyExchangeMode ke_mode // {{I-D.ietf-tls-tls13}} section 4.2.9 384 select( ke_mode ){ 385 case : psk_dhe_ke 386 Certificate certificate // {{I-D.ietf-tls-tls13}} section 4.4.2 387 SignatureScheme algorithm // {{I-D.ietf-tls-tls13}} section 4.2.3. 388 } 389 HandshakeMode handshake_mode // c, f 390 opaque handshake_context<0..2^32-1> // c, f 391 KeyScheduleInputSecrets secrets // f 392 uint8 key_request 393 uint8 ticket_number 394 } AuthRequest 396 c: structure used for the CertificateVerify message 397 f: structure used for the Finished message 399 pfs, h, ke_mode, handshake_context and secrets are define in 400 Section 3.1 402 certificate end point certificate defined in [I-D.ietf-tls-tls13] 403 section 4.4.2. 405 algorithm signature algorithm used defined in [I-D.ietf-tls-tls13] 406 section 4.2.3. 408 handshake_mode defines the specific Handshake Context and Base Key 409 necessary to compute authentication messages as defined in 410 [I-D.ietf-tls-tls13] section 4.4. The handshake_mode set to 411 server indicates the LURK exchange is performed by the TLS Server 412 while the handshake_mode set to client or post-handshake indicates 413 the LURK exchange is performed by the TLS Client. 415 handshake_context Handshake Context has defined in 416 [I-D.ietf-tls-tls13] section 4.4. 418 key_request indicates optional requested keys. The bit is set to 1 419 to indicate the key is being requested by the LURK Client. ..* 420 bit 0 : client_handshake_traffic_secret ..* bit 1 : 421 server_handshake_traffic_secret ..* bit 2 : 422 client_application_traffic_secret_0 ..* bit 3 : 423 server_application_traffic_secret_0 ..* bit 4 : 424 exporter_master_secret ..* bit 5-7: set to 0 426 ticket_number indicates the expected number of session resumption 427 tickets. When requested by the TLS Client the ticket_number is 428 expected to be 0 or 1. When requested by the TLS Server the 429 number can be larger. 431 4.2. Response Payload 433 struct{ 434 opaque key<0..2^16-1> 435 } Key 437 struct { 438 uint8 key_index 439 opaque key_list<0..2^32-1> 440 } Keys 442 struct { 443 Keys keys 444 CertificateVerify certificate_verify 445 Finished finished 446 NewSessionTicket ticket_list<0..2^32-1> 447 } AuthResponse 449 key_index follows the same syntax as key_request in Section 4.1. 451 key_list :the list of keys indicated by key_index. 453 ticket_list list of NewTicketSessions 455 4.3. LURK Client Behavior (TLS Server) 457 On a TLS Server, the LURK Server initiates the LURK exchange after 458 receiving the ClientHello from the TLS Client. The purpose of this 459 exchange is to retrieve the CertificateVerify, Finished, and the 460 necessary keys to: 462 o encrypt the EncryptedExtensions, Finished and optional 463 CertificateRequest Certificate and CertificateVerify message: 464 server_handshake_traffic_secret 466 o encrypt the optional Application Data message: 467 server__application_traffic_secret_N 469 o decrypt the future Finished or optional Certificate and 470 CertificateVerify message sent by the TLS Client: 471 client_handshake_traffic_secret. 473 o decrypt the future Application Data message with the 474 client__application_traffic_secret_N 476 Perfect Forward Secrecy Setting: 478 o Perfect Forward Secrecy is performed as described in 479 [I-D.mglt-lurk-tls12] section 4.1.1 over the server_random. There 480 is no gmt_unix_time as such ServerHello.random is generated as 481 follows: ~~~ ServerHello.random = pfs( server_random + "tls13_s 482 pfs" ); ~~~ 484 The LURK Client proceeds to the Transcript Hash Setting PSK Key 485 Exchange Mode Setting and the Key Schedule Input Secret Setting as 486 described in Section 3.3. 488 Handshake Mode Setting: 490 o If the LURK Client sets the handshake_mode to "server". 492 Handshake Setting: The handshake is set as described in 493 [I-D.ietf-tls-tls13] section 4.4. 495 Key Request Setting: 497 o key_request MUST have the Bit 0 and Bit 1 set to retrieve the 498 [sender]_handshake_traffic_secret. 500 o key_request MUST have the Bit 2 and Bit 3 set to retrieve the 501 [sender]_application_traffic_secret_N 503 o Key_request MAY have Bit 4 set if there is a need to use the 504 extractor. 506 Upon receiving the AuthResponse, the TLS Server encrypts the messages 507 and pursue the TLS handshake as defined in [I-D.ietf-tls-tls13]. 509 4.4. LURK Client Behavior (TLS Client) 511 On a TLS Client the LURK Client initiates an AuthRequest in order to 512 compute the Finished and optional CertificateVerify as well as to 513 retrieve the necessary keys to: 515 o encrypt the Finished and optional Certificate and 516 CertificateVerify message: client_handshake_traffic_secret 518 o encrypt the optional Application Data message: 519 server__application_traffic_secret_N 521 o decrypt the future Application Data message with the 522 server__application_traffic_secret_N 524 The TLS Client has decrypted the encrypted handshake messages sent by 525 the TLS Server by retrieving the server_handshake_traffic_secret with 526 an HandshakeServerKeyRequest. 528 The LURK Client proceeds to Perfect Forward Secrecy Setting, 529 Transcript Hash Setting, Key Schedule Input Secret Setting as 530 described in Section 3.3. 532 If the TLS Client has received a CertificateRequest from the TLS 533 Server, the LURK Client: 535 o sets the ke_mode to psk_dhe_ke. Note that the value is not 536 correlated to the value agreed psk_key_exchange_modes between the 537 TLS Client and the TLS Server. Instead it indicates the necessity 538 to generate a CertificateVerify. 540 o provides the Certificate associated to the private key of the TLS 542 Handshake Mode Setting: 544 o If the LURK Client is initiating a LURK exchange on behalf of a 545 TLS Client it sets the handshake_mode to: ..* "client" when the 546 LURK exchange occurs during the TLS handshake. ..* "post- 547 authentication" when the LURK exchange occurs outside the TLS 548 handshake. 550 Handshake Setting: 552 o set handshake_context as defined in [I-D.ietf-tls-tls13] section 553 4.4. 555 Key Request Setting: 557 o key_request SHOULD have the Bit 0 unset, as 558 client_handshake_traffic_secret is already known by the TLS Client 560 o key_request MUST have the Bit 1 set to retrieve the 561 server_handshake_traffic_secret. 563 o key_request MUST have the Bit 2 and Bit 3 set to retrieve the 564 [sender]_application_traffic_secret_N 566 o Key_request MAY have Bit 4 set if there is a need to use the 567 extractor. 569 Ticket Number Setting: 571 o If the TLS Client want to performed further session resumption, 572 ticket_number is set to 1 and 0 otherwise. 574 Upon receiving the AuthResponse, the LURK Client has the necessary 575 information to proceed the TLS handshake. The ticket_list is a list 576 of local_ticket. The list MUST have a maximum of one local_ticket. 577 The LURK Client is expected to manage the local_tickets as described 578 in Section 4.4.1 580 4.4.1. Local Ticket 582 local_ticket re-uses the NewSessionTicket structure in two different 583 ways depending if the LURK exchange is initiated by a TLS Client or 584 by a TLS Server. 586 o ticket provided to the TLS Server (by the LURK Server) are 587 new_session_ticket, expected to be forwarded to the TLS Client. 589 o tickets provided to the TLS Client ( by the LURK Server) are 590 local_ticket. These local_tickets are only expected to be used 591 between the LURK Client and the LURK Server of the TLS Client. 593 During the initial handshake, the TLS Client has received a 594 local_ticket from the LURK Server and a new_session_ticket from the 595 TLS Server. The TLS Client updates the local_ticket as follows: the 596 ticket_nonce and extensions fields of the new_session_ticket are 597 copied to the local_ticket. 599 When the TLS Server provides more than one new_session_ticket 600 tickets, these tickets are expected to have different nonce. On the 601 other hand a single local_ticket will be provided by the LURK Server. 602 The TLS Client generates an associated local_ticket for each 603 new_session_ticket. All of them are generated from the local_ticket 604 provided by the LURK Server. 606 Though the new_Session_ticket and the local_ticket have different 607 meanings, a TLS Client will not be able to perform session resumption 608 without the corresponding local_ticket. More specifically, the TLS 609 Client MUST: 611 o remove local_tickets and new_session_tickets that have expired 613 o remove local_tickets that have no associated new_session_tickets 615 o remove new_session_tickets that have no associated local_tickets 616 In all these cases, a new handshake will be renegotiated. Note 617 that this gives the Cryptographic Service the ability to define 618 the maximum time a new_session_ticket can be used. 620 4.5. LURK Server Behavior 622 Upon receiving a handshake_server_key request, the LURK server 623 proceeds as follows: 625 Perfect Forward Secrecy Check is performed as Section 3.3 using the 626 pfs, and client_random (resp. server_random) as described in 627 Section 3.3 (resp. Section 4.3). 629 Transcript-Hash Check, PSKExchangeMode Check, KeyScheduleInputSecrets 630 Check are performed as described in Section 3.4 632 HandshakeMode Check: 634 o if the mode is not supported a invalid_handshake_mode error is 635 returned. This typically prevents a TLS Client to perform 636 computation expected to happen on the TLS Server, or to 637 distinguish and authorize client authentication performed during 638 the handshake or post handshake. 640 Handshake Check: 642 o if the hanshake_context does not match the expected handshake 643 context as defined in [I-D.ietf-tls-tls13] section 4.4. an 644 invalid_handshake error is returned. 646 CertificateVerify Check: 648 o if ke_mode is set to psk_dhe_ke and the certificate is not 649 supported an invalid_certificate error is returned 651 o if ke_mode is set to psk_dhe_ke and the algorithm is not supported 652 an invalid_signature_scheme error is returned 654 Keys are generated as described in [I-D.ietf-tls-tls13] section 7.1. 655 This includes the Base Key use to generate the Finished messages as 656 well as the resumption_master_secret. 658 key_request is indicative and is used by the LURK Client to indicate 659 the keys that are not necessarily needed in order to save bandwidth. 660 The LURK Server SHOULD NOT responds with keys whose key_request bit 661 is unset. 663 The CertificateVerify message is generated as described in 664 [I-D.ietf-tls-tls13] section 4.4.3. 666 The Finished message is generated as described in 667 [I-D.ietf-tls-tls13] section 4.4.4. 669 ticket_number indicates the number of NewSessionTicket. 670 ticket_session have different meaning when used by the TLS Client or 671 the TLS Server. When the LURK exchange is initiated by the LURK 672 Client, the ticket_sessions are local_ticket and are only expected to 673 be used between the LURK Client and the LURK Server. Such 674 local_ticket avoids a direct communication of the 675 resumption_master_secret. local_ticket follows the definition of 676 new_session_tickets described in [I-D.ietf-tls-tls13] section 4.6.1. 677 The LURK Server MUST have a zero length ticket_nonce and zero length 678 extensions 680 When the LURK exchange is initiated by the TLS Server the tickets are 681 new_session_tickets as described in [I-D.ietf-tls-tls13] section 682 4.6.1. As a result: 684 o if handshake_mode is set to server, the LURK Server SHOULD respond 685 with a list of new_session_tickets that is not greater than the 686 number indicated by ticket_number. The number of ticket MAY be 687 defined by the LURK Server policies. 689 o if handshake_mode is set to client or post-handshake the LURK 690 Server SHOULD respond with a list of local_ticket that is not 691 greater than the number indicated by ticket_number. The list MUST 692 NOT exceed one local_ticket. 694 5. Security Considerations 696 6. IANA Considerations 697 7. Acknowledgments 699 8. Normative References 701 [I-D.ietf-tls-tls13] 702 Rescorla, E., "The Transport Layer Security (TLS) Protocol 703 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 704 March 2018. 706 [I-D.mglt-lurk-lurk] 707 Migault, D., "LURK Protocol version 1", draft-mglt-lurk- 708 lurk-00 (work in progress), February 2018. 710 [I-D.mglt-lurk-tls12] 711 Migault, D., "LURK Extension version 1 for (D)TLS 1.2 and 712 (D)TLS 1.1 Authentication", draft-mglt-lurk-tls12-00 (work 713 in progress), February 2018. 715 Author's Address 717 Daniel Migault 718 Ericsson 719 8275 Trans Canada Route 720 Saint Laurent, QC 4S 0B6 721 Canada 723 EMail: daniel.migault@ericsson.com