Draft: draft-ietf-core-oscore-edhoc

Commentary: This PR builds on the comment at : Section 5.2 , Appendix A and Appendix B are marked as intended to be moved to lake - edhoc . Appendix A.2 has also notes about the need to merge its content with the content in Section 7.2 of lake - edhoc-07 The rest of the document is restored to be focused on the EDHOC + OSCORE combination . 
 - Please have a look :-)
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.
This optimization is desirable, since the number of protocol round
trips impacts the minimum number of flights, which in turn can have a
substantial impact on the latency of conveying the first OSCORE
request, when using certain radio technologies.
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.
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.
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.  In particular, EDHOC messages can
be transported over the Constrained Application Protocol (CoAP)
RFC7252 and used for establishing a Security Context for Object
Security for Constrained RESTful Environments (OSCORE) RFC8613.
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.
This optimization is desirable, since the number of protocol round
trips impacts on the minimum number of flights, which in turn can
have a substantial impact on the latency of conveying the first
OSCORE request, when using certain radio technologies.
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.
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.
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.
Appendix A.3 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.
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.
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 Appendix A.2 of I-D.ietf-
lake-edhoc.  After that, they can use OSCORE to protect their
communications.
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 one based on the application hash
algorithm of the selected cipher suite for the EDHOC session.  For
example, if SHA-256 is the application hash algorithm of the
selected ciphersuite, HKDF SHA-256 is used as HKDF Algorithm in
the OSCORE Security Context.
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 numeric C_R of 10 corresponds to a (typically client)
Sender ID of hexadecimal '0a', and a numeric C_R of -12 to
hexadecimal '2b'.  Instead, 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).
Since the Client is the EDHOC Initiator and the used Correlation
Method is 1 (see Section 3.2.4 of I-D.ietf-lake-edhoc), the EDHOC
message_3 always includes the Connection Identifier C_R and
CIPHERTEXT_3.  Note that C_R is the OSCORE Sender ID of the
Client, encoded as a bstr_identifier (see Section 5.1 of I-D.ietf-
lake-edhoc).
Since the Client is the EDHOC Initiator, the EDHOC message_3
always includes the connection identifier C_R and CIPHERTEXT_3.
Note that C_R is the OSCORE Sender ID of the Client, encoded as
per oscore-to-edhoc-id.
When receiving a request containing the EDHOC option, i.e. an EDHOC +
OSCORE request, the Server MUST perform the following steps.
When receiving a request containing the EDHOC option, i.e., an EDHOC
+ OSCORE request, the Server MUST perform the following steps.
The first CBOR byte string is the 'kid' of the Client indicated
in the OSCORE option of the EDHOC + OSCORE request, encoded as
a bstr_identifier (see Section 5.1 of I-D.ietf-lake-edhoc).
Perform the EDHOC processing on the EDHOC message_3 rebuilt at
step 3, including verifications, and the OSCORE Security Context
derivation, as per Section 5.4.3 and Section 7.2.1 of I-D.ietf-
lake-edhoc, respectively.
The first CBOR byte string is the 'kid' of the Client indicated
in the OSCORE option of the EDHOC + OSCORE request (i.e., the
OSCORE Sender ID of the Client), encoded as per oscore-to-
edhoc-id.
Perform the EDHOC processing on the EDHOC message_3 rebuilt at
step 3, including verifications as per Section 5.4.3 of I-D.ietf-
lake-edhoc and the OSCORE Security Context derivation as per
Appendix A.2 of I-D.ietf-lake-edhoc.
If steps 4 (EDHOC processing) and 7 (OSCORE processing) are both
successfully completed, the Server MUST reply with an OSCORE
protected response, in order for the Client to achieve key
confirmation (see Section 5.4.2 of I-D.ietf-lake-edhoc).  The usage
of EDHOC message_4 as defined in Section 7.1 of I-D.ietf-lake-edhoc
is not applicable to the approach defined in this specification.
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 numeric EDHOC Connection Identifier C_R, which in EDHOC
message_3 is encoded as the CBOR integer 0, hence as 0x00.
If steps 4 (EDHOC processing) and 7 (OSCORE processing) are both
successfully completed, the Server MUST reply with an OSCORE
protected response, in order for the Client to achieve key
confirmation (see Section 5.4.2 of I-D.ietf-lake-edhoc).  The usage
of EDHOC message_4 as defined in Section 5.5 of I-D.ietf-lake-edhoc
is not applicable to the approach defined in this document.
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.2 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 8.9 of I-D.ietf-lake-edhoc.
The OSCORE Sender ID of the Client is 0x00.  This corresponds to
the numeric EDHOC connection identifier C_R with value 0, which in
EDHOC message_3 is encoded as the CBOR integer 0, hence as 0x00.