<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.35) -->

<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes"?>
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="4"?>
<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>

<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->

<rfc category="std" ipr="trust200902" docName="draft-mglt-lurk-lurk-01">
  <front>
    <title abbrev="LURK TLS">LURK Protocol version 1</title>

    <author fullname="Daniel Migault" initials="D." surname="Migault" >
      <organization> Ericsson </organization>
      <address>
        <postal>
          <street> 8400 boulevard Decarie </street>
          <city> Montreal, QC </city>
          <code> H4P 2N2 </code>
          <country> Canada </country>
        </postal>
        <phone> +1 514-452-2160 </phone>
        <email> daniel.migault@ericsson.com </email>
      </address>
    </author>

    <date/> <!-- <date day="4" month="March" year="2015"/> -->
    <area> Security </area>
    <workgroup> LURK WG  </workgroup>

    <abstract>

<t>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. </t>

</abstract>

  </front>


  <middle>

        <section title="Requirements notation">

<t>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 <xref
target="RFC2119"/>.</t> 

       </section>

    <section title="Introduction" anchor="sec-intro">

<t>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 leakage in case of a
software vulnerabilities  <xref target="HEART"/> in the service, or in
case of cryptographic attacks.  </t>

<t>For example, in large TLS deployment <xref
target="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.</t>

<t>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.</t>

</section>

<section title="Terminology and Acronyms">

<t>In addition to the terminology defined in <xref
target="I-D.mglt-lurk-tls-use-cases"/>, this document introduces the following
terminology:

<list hangIndent="6" style="hanging">
            
<t hangText="- LURK Architecture : ">The architecture that consists in
using a Cryptographic Service accessed by a Service Instance.</t>
            
<t hangText="- Service Instance : ">A service that requires interacting
with a Cryptographic Service to perform its tasks.</t>
            
<t hangText="- Cryptographic Service : ">A service dedicated to perform
Cryptographic Operations using a Cryptographic Material.</t>
            
<t hangText="- Cryptographic Material : "> Is the highly sensitive
material that is used to perform the Cryptographic Operations. This is
typically a secret key.</t>

<t hangText="- 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 on the input data or the
output data. This makes such operation service-dependent as opposed to a
generic cryptographic engine.</t>
            
<t hangText="- 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.</t>
            
<t hangText="- LURK Extensions : ">The specifications of the
Cryptographic Service for a specific service or context.</t>
                   
<t hangText="- 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.</t> 
            
<t hangText="- 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.  </t>
        
</list></t>
    
</section>

<section title="Overview">

<section title="LURK Architecture">

<t>The LURK Architecture depicted in <xref target="arch"/> 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 <xref
target="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.</t>

<t>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 <xref target="arch"/>.
Additional operations may be added to the low level cryptographic
operations before responding to the LURK Client. </t>

<t>The LURK Architecture improves the security associated to the
Cryptographic Material by limiting its dissemination and improving the
control of the its usage.</t>

<t>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.</t> 

<figure anchor="arch" title="LURK Architecture">
<artwork align="center"><![CDATA[
                       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 |
|            |        |
+------------+--------+
]]></artwork></figure>

<t>The remaining of this section intends to provide a high level
overview of the pros and cons provided by the LURK Architecture. </t>

<t>The LURK Architecture is expected to provide the following advantage:

<list style="numbers">

<t>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.</t>

<t>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 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....</t>

<t>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.</t>

<t>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. </t>

<t>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.</t>

<t>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.</t>

<t>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 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.</t>

<t>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. </t>

</list></t>

<t>On the other hand, the LURK Architecture also comes with some
drawbacks and challenges:  

<list style="numbers">

<t>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.</t>

<t>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
<xref target="I-D.sheffer-acme-star-request"/>, <xref
target="RFC8739"/> or delegated credentials for TLS <xref
target="I-D.rescorla-tls-subcerts"/>.</t>

<t>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.</t>

</list></t>

</section>

<section title="LURK Architecture and Hardware Security Module">

<t>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.</t>

<t>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 <xref
target="fig-hsm"/>. 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: 

<list style="number">
    
<t> 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.</t>

<t> 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. </t>
    
<t> The Cryptographic Service benefits from the hardware security
provided by the HSM.</t>
   
<t>The Cryptographic Service provides an interface dedicated and more
intuitive to the Service Instance that the PKCS11 generic interface.</t>

</list>

</t>

<figure anchor="fig-hsm" title="Cryptographic Function with HSM">
<artwork align="center"><![CDATA[
+-------------------------------------------------+
|             Cryptographic Service               |
+--------------+---------------+------------------+
|              |               |        HSM       |
| LURK Server  | LURK Server PKCS11 Cryptographic |
| Interface    | processing  <--->    Material    |
|              |               |    (private key) |
|              |               |                  |
+--------------+---------------+------------------+
]]></artwork></figure>

</section>


<section title="LURK Protocol and LURK extensions"
anchor="sec-lurk-proto-ext">


