idnits 2.17.1 draft-mglt-lurk-lurk-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 530 has weird spacing: '...tension descr...' == Line 534 has weird spacing: '... type indic...' == Line 536 has weird spacing: '... status defin...' == Line 541 has weird spacing: '... id identif...' == Line 543 has weird spacing: '... length lengt...' == (2 more instances...) -- The document date (26 July 2021) is 998 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-TBD' is mentioned on line 851, but not defined -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LURK WG D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track 26 July 2021 5 Expires: 27 January 2022 7 LURK Protocol version 1 8 draft-mglt-lurk-lurk-01 10 Abstract 12 This document describes the Limited Usage of Remote Key (LURK) 13 Architecture, the LURK Protocol as well as the LURK Extensions that 14 enables remote interactions with cryptographic material. The 15 specificities of these interactions are expected to be closely tied 16 to some context and thus be defined in LURK Extensions. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 27 January 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 54 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. LURK Architecture . . . . . . . . . . . . . . . . . . . . 4 56 4.2. LURK Architecture and Hardware Security Module . . . . . 8 57 4.3. LURK Protocol and LURK extensions . . . . . . . . . . . . 9 58 5. LURK Header Processing . . . . . . . . . . . . . . . . . . . 10 59 5.1. LURK Header . . . . . . . . . . . . . . . . . . . . . . . 11 60 5.2. LURK Client Behavior . . . . . . . . . . . . . . . . . . 13 61 5.3. LURK Server Behavior . . . . . . . . . . . . . . . . . . 13 62 5.4. Error Message . . . . . . . . . . . . . . . . . . . . . . 14 63 6. LURK Request type . . . . . . . . . . . . . . . . . . . . . . 15 64 6.1. capabilities . . . . . . . . . . . . . . . . . . . . . . 15 65 6.1.1. Request Payload . . . . . . . . . . . . . . . . . . . 15 66 6.1.2. Response Payload . . . . . . . . . . . . . . . . . . 16 67 6.1.3. LURK Client Behavior . . . . . . . . . . . . . . . . 16 68 6.1.4. LURK Server Behavior . . . . . . . . . . . . . . . . 16 69 6.2. ping . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 6.2.1. Request Payload . . . . . . . . . . . . . . . . . . . 16 71 6.2.2. Response Payload . . . . . . . . . . . . . . . . . . 16 72 6.2.3. LURK Client Behavior . . . . . . . . . . . . . . . . 17 73 6.2.4. LURK Server Behavior . . . . . . . . . . . . . . . . 17 74 6.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 79 9.2. Informative References . . . . . . . . . . . . . . . . . 20 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 82 1. Requirements notation 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Introduction 90 The Limited Usage of Remote Key (LURK) Architecture enables services 91 to outsource the cryptographic related part of the service into a 92 dedicated Cryptographic Service. Isolation of the Cryptographic 93 Operations into a dedicated service is expected to enhance the 94 security of the Cryptographic Material for example by limiting the 95 boundaries to be controlled, by providing more control on its usage, 96 by limiting wide spreading the sensitive data, or by preventing 97 leakage in case of a software vulnerabilities [HEART] in the service, 98 or in case of cryptographic attacks. 100 For example, in large TLS deployment [I-D.mglt-lurk-tls-use-cases] 101 TLS servers both handle the networking operations and the 102 Cryptographic Operations. This often results in a large number of 103 nodes exposed to the Internet and hosting the necessary Cryptographic 104 Material. The LURK Architecture is expected to split these services 105 into two subservices: the networking service responsible for 106 terminating the sessions and a Cryptographic Service responsible for 107 Cryptographic Operations. The network service - designated as 108 Service Instance in the document - communicates with the 109 Cryptographic Service using the LURK Protocol and associated LURK 110 Extensions. Enabling remote access to the Cryptographic Service is 111 expected to prevent or reduce the distribution exposure to various 112 attacks of the Cryptographic Material. In addition, this favors the 113 use of hardware security enforcement as it limits the number of 114 hardware security modules that should be deployed. 116 This document defines the LURK Architecture as well as the LURK 117 Protocol. The LURK Protocol is expected to be a placeholder for LURK 118 Extensions, which are expected to specific to a given usage or 119 protocol. 121 3. Terminology and Acronyms 123 In addition to the terminology defined in 124 [I-D.mglt-lurk-tls-use-cases], this document introduces the following 125 terminology: 127 - LURK Architecture : The architecture that consists in using a 128 Cryptographic Service accessed by a Service Instance. 130 - Service Instance : A service that requires interacting with a 131 Cryptographic Service to perform its tasks. 133 - Cryptographic Service : A service dedicated to perform 134 Cryptographic Operations using a Cryptographic Material. 136 - Cryptographic Material : Is the highly sensitive material that is 137 used to perform the Cryptographic Operations. This is 138 typically a secret key. 140 - Cryptographic Operation : Operations based on the Cryptographic 141 Material. This typically includes some operations such as 142 encryption, decryption, signing. Note also that the 143 Cryptographic Operation are not limited to such operations, but 144 are expected to include additional operations performed either 145 on the input data or the output data. This makes such 146 operation service-dependent as opposed to a generic 147 cryptographic engine. 149 - LURK Protocol : The protocol that enables the communication 150 between a Service Instance and a Cryptographic Service. The 151 LURK Protocol is expected to be generic and the specificities 152 associated to the Cryptographic Service or the Service Instance 153 is expected to be addressed by a specific LURK Extension. 154 Exchanges between the Service Instance and the Cryptographic 155 Service is expected to be made via a LURK Client and a LURK 156 Server. 158 - LURK Extensions : The specifications of the Cryptographic Service 159 for a specific service or context. 161 - LURK Client : The entity sending LURK requests to the LURK Server. 162 In a TLS context, the LURK Client is expected to be hosted on 163 the Edge Server. 165 - LURK Server : The entity receiving LURK request from the LURK 166 Client and responding to those requests. In a TLS context, the 167 LURK Server is expected to be hosted on the Key Server. 169 4. Overview 171 4.1. LURK Architecture 173 The LURK Architecture depicted in Figure 1 shows multiple Service 174 Instances remotely accessing a Cryptographic Service. The two 175 services communicate via a LURK Client and a LURK Server, using the 176 LURK Protocol and an appropriated LURK Extensions. The LURK Protocol 177 is a place holder for LURK Extensions that are expected to fit the 178 needs associated to a specific context, a specific Service Instance 179 and a specific Cryptographic Service. For example 180 [I-D.mglt-lurk-tls] defines the interactions by a service terminating 181 TLS 1.2 session and a Cryptographic Service that is responsible for 182 the associated Cryptographic operations. 184 When the Service Instance requires Cryptographic Operations to be 185 performed, the LURK Client sends a request with associated inputs to 186 the LURK Server of the Cryptographic Service. Upon receiving a query 187 the Cryptographic Service may process the received input to format 188 appropriately the material for a low level cryptographic operations 189 such as signing, encrypting, decrypting. Such processing is 190 designated as LURK Server Cryptographic Operations in Figure 1. 191 Additional operations may be added to the low level cryptographic 192 operations before responding to the LURK Client. 194 The LURK Architecture improves the security associated to the 195 Cryptographic Material by limiting its dissemination and improving 196 the control of the its usage. 198 The communications between the LURK Client and the LURK Server are 199 expected to be authenticated and encrypted with TLS or IPsec due to 200 the expected sensitivity of the information exchanged. 202 LURK Protocol + 203 LURK Extensions 204 <-------------> 205 +---------------------+ +-----------------------------+ 206 | Service Instance | | Cryptographic Service | 207 +------------+--------+ +-------------+---------------+ 208 | | | | | | 209 | Service | LURK |<------------->| LURK Server | LURK Server | 210 | processing | Client | +------->| Interface | Cryptographic | 211 | | | | | | Operations | 212 +------------+--------+ | | | | 213 ... | | | Cryptographic | 214 | | | Material | 215 +---------------------+ | | | (private key) | 216 | Service Instance | | | | | 217 +------------+--------+ | +-------------+---------------+ 218 | | | | 219 | Service | LURK |<-----+ 220 | processing | Client | 221 | | | 222 +------------+--------+ 224 Figure 1: LURK Architecture 226 The remaining of this section intends to provide a high level 227 overview of the pros and cons provided by the LURK Architecture. 229 The LURK Architecture is expected to provide the following advantage: 231 1. Limit exposure of the Cryptographic Material. While the Service 232 Instances could be exposed, for example to the Internet, the 233 Cryptographic Material remains in the core network accessed by 234 authenticated Service Instances. 236 2. Limit the usage of the Cryptographic Material. When a corrupted 237 Service Instance hosts the Cryptographic Material, that node may 238 almost have a full access to the Cryptographic Material, and thus 239 limited restrictions on its usage. With the LURK Architecture, a 240 corrupted Service Instance may still access the Cryptographic 241 Service, but the usage of the Cryptographic Service will remain 242 in the scope of the legitimate usage. It is expected that LURK 243 Extensions reduces the usability of the usage to reduce the 244 interest for an attacker. This includes, among others, perfect 245 froward secrecy mechanisms as well as obscuring the cryptographic 246 output, binding the output to a specific protocol, and protocol 247 version.... 249 3. Limit information of the Cryptographic Material leakage when 250 Cryptographic Operations are performed. The LURK Extension 251 defines the input and outputs exchanged between the LURK Client 252 and the LURK Server. These input / output can be processed by 253 the LURK Server, which can be used to obfuscate the input / 254 output provided to and received by the Cryptographic Operation. 255 Such obfuscation can be used to make cryptographic attacks or 256 using the Cryptographic Material outside a legitimate context 257 harder and are expected to be enforced by the LURK Extension. 259 4. Provide Perfect Forward Secrecy when it is not naturally being 260 provided by the Service Instance. The LURK Extension can be 261 defined in order to prevent an observer to derive the exchanged 262 between the LURK Client and the LURK Server from the input / 263 output messages exchanged by the Service Instance. This 264 prevents, for example, an attacker to replay the exchange from 265 the LURK Client and the LURK Server and thus replay the exchange. 267 5. Improve the monitoring of the Cryptographic Material usage. 268 Sharing the Cryptographic Material with multiple nodes is an 269 efficient way to delegate and distribute an operation. On the 270 other hand, such delegation also makes harder the control of the 271 usage of the Cryptographic Material. Local monitoring of a node 272 is not sufficient and may not provide the appropriated indication 273 to detect an ongoing attack. Aggregation and analysis of the 274 logs is a difficult task and likely not to be performed in most 275 environments. The LURK Architecture by design centralizes such 276 monitoring making it easier and more efficient. 278 6. Limit the risks of leakage of the Cryptographic Material. By 279 centralizing the Cryptographic Material to one or a reduce set of 280 the Cryptographic Services, the LURK Architecture prevents the 281 Cryptographic Material to be disseminated within a data center 282 with numerous replicate of that confidential data. In addition, 283 the reduced number of instances of Cryptographic Service makes it 284 economically feasible to deploy hardware security. 286 7. Enable collaboration between actors by slicing the services. 287 Typically, the owner of the Cryptographic Material can delegate 288 the Service Instance while not sharing the Cryptographic 289 Material. This ease collaboration as the Service Instance 290 provider is not associated with risks of leaking the 291 Cryptographic Material and the owner of the Cryptographic 292 Material can initiate such collaboration without compromising the 293 secrecy of the Cryptographic Material. 295 8. Improve the control of the ownership of the Cryptographic 296 Material to a per-operation level. Shared Cryptographic Material 297 has only a time limitation until the agreement expires and is 298 renewed. This means that before expiration time, the owner of 299 the Cryptographic Material literally gives up its control. The 300 LURK Architecture, instead, enables the owner to prevent any 301 Service Instance at any time to serve as or on behalf of the 302 owner of the Cryptographic Material. 304 On the other hand, the LURK Architecture also comes with some 305 drawbacks and challenges: 307 1. Latency introduced by the communication between the LURK Client 308 and the LURK Server. In some cases, the latency may not be 309 acceptable, which may impose the presence of a more site local 310 instance of Cryptographic Service in order to reduce the latency. 311 This may be problematic, to establish highly dynamic 312 collaboration without a secure and trusted mechanism to provision 313 the Cryptographic Service in another domain. Note that sharing 314 the Cryptographic Service local remains safer than sharing the 315 Cryptographic Material, and sharing a Cryptographic Service 316 between different domain may be associated to a lower trust into 317 the involved parties. 319 2. Centralizing Cryptographic Operation may provide a bottleneck 320 vulnerability, both in term of computing resource available to 321 the Cryptographic Service as well as to bandwidth necessary for 322 the communication between the LURK Client and the LURK Server. 323 The use of authenticated Service Instances limits the risk of a 324 resource exhaustion attack on the Cryptographic Service. In 325 fact, the Cryptographic Service is expected to be provisioned in 326 order to serve the expected demand from Service Instances. On 327 the other hand, if that would happen, scaling the computing 328 resource may be relatively easy regarding the limited scope of 329 the Cryptographic Service. That said, maintaining an available 330 channel between distinct networks may be a harder challenge that 331 may require placing the Cryptographic Service at multiple 332 locations. In case this is not feasible, or the associated cost 333 are too high other mechanisms should be used such as the use of 334 short term certificate [I-D.sheffer-acme-star-request], [RFC8739] 335 or delegated credentials for TLS [I-D.rescorla-tls-subcerts]. 337 3. Cryptographic operations are performed isolated from their 338 context which prevents the distinction between a legitimate 339 request performed in the scope of a Service Instance operation 340 from a request that is part of an attack performed by a rogue 341 Service Instance or a rogue LURK Client outside a Service 342 Instance. Typically, in the case of TLS, a legitimate context 343 would include the establishment of a TLS session. This issue may 344 be mitigated with authenticated and trusted Service Instances, a 345 limitation of the Cryptographic Material usage outside the scope 346 of a legitimate use as well as avoiding leaking information 347 related to the Cryptographic Material. Protection against such 348 usage is expected to be provided by the design of the LURK 349 Extension. 351 4.2. LURK Architecture and Hardware Security Module 353 The primary purpose of an Hardware Security Module (HSM) is to 354 prevent tampering the Cryptographic Material. In most of the cases, 355 HSM provides a generic PKCS11 cryptographic interface instead of a 356 interface specific to a Service Instance. In addition, PKCS11 does 357 not provide remote access facilities and rely on proprietary 358 protocols which does not for example favor interoperability between 359 different service providers. 361 The LURK Architecture is not incompatible with the use of an HSM. 362 Typically the HSM can be used by the Cryptographic Service in order 363 to protect the Cryptographic Material as depicted in Figure 2. Low 364 level cryptographic operations are performed by the HSM, the LURK 365 Server Processing is intended to perform additional operation in 366 order to match the expected format defined by the LURK Protocol and 367 LURK Extensions. The combination of the LURK Architecture and the 368 HSM provides the following advantages: 370 * The HSM benefits from LURK Protocol and LURK Extensions as a 371 standard way to remotely access the HSM. As a consequence, the 372 LURK Architecture enables the resource of an HSM to be shared, 373 which presents some significant saving costs. 375 * The HSM benefits from the protection provided by the LURK 376 Extension that limits usage as well disclosure of the input / 377 output provided to the HSM. 379 * The Cryptographic Service benefits from the hardware security 380 provided by the HSM. 382 * The Cryptographic Service provides an interface dedicated and more 383 intuitive to the Service Instance that the PKCS11 generic 384 interface. 386 +-------------------------------------------------+ 387 | Cryptographic Service | 388 +--------------+---------------+------------------+ 389 | | | HSM | 390 | LURK Server | LURK Server PKCS11 Cryptographic | 391 | Interface | processing <---> Material | 392 | | | (private key) | 393 | | | | 394 +--------------+---------------+------------------+ 396 Figure 2: Cryptographic Function with HSM 398 4.3. LURK Protocol and LURK extensions 400 The purpose of the LURK Protocol and the LURK Extensions is to 401 provide an interfaces between a Service Instance and a Cryptographic 402 Service. The number of Cryptographic Service is expected to evolve 403 over time and these requirements are expected to be fulfilled by a 404 specific LURK Extension, while the LURK Protocol is designed as a 405 placeholder for these LURK Extensions. 407 As a placeholder for LURK Extensions, the main functionality of the 408 LURK Protocol is to steer requests from the LURK Client to the 409 appropriated LURK Extension, and then steer back the response to the 410 LURK Client. Such interactions define exchanges when the request 411 cannot be handled by the LURK Extension as well as when the LURK 412 Extension is not enabled on the LURK Server. This is expected to 413 ease the development of future LURK Extensions limited to specific 414 operations requested by the LURK Client. 416 In addition, the LURK Protocol is also expected to enable a very 417 limited and generic set of interactions between the LURK Client and 418 the LURK Server. These interactions are typically defined by 419 operations requested by the LURK Client, and this document defines 420 two type of requests. A request of type capabilities request defined 421 in Section 6.1 that enables the LURK Client to discover the supported 422 LURK Extensions of the LURK Server. In addition, a request of type 423 ping defined in Section 6.2 enables connectivity check. These 424 interactions are considered as part of the LURK Protocol but could 425 also be seen as a specific LURK Extension: the "lurk" LURK Extension. 426 This document treats both the LURK Extension "lurk" as the LURK 427 Protocol. The distinction is expected to be implementation 428 dependent. 430 Figure 3 describes how the LURK Protocol and the LURK Extensions 431 interacts each others. When the LURK Client interacts with a LURK 432 Server, it is expected to designates the specific Cryptographic 433 Operation to be performed within the designated LURK Extension as 434 well as the necessary parameters for the extension to perform its 435 operation. Upon performing the Cryptographic Operation, the LURK 436 Extension returns the output of the operation with an return code. 437 These output are handled by the LURK Protocol and returned to the 438 LURK Client. 440 +--------------------------------------------------+ 441 | LURK Server | 442 +----------------+----------------+----------------+ 443 | | | | 444 | LURK Extension | LURK Extension | LURK Extension | 445 | (A) | (B) | (C) | 446 | | | | 447 +--------------------------------------------------+ 448 | | 449 | LURK Protocol | 450 | | 451 +--------------------------------------------------+ 453 Figure 3: LURK Protocol and LURK Extension 455 Messages exchanged between the LURK Client and the LURK Server are 456 composed of a LURK Header and LURK Payload as depicted in Figure 4. 457 The LURK Extensions are designed to process the LURK Payloads - 458 eventually void -, while the LURK Header contains the necessary 459 information for the LURK Server to steer the LURK Payload to the 460 appropriated LURK Extension. In that sense, the LURK Protocol could 461 be interpreted as the processing of the LURK Header while the LURK 462 Extension 'lurk' is processing the (void) LURK Payloads. This 463 document treats both the LURK Extension 'lurk' as the LURK Protocol. 465 +----------------------------------+ 466 | | 467 | LURK Header | 468 | | 469 +----------------------------------+ 470 | | 471 | LURK Payload | 472 | | 473 +----------------------------------+ 475 Figure 4: LURK Message Description 477 5. LURK Header Processing 479 As detailed in Section 4.3, upon receiving an request from the LURK 480 Client, the LURK Protocol may: 482 * Respond directly if the request is associated to the LURK 483 Protocol. 485 * Proxy the request to the appropriated LURK Extension when 486 supported. 488 * Respond to with an error. 490 This section treats the two latest aspects while Section 6 describes 491 the requests specific to the LURK Protocol. 493 5.1. LURK Header 495 The LURK Header structure is as follows: 497 enum { 498 lurk (0), (255) 499 } Designation; 501 enum { 502 request (0), success (1), undefined_error (2), 503 invalid_format (3), invalid_extension (4), invalid_type (5), 504 invalid_status (6), temporary_failure (6), (255) 505 } LURKStatus 507 enum { 508 capabilities (0), ping (1), (255) 509 } LURKType; 511 struct { 512 Designation designation = "lurk"; 513 int8 version = 1; 514 } Extension; 516 struct { 517 Extension extension; 518 select( Extension ){ 519 case ("lurk", 1): 520 LURKType; 521 } type; 522 select( Extension ){ 523 case ("lurk", 1): 524 LURKStatus; 525 } status; 526 uint64 id; 527 unint32 length; 528 } LURKHeader; 530 extension describes the LURK Protocol. In this document the 531 extension is defined with designation set to "lurk" and version is 532 set to 1. 534 type indicates the type of the request associated to the extension. 536 status defines if the message is a request or a response. When the 537 message is a response, the status indicates if the request has 538 been processed correctly and if not the status indicates the 539 associated error. 541 id identifies the exchange. 543 length length of the entire message, including header, in bytes. 545 5.2. LURK Client Behavior 547 The LURK Client is only able to send requests and MUST set the status 548 header field to "request". The extension (designation, version) and 549 the type characterizes the request. The id is expected to be 550 unpredictable and SHOULD be randomly generated. The length is 551 computed once the LURK Payload has been inserted and includes the 552 number of bytes of the LURK Header as well as those of the LURK 553 Payload. 555 Upon receiving a message, the LURK Client checks: 557 1. The message id matches a request previously sent and discards the 558 message otherwise. 560 2. The message status indicates a response, i.e. with a status 561 different from "request" and discards the message otherwise. 563 1. A status set to "success" indicates, the request has been 564 properly processed by the LURK Server. In this case, the 565 extension, type and id field of the response MUST match those 566 of the request. The LURK Client is expected to process the 567 LURK Payload. 569 2. A status reporting an error - i.e. that differs from 570 "request" and "success" reports an error. The LURK Client 571 SHOULD be able to handle such errors and SHOULD be able to 572 log them for further analysis. In addition, some errors may 573 trigger some specific behavior such as discovering the 574 capabilities of the LURK Server. 576 5.3. LURK Server Behavior 578 Upon receiving a message the LURK Server checks 580 1. The message extension is supported. When the extension is not 581 supported, the LURK Server SHOULD respond with an 582 "invalid_extension" error. 584 2. The message status is set to "request". When the status differs 585 from "request", the LURK Server SHOULD respond with an 586 "invalid_status" error. 588 3. The message type is supported. The message type is associated to 589 the extension. When the message type is not supported the LURK 590 Server SHOULD respond with an "invalid_type" error. 592 Once the message header has been validated, the LURK Payload is 593 extracted to be processed by the appropriated extension. If any 594 error occurs before the LURK Payload can be steered to the extension, 595 the LURK Server SHOULD respond with an "invalid_format" or 596 "undefined_error". 598 When overloaded, the LURK Server SHOULD send a "temporary_failure" 599 error to indicate its inability to treat the request. 601 When an error is returned before the LURK Payload is being processed, 602 the LURK Server sets the extension to "lurk". When multiple versions 603 are served, and match the error, the LURK Server SHOULD set the 604 version to a version known to be supported by the LURK Client. When 605 this information is not available, the LURK Server SHOULD chose the 606 minimum supported value. The status is set to the error code, the 607 type and id are copied from the request and the length is computed 608 according to the ErrorPayload. 610 Once the LURK header has been validated, the LURK Server is able to 611 request the treatment of the LURK Payload to a specific operation to 612 the appropriated LURK Extension identified by (extension, type). In 613 return, the LURK Extension is expected to returns the corresponding 614 response LURK Payload, and eventually an error code. 616 1. When no error code is returned, the LURK Server returns a LURK 617 Header copying the extension, the type and id from the request. 618 The status is is set to "success" and the length is computed from 619 the LURK Payload returned by the LURK Extension or the LURK 620 Protocol. The LURK Payload is happened to the LURK Header before 621 being sent back to the LURK Client. 623 2. When an error code is returned, the LURK Server returns a LURK 624 Header copying the extension, the type and the id from the 625 request. The status is set to the returned error code, and the 626 length is computed from the returned LURK Payload. The LURK 627 Payload is happened to the LURK Header before being sent back to 628 the LURK Client. 630 The LURK Server SHOULD return error message when possible to inform 631 the LURK Client on the reasons the exchange fails. However, in some 632 cases, the LURK Server MAY discard the request without returning the 633 error. 635 5.4. Error Message 637 The error code is indicated by the status when its value differs from 638 "request" or "success". 640 Error message MAY have no Payload. Error message MAY also carry a 641 state value that indicates a change in the configuration of the LURK 642 Server. The state is expected to reflect any change of the 643 configuration associated to the extension. Generation of the state 644 is implementation dependent and out of the scope of this document. 645 It can typically be implemented as a counter that is incremented any 646 time the extension configuration is updated, or as the hash function 647 of the configuration file. 649 Upon reception of the state, if the LURK Client has stored the 650 previous value, it is expected to compare the two values. A mismatch 651 indicates that extension configuration change and the LURK Client 652 SHOULD perform some capability discoveries. If the two values match 653 an capability discovery SHOULD NOT be performed. The absence of 654 ErrorPayload is considered as a mismatch. 656 struct { 657 opaque lurk_state<32> ; 658 }ErrorPayload; 660 Figure 5: Error Payload Description 662 6. LURK Request type 664 While Section 5 details how the LURK Protocol steers a request from 665 the LURK Client to an appropriated LURK Extension, this section 666 details the specific requests associated to the LURK Protocol that 667 can be initiated by the LURK Client. As exposed in Section 4.3, this 668 section could be seen as a LURK Extension 'lurk'. However this 669 document does not makes such distinction and the LURK Extension 670 'lurk' and the LURK Protocol are considered as the same. 672 The LURK Protocol provides some basic reachability and discovery 673 interactions between LURK Client and LURK Servers. 675 The LURK Header is expected to have the extension's designation set 676 to "lurk" and the extension's version set to 1. The type of the 677 exchange is indicated by the type field. 679 6.1. capabilities 681 6.1.1. Request Payload 683 A LURK "capabilities" request has no payload. 685 6.1.2. Response Payload 687 The "capabilities" response payload consists in a list of the 688 supported Extensions structures. 690 struct { 691 LURKSupportedExtension supported_extensions_list<2..2^16-2>; 692 LURKSupportedType supported_type<2..2^16-2>; 693 opaque lurk_state<32>; 694 }LURKCapabilitiesResponsePayload; 696 Figure 6: LURK Capability Payload Description 698 supported_extensions_list is the concatenation of all supported 699 extensions by the LURK Server. The possible values for the 700 extensions are defined in Section 5.1. 702 supported_type_list is the concatenation of all supported type by 703 the LURK Server. The possible values for the extensions are 704 defined in Section 5.1. 706 lurk_state This value defined in Section 5.4is returned in error 707 messages as to indicate whether the configuration has been updated 708 and if a new LURK capability request needs to be sent. 710 6.1.3. LURK Client Behavior 712 The LURK Client sends a "capabilities" request in a "lurk" extension 713 to discover the various extensions and versions supported by the LURK 714 Server. 716 6.1.4. LURK Server Behavior 718 The LURK Server lists the supported extensions and version the 719 requester is authorized to request and sends the response. 721 6.2. ping 723 6.2.1. Request Payload 725 A LURK "ping" request has no payload. 727 6.2.2. Response Payload 729 A LURK "ping" response has no payload. 731 6.2.3. LURK Client Behavior 733 The LURK Client sends a "ping" request to test the reachability of 734 the LURK Server. The reachability is performed within a LURK 735 relation. 737 6.2.4. LURK Server Behavior 739 The LURK Server sends the corresponding response. 741 6.3. Errors 743 A LURK Server MAY raise a "invalid_payload_format" or a 744 "undefined_error" if for example a unexpected payload is provided. 746 7. Security Considerations 748 This document has provided a security analysis of the LURK 749 Architecture. 751 LURK message can be carried over UDP, and some responses MAY present 752 significant larger response payloads than the request payloads. The 753 messages responded by the LURK Protocol can be be a capabilities 754 response, a ping response or an error. The ping response does not 755 represent any size message increase. An error response MAY carry an 756 error payload of 32 bits that represents the state. Such increase 757 does not seems sufficient to motivate amplification attacks, and the 758 payload MAY be omitted. The capabilities responses carry a payload 759 whose size increases with the number of supported LURK Extension and 760 version. Similarly, the number of LURK Extension supported by a 761 Cryptographic Service is expected to remain quite low, and as such 762 the additional size is not expected to represent a significant 763 threat. 765 While the LURK Protocol does not provide a significant packet size 766 increase, the LURK Protocol may be used carry response payloads 767 associated to a LURK Extension, and as such, the applicator factor 768 associated to each supported LURK Extension MUST be considered. 770 The LURK Protocol does not define any mechanisms to authenticate the 771 LURK Client and the LURK Server nor to protect the data channel 772 between the LURK Client and the LURK Server. It is RECOMMENDED to 773 protect LURK exchanges by protecting the communication between the 774 LURK Client and the LURK Server using for example IPsec [RFC4301], 775 TLS 1.2 [RFC5246], TLS 1.3 [RFC8446] DTLS 1.2 [RFC6347] or DTLS !.3 776 [I-D.ietf-tls-dtls13]. 778 The information exchanged between in the scope of the LURK Protocol 779 may not be considered as confidential. As such exchanges between the 780 LURK Client and the LURK Server may not need to be encrypted. A ping 781 exchange reveals the reachability and the potential scope of the 782 exchange between the two peers. The capabilities exchange reveals 783 the observer the extensions enabled by the LURK Server. This may 784 provide information relative to the function of the LURK Server and 785 the LURK Client. 787 As the LURK Protocol is a place holder for LURK Extension, the 788 confidentiality of the information depends on the LURK Extension 789 enabled. By default, It is RECOMMENDED to encrypt the LURK 790 exchanges. 792 The LURK Server can enable multiple LURK Extensions, serve multiple 793 LURK Clients as well as serve multiple Cryptographic Material. In 794 order to increase the protection boundaries, it is expected to limit 795 the scope of a LURK Server. It is RECOMMENDED to limit the scope of 796 the LURK Server to a limited number of Cryptographic Material. As 797 Cryptographic Material is expected to have a limited scope, it is 798 then expected and RECOMMENDED that the LURK Server enables a limited 799 number of LURK Extensions. In addition, it is also RECOMMENDED that 800 the enabled LURK Extension be appropriately configured to provide 801 only the necessary functionalities. 803 8. IANA Considerations 805 The LURK Protocol and LURK Extension requires the following 806 parameters to be registered by the IANA. 808 LURK Extension Designation 810 Value Designation Reference Description 811 ------------------------------------------------- 812 0 lurk [RFC-TBD] LURK Protocol 813 1-255 UNASSIGNED 815 LURK Protocol Status 817 Value Description Reference 818 ----------------------------------------------------- 819 0 request [RFC-TBD] 820 1 success [RFC-TBD] 821 2 undefined_error [RFC-TBD] 822 3 invalid_format [RFC-TBD] 823 4 invalid_extension [RFC-TBD] 824 5 invalid_type [RFC-TBD] 825 6 invalid_status [RFC-TBD] 826 7 temporary_failure [RFC-TBD] 827 8-255 UNASSIGNED 829 LURK Protocol Type 831 Value Description Reference 832 ---------------------------------------------- 833 0 capabilities [RFC-TBD] 834 1 ping [RFC-TBD] 835 3-255 UNASSIGNED 837 When a new LURK Extension is created, the designation of the LURK 838 Extension, the associated status and type MUST be provided. The 839 status values 0 to 1 are reserved and cannot be assigned with 840 different meanings. As a result, the template for future LURK 841 extension is defined as follows: 843 LURK Extension Designation: 844 LURK Extension Reference: 845 LURK Extension Description: 847 LURK Extension Status 849 Value Description Reference 850 ------------------------------------------- 851 0-1 RESERVED [RFC-TBD] 853 LURK Extension Type 855 Value Description Reference 856 ---------------------------------------------- 858 Registration of LURK Designation for code points 0-127 requires 859 Standard Track, while other code points are RFC Required [RFC8126]. 861 9. References 863 9.1. Normative References 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, 867 DOI 10.17487/RFC2119, March 1997, 868 . 870 9.2. Informative References 872 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 873 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 874 December 2005, . 876 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 877 (TLS) Protocol Version 1.2", RFC 5246, 878 DOI 10.17487/RFC5246, August 2008, 879 . 881 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 882 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 883 . 885 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 886 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 887 January 2012, . 889 [I-D.ietf-tls-dtls13] 890 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 891 Datagram Transport Layer Security (DTLS) Protocol Version 892 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 893 dtls13-43, 30 April 2021, . 896 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 897 Writing an IANA Considerations Section in RFCs", BCP 26, 898 RFC 8126, DOI 10.17487/RFC8126, June 2017, 899 . 901 [I-D.mglt-lurk-tls-use-cases] 902 Migault, D., J, K. M., Salz, R., Mishra, S., and O. G. D. 903 Dios, "LURK TLS/DTLS Use Cases", Work in Progress, 904 Internet-Draft, draft-mglt-lurk-tls-use-cases-02, 28 June 905 2016, . 908 [I-D.mglt-lurk-tls] 909 Migault, D., "LURK Protocol for TLS/DTLS1.2 version 1.0", 910 Work in Progress, Internet-Draft, draft-mglt-lurk-tls-01, 911 11 March 2017, . 914 [I-D.rescorla-tls-subcerts] 915 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 916 "Delegated Credentials for TLS", Work in Progress, 917 Internet-Draft, draft-rescorla-tls-subcerts-02, 30 October 918 2017, . 921 [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor 922 Perales, A., and T. Fossati, "Support for Short-Term, 923 Automatically Renewed (STAR) Certificates in the Automated 924 Certificate Management Environment (ACME)", RFC 8739, 925 DOI 10.17487/RFC8739, March 2020, 926 . 928 [I-D.sheffer-acme-star-request] 929 Sheffer, Y., Lopez, D., Dios, O. G. D., Perales, A. A. P., 930 and T. Fossati, "Generating Certificate Requests for 931 Short-Term, Automatically-Renewed (STAR) Certificates", 932 Work in Progress, Internet-Draft, draft-sheffer-acme-star- 933 request-02, 29 June 2018, 934 . 937 [HEART] Codenomicon, "The Heartbleed Bug", 938 . 940 Author's Address 942 Daniel Migault 943 Ericsson 944 8400 boulevard Decarie 945 Montreal, QC H4P 2N2 946 Canada 948 Phone: +1 514-452-2160 949 Email: daniel.migault@ericsson.com