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