<t>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.</t>

<t>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.</t>

<t>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 <xref
target="sec-lurk-cap"/> that enables the LURK Client to discover the
supported LURK Extensions of the LURK Server. In addition, a request of
type ping defined in <xref target="sec-lurk-ping"/>  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.</t> 

<t><xref target="fig-lurk-proto-ext"/> 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 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.</t>


<figure anchor="fig-lurk-proto-ext" title="LURK Protocol and LURK
Extension">
<artwork align="center"><![CDATA[
+--------------------------------------------------+
|                    LURK Server                   |
+----------------+----------------+----------------+
|                |                |                |
| LURK Extension | LURK Extension | LURK Extension |
|     (A)        |     (B)        |     (C)        |
|                |                |                |
+--------------------------------------------------+
|                                                  |
|                  LURK Protocol                   |
|                                                  |
+--------------------------------------------------+
]]></artwork></figure>



<t>Messages exchanged between the LURK Client and the LURK Server are
composed of a LURK Header and LURK Payload as depicted in <xref
target="fig-lurk-message"/>. 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.</t>


<figure title="LURK Message Description" anchor="fig-lurk-message">
<artwork align="center"><![CDATA[
+----------------------------------+
|                                  |
|           LURK Header            |
|                                  |
+----------------------------------+
|                                  |
|           LURK Payload           |
|                                  |
+----------------------------------+
]]></artwork>
</figure>


</section>

</section>

<section title="LURK Header Processing" anchor="sec-lurk-header-proc">

<t>As detailed in <xref target="sec-lurk-proto-ext"/>, upon receiving
an request from the LURK Client, the LURK Protocol may: 

<list style="number">

<t>Respond directly if the request is associated to the LURK
Protocol.</t>

<t>Proxy the request to the appropriated LURK Extension when supported.</t>

<t>Respond to with an error.</t>

</list></t>

<t>This section treats the two latest aspects while <xref
target="sec-lurk"/> describes the requests specific to the LURK
Protocol.</t>



<section title="LURK Header" anchor="sec-lurk-header">

<t>The LURK Header structure is as follows:</t>


        <figure>
        <artwork align="left"><![CDATA[
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;
        ]]></artwork>
        </figure>

<t>
<list style="hanging">

<t hangText='extension'> describes the LURK Protocol. In this document
the extension is defined with designation set to "lurk" and version is
set to 1.</t>

<t hangText='type'> indicates the type of the request associated to the
extension. </t>

<t hangText='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.</t>  
 
<t hangText='id'> identifies the exchange. </t> 

  
<t hangText='length'> length  of the entire message, including header,
in bytes.</t>
  
</list> </t>  


</section>


<section title="LURK Client Behavior" anchor="sec-lurk-clt">
 
<t>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.</t>

<t>Upon receiving a message, the LURK Client checks:

<list style="numbers">

<t>The message id matches a request previously sent and discards the
message otherwise.</t>

<t>The message status indicates a response, i.e. with a status different
from "request" and discards the message otherwise.

<list style="numbers">

<t>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.</t>

<t>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.</t>  

</list></t>
</list></t>

</section>

<section title="LURK Server Behavior" anchor="sec-lurk-srv">

<t>Upon receiving a message the LURK Server checks

<list style="numbers">

<t>The message extension is supported. When the extension is not
supported, the LURK Server SHOULD respond with an "invalid_extension"
error. </t>

<t>The message status is set to "request". When the status differs from
"request", the LURK Server SHOULD respond with an "invalid_status"
error.</t>

<t>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.</t>

</list></t>

<t>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".</t>

<t>When overloaded, the LURK Server SHOULD send a "temporary_failure"
error to indicate its inability to treat the request.</t> 

<t>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. </t> 

<t>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.

<list style="numbers">

<t>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.</t>

<t>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. </t>

</list></t>

<t>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.</t> 

</section>

<section title="Error Message" anchor="sec-lurk-error">

<t>The error code is indicated by the status  when its value differs from
"request" or "success".</t>

<t>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.</t>

<t>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.</t>

        <figure title="Error Payload Description">
        <artwork align="left"><![CDATA[
struct {
    opaque lurk_state<32> ; 
}ErrorPayload;
        ]]></artwork>
        </figure>

 
</section>



</section><!-- LURK Header -->

<section title="LURK Request type" anchor="sec-lurk"> 

<t>While <xref target="sec-lurk-header-proc"/> 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 <xref
target="sec-lurk-proto-ext"/>, 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. </t> 

<t>The LURK Protocol provides some basic reachability and
discovery interactions between LURK Client and LURK Servers.</t>

<t>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.</t>

    <section title="capabilities" anchor="sec-lurk-cap">
    
        <section title="Request Payload">
        <t>A LURK "capabilities" request has no payload.</t>
        </section>

        <section title="Response Payload">
	<t>The "capabilities" response payload consists in a list of the
