Internet DRAFT - draft-mglt-lurk-lurk
draft-mglt-lurk-lurk
LURK WG D. Migault
Internet-Draft Ericsson
Intended status: Standards Track 26 July 2021
Expires: 27 January 2022
LURK Protocol version 1
draft-mglt-lurk-lurk-01
Abstract
This document describes the Limited Usage of Remote Key (LURK)
Architecture, the LURK Protocol as well as the LURK Extensions that
enables remote interactions with cryptographic material. The
specificities of these interactions are expected to be closely tied
to some context and thus be defined in LURK Extensions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 January 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Migault Expires 27 January 2022 [Page 1]
Internet-Draft LURK TLS July 2021
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. LURK Architecture . . . . . . . . . . . . . . . . . . . . 4
4.2. LURK Architecture and Hardware Security Module . . . . . 8
4.3. LURK Protocol and LURK extensions . . . . . . . . . . . . 9
5. LURK Header Processing . . . . . . . . . . . . . . . . . . . 10
5.1. LURK Header . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. LURK Client Behavior . . . . . . . . . . . . . . . . . . 13
5.3. LURK Server Behavior . . . . . . . . . . . . . . . . . . 13
5.4. Error Message . . . . . . . . . . . . . . . . . . . . . . 14
6. LURK Request type . . . . . . . . . . . . . . . . . . . . . . 15
6.1. capabilities . . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Request Payload . . . . . . . . . . . . . . . . . . . 15
6.1.2. Response Payload . . . . . . . . . . . . . . . . . . 16
6.1.3. LURK Client Behavior . . . . . . . . . . . . . . . . 16
6.1.4. LURK Server Behavior . . . . . . . . . . . . . . . . 16
6.2. ping . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.1. Request Payload . . . . . . . . . . . . . . . . . . . 16
6.2.2. Response Payload . . . . . . . . . . . . . . . . . . 16
6.2.3. LURK Client Behavior . . . . . . . . . . . . . . . . 17
6.2.4. LURK Server Behavior . . . . . . . . . . . . . . . . 17
6.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
The Limited Usage of Remote Key (LURK) Architecture enables services
to outsource the cryptographic related part of the service into a
dedicated Cryptographic Service. Isolation of the Cryptographic
Operations into a dedicated service is expected to enhance the
security of the Cryptographic Material for example by limiting the
boundaries to be controlled, by providing more control on its usage,
by limiting wide spreading the sensitive data, or by preventing
Migault Expires 27 January 2022 [Page 2]
Internet-Draft LURK TLS July 2021
leakage in case of a software vulnerabilities [HEART] in the service,
or in case of cryptographic attacks.
For example, in large TLS deployment [I-D.mglt-lurk-tls-use-cases]
TLS servers both handle the networking operations and the
Cryptographic Operations. This often results in a large number of
nodes exposed to the Internet and hosting the necessary Cryptographic
Material. The LURK Architecture is expected to split these services
into two subservices: the networking service responsible for
terminating the sessions and a Cryptographic Service responsible for
Cryptographic Operations. The network service - designated as
Service Instance in the document - communicates with the
Cryptographic Service using the LURK Protocol and associated LURK
Extensions. Enabling remote access to the Cryptographic Service is
expected to prevent or reduce the distribution exposure to various
attacks of the Cryptographic Material. In addition, this favors the
use of hardware security enforcement as it limits the number of
hardware security modules that should be deployed.
This document defines the LURK Architecture as well as the LURK
Protocol. The LURK Protocol is expected to be a placeholder for LURK
Extensions, which are expected to specific to a given usage or
protocol.
3. Terminology and Acronyms
In addition to the terminology defined in
[I-D.mglt-lurk-tls-use-cases], this document introduces the following
terminology:
- LURK Architecture : The architecture that consists in using a
Cryptographic Service accessed by a Service Instance.
- Service Instance : A service that requires interacting with a
Cryptographic Service to perform its tasks.
- Cryptographic Service : A service dedicated to perform
Cryptographic Operations using a Cryptographic Material.
- Cryptographic Material : Is the highly sensitive material that is
used to perform the Cryptographic Operations. This is
typically a secret key.
- Cryptographic Operation : Operations based on the Cryptographic
Material. This typically includes some operations such as
encryption, decryption, signing. Note also that the
Cryptographic Operation are not limited to such operations, but
are expected to include additional operations performed either
Migault Expires 27 January 2022 [Page 3]
Internet-Draft LURK TLS July 2021
on the input data or the output data. This makes such
operation service-dependent as opposed to a generic
cryptographic engine.
- LURK Protocol : The protocol that enables the communication
between a Service Instance and a Cryptographic Service. The
LURK Protocol is expected to be generic and the specificities
associated to the Cryptographic Service or the Service Instance
is expected to be addressed by a specific LURK Extension.
Exchanges between the Service Instance and the Cryptographic
Service is expected to be made via a LURK Client and a LURK
Server.
- LURK Extensions : The specifications of the Cryptographic Service
for a specific service or context.
- LURK Client : The entity sending LURK requests to the LURK Server.
In a TLS context, the LURK Client is expected to be hosted on
the Edge Server.
- LURK Server : The entity receiving LURK request from the LURK
Client and responding to those requests. In a TLS context, the
LURK Server is expected to be hosted on the Key Server.
4. Overview
4.1. LURK Architecture
The LURK Architecture depicted in Figure 1 shows multiple Service
Instances remotely accessing a Cryptographic Service. The two
services communicate via a LURK Client and a LURK Server, using the
LURK Protocol and an appropriated LURK Extensions. The LURK Protocol
is a place holder for LURK Extensions that are expected to fit the
needs associated to a specific context, a specific Service Instance
and a specific Cryptographic Service. For example
[I-D.mglt-lurk-tls] defines the interactions by a service terminating
TLS 1.2 session and a Cryptographic Service that is responsible for
the associated Cryptographic operations.
When the Service Instance requires Cryptographic Operations to be
performed, the LURK Client sends a request with associated inputs to
the LURK Server of the Cryptographic Service. Upon receiving a query
the Cryptographic Service may process the received input to format
appropriately the material for a low level cryptographic operations
such as signing, encrypting, decrypting. Such processing is
designated as LURK Server Cryptographic Operations in Figure 1.
Additional operations may be added to the low level cryptographic
operations before responding to the LURK Client.
Migault Expires 27 January 2022 [Page 4]
Internet-Draft LURK TLS July 2021
The LURK Architecture improves the security associated to the
Cryptographic Material by limiting its dissemination and improving
the control of the its usage.
The communications between the LURK Client and the LURK Server are
expected to be authenticated and encrypted with TLS or IPsec due to
the expected sensitivity of the information exchanged.
LURK Protocol +
LURK Extensions
<------------->
+---------------------+ +-----------------------------+
| Service Instance | | Cryptographic Service |
+------------+--------+ +-------------+---------------+
| | | | | |
| Service | LURK |<------------->| LURK Server | LURK Server |
| processing | Client | +------->| Interface | Cryptographic |
| | | | | | Operations |
+------------+--------+ | | | |
... | | | Cryptographic |
| | | Material |
+---------------------+ | | | (private key) |
| Service Instance | | | | |
+------------+--------+ | +-------------+---------------+
| | | |
| Service | LURK |<-----+
| processing | Client |
| | |
+------------+--------+
Figure 1: LURK Architecture
The remaining of this section intends to provide a high level
overview of the pros and cons provided by the LURK Architecture.
The LURK Architecture is expected to provide the following advantage:
1. Limit exposure of the Cryptographic Material. While the Service
Instances could be exposed, for example to the Internet, the
Cryptographic Material remains in the core network accessed by
authenticated Service Instances.
2. Limit the usage of the Cryptographic Material. When a corrupted
Service Instance hosts the Cryptographic Material, that node may
almost have a full access to the Cryptographic Material, and thus
limited restrictions on its usage. With the LURK Architecture, a
corrupted Service Instance may still access the Cryptographic
Service, but the usage of the Cryptographic Service will remain
Migault Expires 27 January 2022 [Page 5]
Internet-Draft LURK TLS July 2021
in the scope of the legitimate usage. It is expected that LURK
Extensions reduces the usability of the usage to reduce the
interest for an attacker. This includes, among others, perfect
froward secrecy mechanisms as well as obscuring the cryptographic
output, binding the output to a specific protocol, and protocol
version....
3. Limit information of the Cryptographic Material leakage when
Cryptographic Operations are performed. The LURK Extension
defines the input and outputs exchanged between the LURK Client
and the LURK Server. These input / output can be processed by
the LURK Server, which can be used to obfuscate the input /
output provided to and received by the Cryptographic Operation.
Such obfuscation can be used to make cryptographic attacks or
using the Cryptographic Material outside a legitimate context
harder and are expected to be enforced by the LURK Extension.
4. Provide Perfect Forward Secrecy when it is not naturally being
provided by the Service Instance. The LURK Extension can be
defined in order to prevent an observer to derive the exchanged
between the LURK Client and the LURK Server from the input /
output messages exchanged by the Service Instance. This
prevents, for example, an attacker to replay the exchange from
the LURK Client and the LURK Server and thus replay the exchange.
5. Improve the monitoring of the Cryptographic Material usage.
Sharing the Cryptographic Material with multiple nodes is an
efficient way to delegate and distribute an operation. On the
other hand, such delegation also makes harder the control of the
usage of the Cryptographic Material. Local monitoring of a node
is not sufficient and may not provide the appropriated indication
to detect an ongoing attack. Aggregation and analysis of the
logs is a difficult task and likely not to be performed in most
environments. The LURK Architecture by design centralizes such
monitoring making it easier and more efficient.
6. Limit the risks of leakage of the Cryptographic Material. By
centralizing the Cryptographic Material to one or a reduce set of
the Cryptographic Services, the LURK Architecture prevents the
Cryptographic Material to be disseminated within a data center
with numerous replicate of that confidential data. In addition,
the reduced number of instances of Cryptographic Service makes it
economically feasible to deploy hardware security.
7. Enable collaboration between actors by slicing the services.
Typically, the owner of the Cryptographic Material can delegate
the Service Instance while not sharing the Cryptographic
Material. This ease collaboration as the Service Instance
Migault Expires 27 January 2022 [Page 6]
Internet-Draft LURK TLS July 2021
provider is not associated with risks of leaking the
Cryptographic Material and the owner of the Cryptographic
Material can initiate such collaboration without compromising the
secrecy of the Cryptographic Material.
8. Improve the control of the ownership of the Cryptographic
Material to a per-operation level. Shared Cryptographic Material
has only a time limitation until the agreement expires and is
renewed. This means that before expiration time, the owner of
the Cryptographic Material literally gives up its control. The
LURK Architecture, instead, enables the owner to prevent any
Service Instance at any time to serve as or on behalf of the
owner of the Cryptographic Material.
On the other hand, the LURK Architecture also comes with some
drawbacks and challenges:
1. Latency introduced by the communication between the LURK Client
and the LURK Server. In some cases, the latency may not be
acceptable, which may impose the presence of a more site local
instance of Cryptographic Service in order to reduce the latency.
This may be problematic, to establish highly dynamic
collaboration without a secure and trusted mechanism to provision
the Cryptographic Service in another domain. Note that sharing
the Cryptographic Service local remains safer than sharing the
Cryptographic Material, and sharing a Cryptographic Service
between different domain may be associated to a lower trust into
the involved parties.
2. Centralizing Cryptographic Operation may provide a bottleneck
vulnerability, both in term of computing resource available to
the Cryptographic Service as well as to bandwidth necessary for
the communication between the LURK Client and the LURK Server.
The use of authenticated Service Instances limits the risk of a
resource exhaustion attack on the Cryptographic Service. In
fact, the Cryptographic Service is expected to be provisioned in
order to serve the expected demand from Service Instances. On
the other hand, if that would happen, scaling the computing
resource may be relatively easy regarding the limited scope of
the Cryptographic Service. That said, maintaining an available
channel between distinct networks may be a harder challenge that
may require placing the Cryptographic Service at multiple
locations. In case this is not feasible, or the associated cost
are too high other mechanisms should be used such as the use of
short term certificate [I-D.sheffer-acme-star-request], [RFC8739]
or delegated credentials for TLS [I-D.rescorla-tls-subcerts].
Migault Expires 27 January 2022 [Page 7]
Internet-Draft LURK TLS July 2021
3. Cryptographic operations are performed isolated from their
context which prevents the distinction between a legitimate
request performed in the scope of a Service Instance operation
from a request that is part of an attack performed by a rogue
Service Instance or a rogue LURK Client outside a Service
Instance. Typically, in the case of TLS, a legitimate context
would include the establishment of a TLS session. This issue may
be mitigated with authenticated and trusted Service Instances, a
limitation of the Cryptographic Material usage outside the scope
of a legitimate use as well as avoiding leaking information
related to the Cryptographic Material. Protection against such
usage is expected to be provided by the design of the LURK
Extension.
4.2. LURK Architecture and Hardware Security Module
The primary purpose of an Hardware Security Module (HSM) is to
prevent tampering the Cryptographic Material. In most of the cases,
HSM provides a generic PKCS11 cryptographic interface instead of a
interface specific to a Service Instance. In addition, PKCS11 does
not provide remote access facilities and rely on proprietary
protocols which does not for example favor interoperability between
different service providers.
The LURK Architecture is not incompatible with the use of an HSM.
Typically the HSM can be used by the Cryptographic Service in order
to protect the Cryptographic Material as depicted in Figure 2. Low
level cryptographic operations are performed by the HSM, the LURK
Server Processing is intended to perform additional operation in
order to match the expected format defined by the LURK Protocol and
LURK Extensions. The combination of the LURK Architecture and the
HSM provides the following advantages:
* The HSM benefits from LURK Protocol and LURK Extensions as a
standard way to remotely access the HSM. As a consequence, the
LURK Architecture enables the resource of an HSM to be shared,
which presents some significant saving costs.
* The HSM benefits from the protection provided by the LURK
Extension that limits usage as well disclosure of the input /
output provided to the HSM.
* The Cryptographic Service benefits from the hardware security
provided by the HSM.
* The Cryptographic Service provides an interface dedicated and more
intuitive to the Service Instance that the PKCS11 generic
interface.
Migault Expires 27 January 2022 [Page 8]
Internet-Draft LURK TLS July 2021
+-------------------------------------------------+
| Cryptographic Service |
+--------------+---------------+------------------+
| | | HSM |
| LURK Server | LURK Server PKCS11 Cryptographic |
| Interface | processing <---> Material |
| | | (private key) |
| | | |
+--------------+---------------+------------------+
Figure 2: Cryptographic Function with HSM
4.3. LURK Protocol and LURK extensions
The purpose of the LURK Protocol and the LURK Extensions is to
provide an interfaces between a Service Instance and a Cryptographic
Service. The number of Cryptographic Service is expected to evolve
over time and these requirements are expected to be fulfilled by a
specific LURK Extension, while the LURK Protocol is designed as a
placeholder for these LURK Extensions.
As a placeholder for LURK Extensions, the main functionality of the
LURK Protocol is to steer requests from the LURK Client to the
appropriated LURK Extension, and then steer back the response to the
LURK Client. Such interactions define exchanges when the request
cannot be handled by the LURK Extension as well as when the LURK
Extension is not enabled on the LURK Server. This is expected to
ease the development of future LURK Extensions limited to specific
operations requested by the LURK Client.
In addition, the LURK Protocol is also expected to enable a very
limited and generic set of interactions between the LURK Client and
the LURK Server. These interactions are typically defined by
operations requested by the LURK Client, and this document defines
two type of requests. A request of type capabilities request defined
in Section 6.1 that enables the LURK Client to discover the supported
LURK Extensions of the LURK Server. In addition, a request of type
ping defined in Section 6.2 enables connectivity check. These
interactions are considered as part of the LURK Protocol but could
also be seen as a specific LURK Extension: the "lurk" LURK Extension.
This document treats both the LURK Extension "lurk" as the LURK
Protocol. The distinction is expected to be implementation
dependent.
Figure 3 describes how the LURK Protocol and the LURK Extensions
interacts each others. When the LURK Client interacts with a LURK
Server, it is expected to designates the specific Cryptographic
Operation to be performed within the designated LURK Extension as
Migault Expires 27 January 2022 [Page 9]
Internet-Draft LURK TLS July 2021
well as the necessary parameters for the extension to perform its
operation. Upon performing the Cryptographic Operation, the LURK
Extension returns the output of the operation with an return code.
These output are handled by the LURK Protocol and returned to the
LURK Client.
+--------------------------------------------------+
| LURK Server |
+----------------+----------------+----------------+
| | | |
| LURK Extension | LURK Extension | LURK Extension |
| (A) | (B) | (C) |
| | | |
+--------------------------------------------------+
| |
| LURK Protocol |
| |
+--------------------------------------------------+
Figure 3: LURK Protocol and LURK Extension
Messages exchanged between the LURK Client and the LURK Server are
composed of a LURK Header and LURK Payload as depicted in Figure 4.
The LURK Extensions are designed to process the LURK Payloads -
eventually void -, while the LURK Header contains the necessary
information for the LURK Server to steer the LURK Payload to the
appropriated LURK Extension. In that sense, the LURK Protocol could
be interpreted as the processing of the LURK Header while the LURK
Extension 'lurk' is processing the (void) LURK Payloads. This
document treats both the LURK Extension 'lurk' as the LURK Protocol.
+----------------------------------+
| |
| LURK Header |
| |
+----------------------------------+
| |
| LURK Payload |
| |
+----------------------------------+
Figure 4: LURK Message Description
5. LURK Header Processing
As detailed in Section 4.3, upon receiving an request from the LURK
Client, the LURK Protocol may:
Migault Expires 27 January 2022 [Page 10]
Internet-Draft LURK TLS July 2021
* Respond directly if the request is associated to the LURK
Protocol.
* Proxy the request to the appropriated LURK Extension when
supported.
* Respond to with an error.
This section treats the two latest aspects while Section 6 describes
the requests specific to the LURK Protocol.
5.1. LURK Header
The LURK Header structure is as follows:
Migault Expires 27 January 2022 [Page 11]
Internet-Draft LURK TLS July 2021
enum {
lurk (0), (255)
} Designation;
enum {
request (0), success (1), undefined_error (2),
invalid_format (3), invalid_extension (4), invalid_type (5),
invalid_status (6), temporary_failure (6), (255)
} LURKStatus
enum {
capabilities (0), ping (1), (255)
} LURKType;
struct {
Designation designation = "lurk";
int8 version = 1;
} Extension;
struct {
Extension extension;
select( Extension ){
case ("lurk", 1):
LURKType;
} type;
select( Extension ){
case ("lurk", 1):
LURKStatus;
} status;
uint64 id;
unint32 length;
} LURKHeader;
extension describes the LURK Protocol. In this document the
extension is defined with designation set to "lurk" and version is
set to 1.
type indicates the type of the request associated to the extension.
status defines if the message is a request or a response. When the
message is a response, the status indicates if the request has
been processed correctly and if not the status indicates the
associated error.
id identifies the exchange.
Migault Expires 27 January 2022 [Page 12]
Internet-Draft LURK TLS July 2021
length length of the entire message, including header, in bytes.
5.2. LURK Client Behavior
The LURK Client is only able to send requests and MUST set the status
header field to "request". The extension (designation, version) and
the type characterizes the request. The id is expected to be
unpredictable and SHOULD be randomly generated. The length is
computed once the LURK Payload has been inserted and includes the
number of bytes of the LURK Header as well as those of the LURK
Payload.
Upon receiving a message, the LURK Client checks:
1. The message id matches a request previously sent and discards the
message otherwise.
2. The message status indicates a response, i.e. with a status
different from "request" and discards the message otherwise.
1. A status set to "success" indicates, the request has been
properly processed by the LURK Server. In this case, the
extension, type and id field of the response MUST match those
of the request. The LURK Client is expected to process the
LURK Payload.
2. A status reporting an error - i.e. that differs from
"request" and "success" reports an error. The LURK Client
SHOULD be able to handle such errors and SHOULD be able to
log them for further analysis. In addition, some errors may
trigger some specific behavior such as discovering the
capabilities of the LURK Server.
5.3. LURK Server Behavior
Upon receiving a message the LURK Server checks
1. The message extension is supported. When the extension is not
supported, the LURK Server SHOULD respond with an
"invalid_extension" error.
2. The message status is set to "request". When the status differs
from "request", the LURK Server SHOULD respond with an
"invalid_status" error.
3. The message type is supported. The message type is associated to
the extension. When the message type is not supported the LURK
Server SHOULD respond with an "invalid_type" error.
Migault Expires 27 January 2022 [Page 13]
Internet-Draft LURK TLS July 2021
Once the message header has been validated, the LURK Payload is
extracted to be processed by the appropriated extension. If any
error occurs before the LURK Payload can be steered to the extension,
the LURK Server SHOULD respond with an "invalid_format" or
"undefined_error".
When overloaded, the LURK Server SHOULD send a "temporary_failure"
error to indicate its inability to treat the request.
When an error is returned before the LURK Payload is being processed,
the LURK Server sets the extension to "lurk". When multiple versions
are served, and match the error, the LURK Server SHOULD set the
version to a version known to be supported by the LURK Client. When
this information is not available, the LURK Server SHOULD chose the
minimum supported value. The status is set to the error code, the
type and id are copied from the request and the length is computed
according to the ErrorPayload.
Once the LURK header has been validated, the LURK Server is able to
request the treatment of the LURK Payload to a specific operation to
the appropriated LURK Extension identified by (extension, type). In
return, the LURK Extension is expected to returns the corresponding
response LURK Payload, and eventually an error code.
1. When no error code is returned, the LURK Server returns a LURK
Header copying the extension, the type and id from the request.
The status is is set to "success" and the length is computed from
the LURK Payload returned by the LURK Extension or the LURK
Protocol. The LURK Payload is happened to the LURK Header before
being sent back to the LURK Client.
2. When an error code is returned, the LURK Server returns a LURK
Header copying the extension, the type and the id from the
request. The status is set to the returned error code, and the
length is computed from the returned LURK Payload. The LURK
Payload is happened to the LURK Header before being sent back to
the LURK Client.
The LURK Server SHOULD return error message when possible to inform
the LURK Client on the reasons the exchange fails. However, in some
cases, the LURK Server MAY discard the request without returning the
error.
5.4. Error Message
The error code is indicated by the status when its value differs from
"request" or "success".
Migault Expires 27 January 2022 [Page 14]
Internet-Draft LURK TLS July 2021
Error message MAY have no Payload. Error message MAY also carry a
state value that indicates a change in the configuration of the LURK
Server. The state is expected to reflect any change of the
configuration associated to the extension. Generation of the state
is implementation dependent and out of the scope of this document.
It can typically be implemented as a counter that is incremented any
time the extension configuration is updated, or as the hash function
of the configuration file.
Upon reception of the state, if the LURK Client has stored the
previous value, it is expected to compare the two values. A mismatch
indicates that extension configuration change and the LURK Client
SHOULD perform some capability discoveries. If the two values match
an capability discovery SHOULD NOT be performed. The absence of
ErrorPayload is considered as a mismatch.
struct {
opaque lurk_state<32> ;
}ErrorPayload;
Figure 5: Error Payload Description
6. LURK Request type
While Section 5 details how the LURK Protocol steers a request from
the LURK Client to an appropriated LURK Extension, this section
details the specific requests associated to the LURK Protocol that
can be initiated by the LURK Client. As exposed in Section 4.3, this
section could be seen as a LURK Extension 'lurk'. However this
document does not makes such distinction and the LURK Extension
'lurk' and the LURK Protocol are considered as the same.
The LURK Protocol provides some basic reachability and discovery
interactions between LURK Client and LURK Servers.
The LURK Header is expected to have the extension's designation set
to "lurk" and the extension's version set to 1. The type of the
exchange is indicated by the type field.
6.1. capabilities
6.1.1. Request Payload
A LURK "capabilities" request has no payload.
Migault Expires 27 January 2022 [Page 15]
Internet-Draft LURK TLS July 2021
6.1.2. Response Payload
The "capabilities" response payload consists in a list of the
supported Extensions structures.
struct {
LURKSupportedExtension supported_extensions_list<2..2^16-2>;
LURKSupportedType supported_type<2..2^16-2>;
opaque lurk_state<32>;
}LURKCapabilitiesResponsePayload;
Figure 6: LURK Capability Payload Description
supported_extensions_list is the concatenation of all supported
extensions by the LURK Server. The possible values for the
extensions are defined in Section 5.1.
supported_type_list is the concatenation of all supported type by
the LURK Server. The possible values for the extensions are
defined in Section 5.1.
lurk_state This value defined in Section 5.4is returned in error
messages as to indicate whether the configuration has been updated
and if a new LURK capability request needs to be sent.
6.1.3. LURK Client Behavior
The LURK Client sends a "capabilities" request in a "lurk" extension
to discover the various extensions and versions supported by the LURK
Server.
6.1.4. LURK Server Behavior
The LURK Server lists the supported extensions and version the
requester is authorized to request and sends the response.
6.2. ping
6.2.1. Request Payload
A LURK "ping" request has no payload.
6.2.2. Response Payload
A LURK "ping" response has no payload.
Migault Expires 27 January 2022 [Page 16]
Internet-Draft LURK TLS July 2021
6.2.3. LURK Client Behavior
The LURK Client sends a "ping" request to test the reachability of
the LURK Server. The reachability is performed within a LURK
relation.
6.2.4. LURK Server Behavior
The LURK Server sends the corresponding response.
6.3. Errors
A LURK Server MAY raise a "invalid_payload_format" or a
"undefined_error" if for example a unexpected payload is provided.
7. Security Considerations
This document has provided a security analysis of the LURK
Architecture.
LURK message can be carried over UDP, and some responses MAY present
significant larger response payloads than the request payloads. The
messages responded by the LURK Protocol can be be a capabilities
response, a ping response or an error. The ping response does not
represent any size message increase. An error response MAY carry an
error payload of 32 bits that represents the state. Such increase
does not seems sufficient to motivate amplification attacks, and the
payload MAY be omitted. The capabilities responses carry a payload
whose size increases with the number of supported LURK Extension and
version. Similarly, the number of LURK Extension supported by a
Cryptographic Service is expected to remain quite low, and as such
the additional size is not expected to represent a significant
threat.
While the LURK Protocol does not provide a significant packet size
increase, the LURK Protocol may be used carry response payloads
associated to a LURK Extension, and as such, the applicator factor
associated to each supported LURK Extension MUST be considered.
The LURK Protocol does not define any mechanisms to authenticate the
LURK Client and the LURK Server nor to protect the data channel
between the LURK Client and the LURK Server. It is RECOMMENDED to
protect LURK exchanges by protecting the communication between the
LURK Client and the LURK Server using for example IPsec [RFC4301],
TLS 1.2 [RFC5246], TLS 1.3 [RFC8446] DTLS 1.2 [RFC6347] or DTLS !.3
[I-D.ietf-tls-dtls13].
Migault Expires 27 January 2022 [Page 17]
Internet-Draft LURK TLS July 2021
The information exchanged between in the scope of the LURK Protocol
may not be considered as confidential. As such exchanges between the
LURK Client and the LURK Server may not need to be encrypted. A ping
exchange reveals the reachability and the potential scope of the
exchange between the two peers. The capabilities exchange reveals
the observer the extensions enabled by the LURK Server. This may
provide information relative to the function of the LURK Server and
the LURK Client.
As the LURK Protocol is a place holder for LURK Extension, the
confidentiality of the information depends on the LURK Extension
enabled. By default, It is RECOMMENDED to encrypt the LURK
exchanges.
The LURK Server can enable multiple LURK Extensions, serve multiple
LURK Clients as well as serve multiple Cryptographic Material. In
order to increase the protection boundaries, it is expected to limit
the scope of a LURK Server. It is RECOMMENDED to limit the scope of
the LURK Server to a limited number of Cryptographic Material. As
Cryptographic Material is expected to have a limited scope, it is
then expected and RECOMMENDED that the LURK Server enables a limited
number of LURK Extensions. In addition, it is also RECOMMENDED that
the enabled LURK Extension be appropriately configured to provide
only the necessary functionalities.
8. IANA Considerations
The LURK Protocol and LURK Extension requires the following
parameters to be registered by the IANA.
Migault Expires 27 January 2022 [Page 18]
Internet-Draft LURK TLS July 2021
LURK Extension Designation
Value Designation Reference Description
-------------------------------------------------
0 lurk [RFC-TBD] LURK Protocol
1-255 UNASSIGNED
LURK Protocol Status
Value Description Reference
-----------------------------------------------------
0 request [RFC-TBD]
1 success [RFC-TBD]
2 undefined_error [RFC-TBD]
3 invalid_format [RFC-TBD]
4 invalid_extension [RFC-TBD]
5 invalid_type [RFC-TBD]
6 invalid_status [RFC-TBD]
7 temporary_failure [RFC-TBD]
8-255 UNASSIGNED
LURK Protocol Type
Value Description Reference
----------------------------------------------
0 capabilities [RFC-TBD]
1 ping [RFC-TBD]
3-255 UNASSIGNED
When a new LURK Extension is created, the designation of the LURK
Extension, the associated status and type MUST be provided. The
status values 0 to 1 are reserved and cannot be assigned with
different meanings. As a result, the template for future LURK
extension is defined as follows:
Migault Expires 27 January 2022 [Page 19]
Internet-Draft LURK TLS July 2021
LURK Extension Designation:
LURK Extension Reference:
LURK Extension Description:
LURK Extension Status
Value Description Reference
-------------------------------------------
0-1 RESERVED [RFC-TBD]
LURK Extension Type
Value Description Reference
----------------------------------------------
Registration of LURK Designation for code points 0-127 requires
Standard Track, while other code points are RFC Required [RFC8126].
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
Migault Expires 27 January 2022 [Page 20]
Internet-Draft LURK TLS July 2021
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021, <https://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-43.txt>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[I-D.mglt-lurk-tls-use-cases]
Migault, D., J, K. M., Salz, R., Mishra, S., and O. G. D.
Dios, "LURK TLS/DTLS Use Cases", Work in Progress,
Internet-Draft, draft-mglt-lurk-tls-use-cases-02, 28 June
2016, <https://www.ietf.org/archive/id/draft-mglt-lurk-
tls-use-cases-02.txt>.
[I-D.mglt-lurk-tls]
Migault, D., "LURK Protocol for TLS/DTLS1.2 version 1.0",
Work in Progress, Internet-Draft, draft-mglt-lurk-tls-01,
11 March 2017, <https://www.ietf.org/archive/id/draft-
mglt-lurk-tls-01.txt>.
[I-D.rescorla-tls-subcerts]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS", Work in Progress,
Internet-Draft, draft-rescorla-tls-subcerts-02, 30 October
2017, <https://www.ietf.org/archive/id/draft-rescorla-tls-
subcerts-02.txt>.
[RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor
Perales, A., and T. Fossati, "Support for Short-Term,
Automatically Renewed (STAR) Certificates in the Automated
Certificate Management Environment (ACME)", RFC 8739,
DOI 10.17487/RFC8739, March 2020,
<https://www.rfc-editor.org/info/rfc8739>.
[I-D.sheffer-acme-star-request]
Sheffer, Y., Lopez, D., Dios, O. G. D., Perales, A. A. P.,
and T. Fossati, "Generating Certificate Requests for
Short-Term, Automatically-Renewed (STAR) Certificates",
Work in Progress, Internet-Draft, draft-sheffer-acme-star-
request-02, 29 June 2018,
<https://www.ietf.org/archive/id/draft-sheffer-acme-star-
request-02.txt>.
Migault Expires 27 January 2022 [Page 21]
Internet-Draft LURK TLS July 2021
[HEART] Codenomicon, "The Heartbleed Bug",
<http://heartbleed.com/>.
Author's Address
Daniel Migault
Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada
Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com
Migault Expires 27 January 2022 [Page 22]
