Draft: draft-ietf-core-oscore-edhoc

Commentary: Clean - up after As the content - from - edhoc branch seems to be the most up - to - date one ( in which the parts changed are introduced in the first place ) , this builds on , and only the latest commit is actually relevant . 
 Compared to the original bstridentifier mapping , this is a different int - to - bstr mapping , but one that 's most likely efficient to implement . I have not made any statement on the efficiencies , but some guidance we could give is that from a coding density point of view , numeric Cx should only be used with -24 .. 23 ; for all other values , doing it in a bstr is just as good and saves a byte in OSCORE . ( In fact we may want to make that normative , so that only the single - byte case needs to be implemented where this needs explicit implementation ) .
This document defines an optimization approach for combining the
lightweight authenticated key exchange protocol EDHOC run over CoAP
with the first subsequent OSCORE transaction.  This combination
reduces the number of round trips required to set up an OSCORE
Security Context and to complete an OSCORE transaction using that
Security Context.
This document defines an optimization approach to combine the
lightweight authenticated key exchange protocol EDHOC I-D.ietf-lake-
edhoc, when running over CoAP RFC7252, with the first subsequent
OSCORE RFC8613 transaction.
This allows for a minimum number of round trips necessary to setup
the OSCORE Security Context and complete an OSCORE transaction, for
example when an IoT device gets configured in a network for the first
time.
This document defines how the lightweight authenticated key exchange
protocol EDHOC is used for establishing an OSCORE Security Context,
using CoAP for message transferring.  Furthermore, this document
defines an optimization approach for combining EDHOC run over CoAP
with the first subsequent OSCORE transaction.  This reduces the
number of round trips required to set up an OSCORE Security Context
and to complete an OSCORE transaction using that Security Context.
Ephemeral Diffie-Hellman Over COSE (EDHOC) I-D.ietf-lake-edhoc is a
lightweight authenticated key exchange protocol, especially intended
for use in constrained scenarios.  As defined in Section 7.2 of I-
D.ietf-lake-edhoc, EDHOC messages can be transported over the
Constrained Application Protocol (CoAP) RFC7252.
This document builds on the EDHOC specification I-D.ietf-lake-edhoc
and defines how EDHOC run over CoAP is used for establishing a
Security Context for Object Security for Constrained RESTful
Environments (OSCORE) RFC8613.
In addition, this document defines an optimization approach that
combines EDHOC run over CoAP with the first subsequent OSCORE
transaction.  This allows for a minimum number of round trips
necessary to setup the OSCORE Security Context and complete an OSCORE
transaction, for example, when an IoT device gets configured in a
network for the first time.
Without this optimization, it is not possible, not even in theory, to
achieve the minimum number of flights.  This optimization makes it
possible also in practice, since the last message of the EDHOC
protocol can be made relatively small (see Section 1 of I-D.ietf-
lake-edhoc), thus allowing additional OSCORE protected CoAP data
within target MTU sizes.
Without this optimization, it is not possible, not even in theory, to
achieve the minimum number of flights.  This optimization makes it
possible also in practice since the last message of the EDHOC
protocol can be made relatively small (see Section 1 of I-D.ietf-
lake-edhoc), thus allowing additional OSCORE protected CoAP data
within target MTU sizes.
EDHOC is a 3-message key exchange protocol.  Section 7.2 of I-D.ietf-
lake-edhoc specifies how to transport EDHOC over CoAP: the EDHOC data
(referred to as "EDHOC messages") are transported in the payload of
CoAP requests and responses.
This draft deals with the case of the Initiator acting as CoAP Client
and the Responder acting as CoAP Server; instead, the case of the
Initiator acting as CoAP Server cannot be optimized by using this
approach.
That is, the CoAP Client sends a POST request containing EDHOC
message_1 to a reserved resource at the CoAP Server.  This triggers
the EDHOC exchange on the CoAP Server, which replies with a 2.04
(Changed) Response containing EDHOC message_2.  Finally, the CoAP
Client sends EDHOC message_3, as a CoAP POST request to the same
resource used for EDHOC message_1.  The Content-Format of these CoAP
messages may be set to "application/edhoc".
After this exchange takes place, and after successful verifications
specified in the EDHOC protocol, the Client and Server derive the
OSCORE Security Context, as specified in Section 7.2.1 of I-D.ietf-
lake-edhoc.  Then, they are ready to use OSCORE.
This sequential way of running EDHOC and then OSCORE is specified in
fig-non-combined.  As shown in the figure, this mechanism takes 3
round trips to complete.
The number of roundtrips can be minimized as follows.  Already after
receiving EDHOC message_2 and before sending EDHOC message_3, the
CoAP Client has all the information needed to derive the OSCORE
Security Context.
This means that the Client can potentially send at the same time both
EDHOC message_3 and the subsequent OSCORE Request.  On a semantic
level, this approach practically requires to send two separate REST
requests at the same time.
The high level message flow of running EDHOC and OSCORE combined is
shown in fig-combined.
Defining the specific details of how to transport the data and of
their processing order is the goal of this specification, as defined
in edhoc-in-oscore.
This section defines the EDHOC Option, used in a CoAP request to
signal that the request combines EDHOC message_3 and OSCORE protected
data.
The EDHOC protocol allows two peers to agree on a cryptographic
secret, in a mutually-authenticated way and by using Diffie-Hellman
ephemeral keys to achieve perfect forward secrecy.  The two peers are
denoted as Initiator and Responder, as the one sending or receiving
the initial EDHOC message_1, respectively.
After successful processing of EDHOC message_3, both peers agree on a
cryptographic secret that can be used to derive further security
material, and especially to establish an OSCORE Security Context
RFC8613.  The Responder can also send an optional EDHOC message_4 to
achieve key confirmation, e.g. in deployments where no protected
application message is sent from the Responder to the Initiator.
Section 7.2 of I-D.ietf-lake-edhoc specifies how to transport EDHOC
over CoAP.  That is, the EDHOC data (referred to as "EDHOC messages")
are transported in the payload of CoAP requests and responses.  The
default message flow consists in the CoAP Client acting as Initiator
and the CoAP Server acting as Responder.  Alternatively, the two
roles can be reversed.  In the rest of this document, EDHOC messages
are considered to be transported over CoAP.
fig-non-combined shows a Client and Server running EDHOC as Initiator
and Responder, respectively.  That is, the Client sends a POST
request with payload EDHOC message_1 to a reserved resource at the
CoAP Server, by default at Uri-Path "/.well-known/edhoc".  This
triggers the EDHOC exchange at the Server, which replies with a 2.04
(Changed) Response with payload EDHOC message_2.  Finally, the Client
sends a CoAP POST request to the same resource used for EDHOC
message_1, with payload EDHOC message_3.  The Content-Format of these
CoAP messages may be set to "application/edhoc".
After this exchange takes place, and after successful verifications
as specified in the EDHOC protocol, the Client and Server can derive
an OSCORE Security Context, as defined in oscore-ctx of this
document.  After that, they can use OSCORE to protect their
communications.
As shown in fig-non-combined, this purely-sequential way of first
running EDHOC and then using OSCORE takes three round trips to
complete.
edhoc-in-oscore defines an optimization for combining EDHOC with the
first subsequent OSCORE transaction.  This reduces the number of
round trips required to set up an OSCORE Security Context and to
complete an OSCORE transaction using that Security Context.
When using EDHOC over CoAP for establishing an OSCORE Security
Context, EDHOC messages are exchanged as defined in Section 7.2 of I-
D.ietf-lake-edhoc, with the following addition.
EDHOC error messages sent as CoAP responses MUST be error responses,
i.e. they MUST specify a CoAP error response code.  In particular, it
is RECOMMENDED that such error responses have response code either
4.00 (Bad Request) in case of client error (e.g. due to a malformed
EDHOC message), or 5.00 (Internal Server Error) in case of server
error (e.g. due to failure in deriving EDHOC key material).
After successful processing of EDHOC message_3 (see Section 5.5 of I-
D.ietf-lake-edhoc), the Client and Server derive Security Context
parameters for OSCORE (see Section 3.2 of RFC8613) as follows.
The Master Secret and Master Salt are derived by using the EDHOC-
Exporter interface defined in Section 4.1 of I-D.ietf-lake-edhoc.
The EDHOC Exporter Labels to use are "OSCORE Master Secret" and
"OSCORE Master Salt", for deriving the OSCORE Master Secret and
the OSCORE Master Salt, respectively.
By default, key_length is the key length (in bytes) of the
application AEAD Algorithm of the selected cipher suite for the
EDHOC session.  Also by default, salt_length has value 8.  The
Initiator and Responder MAY agree out-of-band on a longer
key_length than the default and on a different salt_length.
The AEAD Algorithm is the application AEAD algorithm of the
selected cipher suite for the EDHOC session.
The HKDF Algorithm is the HKDF algorithm of the selected cipher
suite for the EDHOC session.
In case the Client is the Initiator and the Server is the
Responder, the Client's OSCORE Sender ID and the Server's OSCORE
Sender ID are the byte string EDHOC connection identifier C_R and
C_I for the EDHOC session, respectively.  The reverse applies in
case the Client is the Responder and the Server is the Initiator.
Numeric connection identifiers are converted to (naturally byte-
string shaped) Sender IDs by using their CBOR encoded form.  For
example, a C_R of 10 corresponds to a (typically server) Sender ID
of hexadecimal '0a', -12 to hexadecimal '2b', whereas a byte-
string valued C_R of h'ff' corresponds to a Sender ID of
hexadecimal 'ff'.
Before deriving an OSCORE Security Context, the two peers MUST
ensure that the EDHOC connection identifiers are different. that
is, the two peers MUST NOT derive an OSCORE Security Context from
an EDHOC session, if C_R is equal to C_I for that session.
If the Responder runs EDHOC with the intention of deriving an
OSCORE Security Context, the Responder MUST NOT include in EDHOC
message_2 a connection identifier C_R equivalent (under conversion
to a Sender ID) to the connection identifier C_I received in EDHOC
message_1.  If the Initiator runs EDHOC with the intention of
deriving an OSCORE Security Context, the initiator MUST
discontinue the protocol and reply with an EDHOC error message
when receiving an EDHOC message_2 that includes a connection
identifier C_R equal to C_I.
The Client and Server use the parameters above to establish an OSCORE
Security Context, as per Section 3.2.1 of RFC8613.
From then on, the Client and Server MUST be able to retrieve the
OSCORE protocol state using its chosen connection identifier, and
optionally other information such as the 5-tuple, i.e., the tuple
(source IP address, source port, destination IP address, destination
port, transport protocol).
This section defines an optimization for combining the EDHOC exchange
with the first subsequent OSCORE transaction, thus minimizing the
number of round trips between the two peers.
This approach can be used only if the default EDHOC message flow is
used, i.e., when the Client acts as Initiator and the Server acts as
Responder, while it cannot be used in the case with reversed roles.
When running the purely-sequential flow of overview, the Client has
all the information to derive the OSCORE Security Context already
after receiving EDHOC message_2 and before sending EDHOC message_3.
Hence, the Client can potentially send both EDHOC message_3 and the
subsequent OSCORE Request at the same time.  On a semantic level,
this requires sending two REST requests at once, as in fig-combined.
To this end, the specific approach defined in this section consists
of sending EDHOC message_3 inside an OSCORE protected CoAP message.
The resulting EDHOC + OSCORE request is in practice the OSCORE
Request from fig-non-combined, as still sent to a protected resource
and with the correct CoAP method and options, but with the addition
that it also transports EDHOC message_3.
As EDHOC message_3 may be too large to be included in a CoAP Option,
e.g., if containing a large public key certificate chain, it has to
be transported in the CoAP payload of the EDHOC + OSCORE request.
The rest of this section specifies how to transport the data in the
EDHOC + OSCORE request and their processing order.  In particular,
the use of this approach is explicitly signalled by including an
EDHOC Option (see edhoc-option) in the EDHOC + OSCORE request.  The
processing of the EDHOC + OSCORE request is specified in client-
processing for the Client side and in server-processing for the
Server side.
This section defines the EDHOC Option.  The option is used in a CoAP
request, to signal that the request payload conveys both an EDHOC
message_3 and OSCORE protected data, combined together.
The approach defined in this specification consists of sending EDHOC
message_3 inside an OSCORE protected CoAP message.
The resulting EDHOC + OSCORE request is in practice the OSCORE
Request from fig-non-combined, sent to a protected resource and with
the correct CoAP method and options, with the addition that it also
transports EDHOC message_3.
Since EDHOC message_3 may be too large to be included in a CoAP
Option, e.g. if containing a large public key certificate chain, it
has to be transported through the CoAP payload.
The use of this approach is explicitly signalled by including an
EDHOC Option (see signalling) in the EDHOC + OSCORE request.
Signal the usage of this approach within the EDHOC + OSCORE
request, by including the new EDHOC Option defined in signalling.
When receiving an EDHOC + OSCORE request, the Server performs the
following steps.
Check the presence of the EDHOC option defined in signalling, to
determine that the received request is an EDHOC + OSCORE request.
If this is the case, the Server continues with the steps defined
below.
Signal the usage of this approach within the EDHOC + OSCORE
request, by including the new EDHOC Option defined in edhoc-
option.
When receiving a request containing the EDHOC option, i.e. an EDHOC +
OSCORE request, the Server MUST perform the following steps.
Check that the payload of the EDHOC + OSCORE request is a CBOR
sequence composed of two CBOR byte strings.  If this is not the
case, the Server MUST stop processing the request and MUST respond
with a 4.00 (Bad Request) error message.
If the applicability statement used in the EDHOC session specifies
that EDHOC message_4 shall be sent, the Server MUST stop the EDHOC
processing and consider it failed, as due to a client error.
MUST have Content-Format set to application/edhoc defined in
Section 9.5 of I-D.ietf-lake-edhoc.
MUST specify a CoAP error response code, i.e. 4.00 (Bad Request)
in case of client error (e.g. due to a malformed EDHOC message_3),
or 5.00 (Internal Server Error) in case of server error (e.g. due
to failure in deriving EDHOC key material).
The OSCORE Sender ID of the Client is 0x20.  This corresponds to
the EDHOC Connection Identifier C_R, which is encoded as the
bstr_identifier 0x08 in EDHOC message_3.
The EDHOC option is registered with CoAP option number 13.
If step 4 (EDHOC processing) fails, the server discontinues the
protocol as per Section 5.4.3 of I-D.ietf-lake-edhoc and responds
with an EDHOC error message, formatted as defined in Section 6.1 of
I-D.ietf-lake-edhoc.  In particular, the CoAP response conveying the
EDHOC error message MUST have Content-Format set to application/edhoc
defined in Section 9.5 of I-D.ietf-lake-edhoc.
The OSCORE Sender ID of the Client is 0x00.  This corresponds to
the EDHOC Connection Identifier C_R, which is encoded as the
bstr_identifier 0x37 in EDHOC message_3.
The EDHOC option is registered with CoAP option number 21.
RFC Editor: Please replace "" with the RFC number of
this document and delete this paragraph.
This document suggests 21 (TBD21) as option number to be assigned to
the new EDHOC option, since both 13 and 21 are consistent for the use
case in question, but different use cases or protocols may make
better use of the option number 13.