supported Extensions structures.</t>

        <figure title="LURK Capability Payload Description">
        <artwork align="left"><![CDATA[
struct {
    LURKSupportedExtension supported_extensions_list<2..2^16-2>;
    LURKSupportedType supported_type<2..2^16-2>;
    opaque lurk_state<32>;  
}LURKCapabilitiesResponsePayload;
        ]]></artwork>
        </figure>


<t> 
<list style="hanging">

<t hangText='supported_extensions_list'> is the concatenation of all
supported extensions by the LURK Server. The possible values for the
extensions are defined in <xref target='sec-lurk-header'/>.</t>

<t hangText='supported_type_list'> is the concatenation of all
supported type by the LURK Server. The possible values for the
extensions are defined in <xref target='sec-lurk-header'/>.</t>

<t hangText='lurk_state'> This value defined in <xref
target="sec-lurk-error"/>is returned in error messages as to indicate
whether the configuration has been updated and if a new LURK capability
request needs to be sent.</t> 

</list> 
</t>

</section>

<section title="LURK Client Behavior">
        
<t>The LURK Client sends a "capabilities" request in a "lurk" extension
to discover the various extensions and versions supported by the LURK
Server. </t>
 
</section>

<section title="LURK Server Behavior">

<t>The LURK Server lists the supported extensions and version the
requester is authorized to request and sends the response.</t> 

</section>

</section>

<section title="ping" anchor="sec-lurk-ping">

<section title="Request Payload">
        
<t>A LURK "ping" request has no payload.</t>
        
</section>

<section title="Response Payload">
        
<t>A LURK "ping" response has no payload.</t>

</section>
        
<section title="LURK Client Behavior">
	
<t>The LURK Client sends a "ping" request to test the reachability of
the LURK Server. The reachability is performed within a LURK
relation.</t>

</section>
        
<section title="LURK Server Behavior">
        
<t>The LURK Server sends the corresponding response.</t>
        
</section>

</section>

<section title="Errors">

<t>A LURK Server MAY raise a "invalid_payload_format" or a
"undefined_error" if for example a unexpected payload is provided.</t>

</section>
 
</section> <!-- LURK Extension 'lurk' -->

<section title="Security Considerations" anchor="sec-sec">

<t>This document has provided a security analysis of the LURK
Architecture.</t>

<t>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.</t>

<t>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.</t>

<t>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 <xref target="RFC4301"/>, TLS
1.2 <xref target="RFC5246"/>, TLS 1.3 <xref
target="RFC8446"/> DTLS 1.2 <xref target="RFC6347"/> or DTLS
!.3 <xref target="I-D.ietf-tls-dtls13"/>.</t>


<t>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.</t>   

<t>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.</t>

<t>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.</t>   




    </section>

<section title="IANA Considerations" anchor="sec-ianae">

<t> The LURK Protocol and LURK Extension requires the following
parameters to be registered by the IANA.</t>

<figure ><artwork align="left"><![CDATA[
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   
]]></artwork></figure>


<t> 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:</t>

<figure ><artwork align="left"><![CDATA[
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
----------------------------------------------

]]></artwork></figure>

<t>Registration of LURK Designation for code points 0-127 requires
Standard Track, while other code points are RFC Required <xref
target="RFC8126"/>.</t>

<!--
<t>We need to finalize this section reading <xref
target="RFC8126"/>.</t>
-->

</section>

</middle>


  <back>
    <references title="Normative References">

        <?rfc include="reference.RFC.2119.xml"?>  
<!--        <?rfc include="reference.RFC.4279.xml"?>  
        <?rfc include="reference.RFC.4492.xml"?>  
        <?rfc include="reference.RFC.5246.xml"?>  
        <?rfc include="reference.RFC.6347.xml"?>  
        <?rfc include="reference.RFC.7627.xml"?>  
-->
    </references>

    <references title="Informative References">
        <?rfc include="reference.RFC.4301.xml"?>  
        <?rfc include="reference.RFC.5246.xml"?>  
        <?rfc include="reference.RFC.8446.xml"?>  
        <?rfc include="reference.RFC.6347.xml"?>  
        <?rfc include="reference.I-D.ietf-tls-dtls13.xml"?>  
        <?rfc include="reference.RFC.8126.xml"?>  
        <?rfc include="reference.I-D.mglt-lurk-tls-use-cases.xml"?> 
        <?rfc include="reference.I-D.mglt-lurk-tls.xml"?>
        <?rfc include="reference.I-D.rescorla-tls-subcerts.xml"?>
        <?rfc include="reference.RFC.8739.xml"?>
        <?rfc include="reference.I-D.sheffer-acme-star-request.xml"?>
        <!--<?rfc include="reference.I-D.erb-lurk-rsalg"?> -->

<reference anchor="HEART" target="http://heartbleed.com/">
        <front>
        <title>The Heartbleed Bug</title>
        <author>
        <organization>Codenomicon</organization>
        </author>
        <date/>
        </front>
    </reference>
    </references>

  </back>
</rfc>
