draft-palombini-core-oscore-edhoc-01.txt | draft-palombini-core-oscore-edhoc-02.txt | |||
---|---|---|---|---|
CoRE Working Group F. Palombini | CoRE Working Group F. Palombini | |||
Internet-Draft Ericsson | Internet-Draft Ericsson | |||
Intended status: Standards Track M. Tiloca | Intended status: Standards Track M. Tiloca | |||
Expires: 6 May 2021 R. Hoeglund | Expires: August 23, 2021 R. Hoeglund | |||
RISE AB | RISE AB | |||
S. Hristozov | S. Hristozov | |||
Fraunhofer AISEC | Fraunhofer AISEC | |||
G. Selander | G. Selander | |||
Ericsson | Ericsson | |||
2 November 2020 | February 19, 2021 | |||
Combining EDHOC and OSCORE | Combining EDHOC and OSCORE | |||
draft-palombini-core-oscore-edhoc-01 | draft-palombini-core-oscore-edhoc-02 | |||
Abstract | Abstract | |||
This document defines possible optimization approaches for combining | This document defines an optimization approach for combining the | |||
the lightweight authenticated key exchange protocol EDHOC run over | lightweight authenticated key exchange protocol EDHOC run over CoAP | |||
CoAP with the first subsequent OSCORE transaction. This combination | with the first subsequent OSCORE transaction. This combination | |||
reduces the number of round trips required to set up an OSCORE | reduces the number of round trips required to set up an OSCORE | |||
Security Context and complete an OSCORE transaction using that | Security Context and to complete an OSCORE transaction using that | |||
context. | Security Context. | |||
Discussion Venues | ||||
This note is to be removed before publishing as an RFC. | ||||
Source for this draft and an issue tracker can be found at | ||||
https://github.com/EricssonResearch/oscore-edhoc | ||||
(https://github.com/EricssonResearch/oscore-edhoc). | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 6 May 2021. | This Internet-Draft will expire on August 23, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Simplified BSD License text | to this document. Code Components extracted from this document must | |||
as described in Section 4.e of the Trust Legal Provisions and are | include Simplified BSD License text as described in Section 4.e of | |||
provided without warranty as described in the Simplified BSD License. | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. EDHOC in OSCORE . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. EDHOC Option . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. Signalling in a New EDHOC Option . . . . . . . . . . . . 6 | 4. EDHOC Combined with OSCORE . . . . . . . . . . . . . . . . . 6 | |||
3.2. Signalling in the OSCORE Option . . . . . . . . . . . . . 8 | 4.1. Client Processing . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 4.2. Server Processing . . . . . . . . . . . . . . . . . . . . 7 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 5. Example of EDHOC + OSCORE Request . . . . . . . . . . . . . . 9 | |||
6. Normative References . . . . . . . . . . . . . . . . . . . . 9 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | 7.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 10 | |||
8. Normative References . . . . . . . . . . . . . . . . . . . . 10 | ||||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
1. Introduction | 1. Introduction | |||
This document presents possible optimization approaches to combine | This document defines an optimization approach to combine the | |||
the lightweight authenticated key exchange protocol EDHOC | lightweight authenticated key exchange protocol EDHOC | |||
[I-D.ietf-lake-edhoc], when running over CoAP [RFC7252], with the | [I-D.ietf-lake-edhoc], when running over CoAP [RFC7252], with the | |||
first subsequent OSCORE [RFC8613] transaction. | first subsequent OSCORE [RFC8613] transaction. | |||
This allows for a minimum number of round trips necessary to setup | This allows for a minimum number of round trips necessary to setup | |||
the OSCORE Security Context and complete an OSCORE transaction, for | the OSCORE Security Context and complete an OSCORE transaction, for | |||
example when an IoT device gets configured in a network for the first | example when an IoT device gets configured in a network for the first | |||
time. | time. | |||
The number of protocol round trips impacts the minimum number of | This optimization is desirable, since the number of protocol round | |||
flights, which can have a substantial impact on performance with | trips impacts the minimum number of flights, which in turn can have a | |||
certain radio technologies. | 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 | Without this optimization, it is not possible, not even in theory, to | |||
achieve the minimum number of flights. This optimization makes it | achieve the minimum number of flights. This optimization makes it | |||
possible also in practice, since the last message of the EDHOC | possible also in practice, since the last message of the EDHOC | |||
protocol can be made relatively small (see Section 1 of | protocol can be made relatively small (see Section 1 of | |||
[I-D.ietf-lake-edhoc]), thus allowing additional OSCORE protected | [I-D.ietf-lake-edhoc]), thus allowing additional OSCORE protected | |||
CoAP data within target MTU sizes. | CoAP data within target MTU sizes. | |||
The goal of this document is to provide details on different | ||||
alternatives for transporting and processing the necessary data, | ||||
gather opinions on the different approaches, and select only one of | ||||
those. | ||||
1.1. Terminology | 1.1. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
The reader is expected to be familiar with terms and concepts defined | The reader is expected to be familiar with terms and concepts defined | |||
in CoAP [RFC7252], CBOR [I-D.ietf-cbor-7049bis], OSCORE [RFC8613] and | in CoAP [RFC7252], CBOR [RFC8949], CBOR sequences [RFC8742], OSCORE | |||
EDHOC [I-D.ietf-lake-edhoc]. | [RFC8613] and EDHOC [I-D.ietf-lake-edhoc]. | |||
2. Background | 2. Background | |||
EDHOC is a 3-message key exchange protocol. Section 7.1 of | 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 | [I-D.ietf-lake-edhoc] specifies how to transport EDHOC over CoAP: the | |||
EDHOC data (referred to as "EDHOC messages") are transported in the | EDHOC data (referred to as "EDHOC messages") are transported in the | |||
payload of CoAP requests and responses. | payload of CoAP requests and responses. | |||
This draft deals with the case of the Initiator acting as CoAP Client | This draft deals with the case of the Initiator acting as CoAP Client | |||
and the Responder acting as CoAP Server. (The case of the Initiator | and the Responder acting as CoAP Server; instead, the case of the | |||
acting as CoAP server cannot be optimized in this way.) That is, the | Initiator acting as CoAP Server cannot be optimized by using this | |||
CoAP Client sends a POST request containing the EDHOC message 1 to a | approach. | |||
reserved resource at the CoAP Server. This triggers the EDHOC | ||||
exchange on the CoAP Server, which replies with a 2.04 (Changed) | That is, the CoAP Client sends a POST request containing EDHOC | |||
Response containing the EDHOC message 2. Finally, the EDHOC message | message_1 to a reserved resource at the CoAP Server. This triggers | |||
3 is sent by the CoAP Client in a CoAP POST request to the same | the EDHOC exchange on the CoAP Server, which replies with a 2.04 | |||
resource used for the EDHOC message 1. The Content-Format of these | (Changed) Response containing EDHOC message_2. Finally, the CoAP | |||
CoAP messages is set to "application/edhoc". | 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 | After this exchange takes place, and after successful verifications | |||
specified in the EDHOC protocol, the Client and Server derive the | specified in the EDHOC protocol, the Client and Server derive the | |||
OSCORE Security Context, as specified in Section 7.1.1 of | OSCORE Security Context, as specified in Section 7.2.1 of | |||
[I-D.ietf-lake-edhoc]. Then, they are ready to use OSCORE. | [I-D.ietf-lake-edhoc]. Then, they are ready to use OSCORE. | |||
This sequential way of running EDHOC and then OSCORE is specified in | This sequential way of running EDHOC and then OSCORE is specified in | |||
Figure 1. As shown in the figure, this mechanism is executed in 3 | Figure 1. As shown in the figure, this mechanism takes 3 round trips | |||
round trips. | to complete. | |||
CoAP Client CoAP Server | CoAP Client CoAP Server | |||
| ------------- EDHOC message_1 ------------> | | | ------------- EDHOC message_1 ------------> | | |||
| | | | | | |||
| <------------ EDHOC message_2 ------------- | | | <------------ EDHOC message_2 ------------- | | |||
| | | | | | |||
EDHOC verification | | EDHOC verification | | |||
| | | | | | |||
| ------------- EDHOC message_3 ------------> | | | ------------- EDHOC message_3 ------------> | | |||
| | | | | | |||
| EDHOC verification | | EDHOC verification | |||
| | | | + | |||
OSCORE Sec Ctx OSCORE Sec Ctx | OSCORE Sec Ctx OSCORE Sec Ctx | |||
Derivation Derivation | Derivation Derivation | |||
| | | | | | |||
| -------------- OSCORE Request ------------> | | | ------------- OSCORE Request -------------> | | |||
| | | | | | |||
| <------------ OSCORE Response ------------- | | | <------------ OSCORE Response ------------- | | |||
| | | | | | |||
Figure 1: EDHOC and OSCORE run sequentially | Figure 1: EDHOC and OSCORE run sequentially | |||
The number of roundtrips can be minimized: after receiving the EDHOC | The number of roundtrips can be minimized as follows. Already after | |||
message 2, the CoAP Client has all the information needed to derive | receiving EDHOC message_2 and before sending EDHOC message_3, the | |||
the OSCORE Security Context before sending the EDHOC message 3. | 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 | This means that the Client can potentially send at the same time both | |||
the EDHOC message 3 and the subsequent OSCORE Request. On a semantic | EDHOC message_3 and the subsequent OSCORE Request. On a semantic | |||
level, this approach practically requires to send two separate REST | level, this approach practically requires to send two separate REST | |||
requests at the same time. | requests at the same time. | |||
The high level message flow of running EDHOC and OSCORE combined is | The high level message flow of running EDHOC and OSCORE combined is | |||
shown in Figure 2. | shown in Figure 2. | |||
Defining the specific details of how to transport the data and of | Defining the specific details of how to transport the data and of | |||
their processing order is the goal of this specification. | their processing order is the goal of this specification, as defined | |||
in Section 4. | ||||
CoAP Client CoAP Server | CoAP Client CoAP Server | |||
| ------------- EDHOC message_1 ------------> | | | ------------- EDHOC message_1 ------------> | | |||
| | | | | | |||
| <------------ EDHOC message_2 ------------- | | | <------------ EDHOC message_2 ------------- | | |||
| | | | | | |||
EDHOC verification + | | EDHOC verification | | |||
+ | | ||||
OSCORE Sec Ctx | | OSCORE Sec Ctx | | |||
Derivation | | Derivation | | |||
| | | | | | |||
| ------------- EDHOC message_3 ------------> | | | ---- EDHOC message_3 + OSCORE Request ----> | | |||
| + OSCORE Request | | ||||
| | | | | | |||
| EDHOC verification + | | EDHOC verification | |||
| + | ||||
| OSCORE Sec Ctx | | OSCORE Sec Ctx | |||
| Derivation | | Derivation | |||
| | | | | | |||
| <------------ OSCORE Response ------------- | | | <------------ OSCORE Response ------------- | | |||
| | | | | | |||
Figure 2: EDHOC and OSCORE combined | Figure 2: EDHOC and OSCORE combined | |||
3. EDHOC in OSCORE | 3. EDHOC Option | |||
This approach consists in sending the EDHOC message 3 inside an | This section defines the EDHOC Option, used in a CoAP request to | |||
OSCORE message (i.e., an OSCORE protected CoAP message). | signal that the request combines EDHOC message_3 and OSCORE protected | |||
data. | ||||
The resulting OSCORE + EDHOC request is in practice the OSCORE | The EDHOC Option has the properties summarized in Figure 3, which | |||
Request from Figure 1, sent to a protected resource and with the | extends Table 4 of [RFC7252]. The option is Critical, Safe-to- | |||
correct CoAP method and options, with the addition that it also | Forward, and part of the Cache-Key. The option MUST occur at most | |||
transports the EDHOC message 3. | once and is always empty. If any value is sent, the value is simply | |||
ignored. The option is intended only for CoAP requests and is of | ||||
Class U for OSCORE [RFC8613]. | ||||
As the 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 | | No. | C | U | N | R | Name | Format | Length | Default | | |||
would have to be transported in the CoAP payload. | +-------+---+---+---+---+-------+--------+--------+---------+ | |||
| TBD13 | x | | | | EDHOC | Empty | 0 | (none) | | ||||
+-------+---+---+---+---+-------+--------+--------+---------+ | ||||
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable | ||||
In particular, the payload of the OSCORE + EDHOC request is formatted | Figure 3: The EDHOC Option. | |||
as a CBOR sequence of two CBOR byte strings: the EDHOC message 3 and | ||||
the OSCORE ciphertext of the original OSCORE Request, in this order, | ||||
both encoded as CBOR byte strings. | ||||
Note that the OSCORE ciphertext is not computed over the EDHOC | The presence of this option means that the message payload contains | |||
message 3, which is not protected by OSCORE. That is, the client | also EDHOC data, that must be extracted and processed as defined in | |||
first prepares the OSCORE Request as in Figure 1. Then, it reformats | Section 4.2, before the rest of the message can be processed. | |||
the payload to include also the EDHOC message 3, as defined above. | ||||
The result is the OSCORE + EDHOC request to send. | ||||
The usage of this approach is indicated by a signalling information | Figure 4 shows the format of a CoAP message containing both the EDHOC | |||
in the OSCORE + EDHOC request, which can be either a new EDHOC Option | data and the OSCORE ciphertext, using the newly defined EDHOC option | |||
(see Section 3.1) or the OSCORE Option with a particular Flag Bit set | for signalling. | |||
(see Section 3.2). | ||||
When receiving such a request, the Server needs to perform the | 0 1 2 3 | |||
following processing, in addition to the EDHOC, OSCORE and CoAP | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
processing: | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|Ver| T | TKL | Code | Message ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Token (if any, TKL bytes) ... | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| OSCORE option | EDHOC option | other options (if any) ... | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|1 1 1 1 1 1 1 1| Payload | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
1. Check the signalling information to identify that this is an | Figure 4: CoAP message for EDHOC and OSCORE combined - signalled with | |||
OSCORE + EDHOC request. | the EDHOC Option | |||
2. Extract the EDHOC message 3 from the payload of the OSCORE + | 4. EDHOC Combined with OSCORE | |||
EDHOC request, as the value of the first CBOR byte string in the | ||||
CBOR sequence. | ||||
3. Execute the EDHOC processing on the EDHOC message 3, including | The approach defined in this specification consists of sending EDHOC | |||
verifications and the OSCORE Security Context derivation. | message_3 inside an OSCORE protected CoAP message. | |||
4. Extract the OSCORE ciphertext from the payload of the OSCORE + | The resulting EDHOC + OSCORE request is in practice the OSCORE | |||
EDHOC request, as the value of the second CBOR byte string in the | Request from Figure 1, sent to a protected resource and with the | |||
CBOR sequence. Then, set the CoAP payload of the request to the | correct CoAP method and options, with the addition that it also | |||
extracted ciphertext. | transports EDHOC message_3. | |||
5. Decrypt and verify the OSCORE protected CoAP request resulting | Since EDHOC message_3 may be too large to be included in a CoAP | |||
from step 4, as defined by OSCORE. | Option, e.g. if containing a large public key certificate chain, it | |||
has to be transported through the CoAP payload. | ||||
6. Process the CoAP request resulting from step 5. | The use of this approach is explicitly signalled by including an | |||
EDHOC Option (see Section 3) in the EDHOC + OSCORE request. | ||||
The following sections expand on the two ways of signalling that the | 4.1. Client Processing | |||
EDHOC message is transported in the OSCORE message. | ||||
3.1. Signalling in a New EDHOC Option | The Client prepares an EDHOC + OSCORE request as follows. | |||
One way to signal that the Server has to extract and process the | 1. Compose EDHOC message_3 as per Section 5.4.2 of | |||
EDHOC message 3 before processing the OSCORE protected CoAP request | [I-D.ietf-lake-edhoc]. | |||
is to define a new CoAP Option, called the EDHOC Option. | ||||
The presence of this option means that the message contains EDHOC | Since the Client is the EDHOC Initiator and the used Correlation | |||
data in the payload, that must be extracted and processed before the | Method is 1 (see Section 3.2.4 of [I-D.ietf-lake-edhoc]), the | |||
rest of the message can be processed. | 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]). | ||||
In particular, the EDHOC message 3 has to be extracted from the CoAP | 2. Encrypt the original CoAP request as per Section 8.1 of | |||
payload, as the first element of a CBOR sequence wrapped in a CBOR | [RFC8613], using the new OSCORE Security Context established | |||
byte string. | after receiving EDHOC message_2. | |||
The Option is critical, Safe-to-Forward, and part of the Cache-Key. | Note that the OSCORE ciphertext is not computed over EDHOC | |||
message_3, which is not protected by OSCORE. That is, the result | ||||
of this step is the OSCORE Request as in Figure 1. | ||||
The Option value is always empty. If any value is sent, the value is | 3. Build a CBOR sequence [RFC8742] composed of two CBOR byte strings | |||
simply ignored. | in the following order. | |||
The Option MUST occur at most once. | * The first CBOR byte string is the CIPHERTEXT_3 of the EDHOC | |||
message_3 resulting from step 3. | ||||
The Option is of Class U for OSCORE. | * The second CBOR byte string has as value the OSCORE ciphertext | |||
of the OSCORE protected CoAP request resulting from step 2. | ||||
Figure 3 shows the format for a CoAP message containing both the | 4. Compose the EDHOC + OSCORE request, as the OSCORE protected CoAP | |||
OSCORE ciphertext and EDHOC message 3, using the newly defined EDHOC | request resulting from step 2, where the payload is replaced with | |||
option for signaling. | the CBOR sequence built at step 3. | |||
0 1 2 3 | 5. Signal the usage of this approach within the EDHOC + OSCORE | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | request, by including the new EDHOC Option defined in Section 3. | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|Ver| T | TKL | Code | Message ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Token (if any, TKL bytes) ... | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| OSCORE option | EDHOC option | other options (if any) ... | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|1 1 1 1 1 1 1 1| Payload | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 3: CoAP message for EDHOC and OSCORE combined - signaled | 4.2. Server Processing | |||
with the EDHOC Option | ||||
An example based on the OSCORE test vector from Appendix C.4 of | When receiving an EDHOC + OSCORE request, the Server performs the | |||
[RFC8613] and the EDHOC test vector from Appendix B.2 of | following steps. | |||
[I-D.ietf-lake-edhoc] is given in Figure 4. The example assumes that | ||||
the EDHOC option is registered with CoAP option number 13. | ||||
o OSCORE option value: 0x0914 (2 bytes) | 1. Check the presence of the EDHOC option defined in Section 3, to | |||
determine that the received request is an EDHOC + OSCORE request. | ||||
If this is the case, the Server continues with the steps defined | ||||
below. | ||||
o ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes) | 2. Extract CIPHERTEXT_3 from the payload of the EDHOC + OSCORE | |||
request, as the first CBOR byte string in the CBOR sequence. | ||||
o EDHOC option value: - (0 bytes) | 3. Rebuild EDHOC message_3, as a CBOR sequence composed of two CBOR | |||
byte strings in the following order. | ||||
o EDHOC message 3: 085253c3991999a5ffb86921e99b607c067770e0 | * The first CBOR byte string is the 'kid' of the Client | |||
(20 bytes) | 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]). | ||||
From there: | * The second CBOR byte string is the CIPHERTEXT_3 retrieved at | |||
step 2. | ||||
o Protected CoAP request (OSCORE message): 0x44025d1f0000397439 | 4. Perform the EDHOC processing on the EDHOC message_3 rebuilt at | |||
6c6f63616c686f737462 0914 04 ff 54085253C3991999A5FFB86921E99 | step 3, including verifications, and the OSCORE Security Context | |||
B607C067770E0 4d612f1092f1776f1c1668b3825e (58 bytes) | derivation, as per Section 5.4.3 and Section 7.2.1 of | |||
[I-D.ietf-lake-edhoc], respectively. | ||||
Figure 4: CoAP message for EDHOC and OSCORE combined - signaled | 5. Extract the OSCORE ciphertext from the payload of the EDHOC + | |||
with the EDHOC Option | OSCORE request, as the value of the second CBOR byte string in | |||
the CBOR sequence. | ||||
3.2. Signalling in the OSCORE Option | 6. Rebuild the OSCORE protected CoAP request as the EDHOC + OSCORE | |||
request, where the payload is replaced with the OSCORE ciphertext | ||||
resulting from step 5. | ||||
Another way to signal that the EDHOC message 3 is to be extracted | 7. Decrypt and verify the OSCORE protected CoAP request resulting | |||
from the CoAP payload as the first element of a CBOR sequence wrapped | from step 6, as per Section 8.2 of [RFC8613], by using the new | |||
in a CBOR byte string, and that the processing defined in Section 3 | OSCORE Security Context established at step 4. | |||
is to be executed, is to use one of the OSCORE Flag Bits of the | ||||
OSCORE Option. | ||||
Bit Position: 1 | 8. Process the CoAP request resulting from step 7. | |||
Name: 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. | ||||
Description: Set to 1 if the payload is a sequence of EDHOC message 3 | If step 4 (EDHOC processing) fails, the server discontinues the | |||
and OSCORE ciphertext. | protocol as per Section 5.4.3 of [I-D.ietf-lake-edhoc] and sends 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: | ||||
Reference: this document | o MUST have Content-Format set to application/edhoc defined in | |||
Section 9.5 of [I-D.ietf-lake-edhoc]. | ||||
The OSCORE Option value with the EDHOC bit set is given in Figure 5. | o 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). | ||||
0 1 2 3 4 5 6 7 <------------- n bytes --------------> | If step 4 (EDHOC processing) is successfully completed but step 7 | |||
+-+-+-+-+-+-+-+-+-------------------------------------- | (OSCORE processing) fails, the same OSCORE error handling applies as | |||
|0|1|0|h|k| n | Partial IV (if any) ... | defined in Section 8.2 of [RFC8613]. | |||
+-+-+-+-+-+-+-+-+-------------------------------------- | ||||
<- 1 byte -> <----- s bytes ------> | 5. Example of EDHOC + OSCORE Request | |||
+------------+----------------------+------------------+ | ||||
| s (if any) | kid context (if any) | kid (if any) ... | | ||||
+------------+----------------------+------------------+ | ||||
Figure 5: The OSCORE Option Value with the EDHOC bit set | An example based on the OSCORE test vector from Appendix C.4 of | |||
[RFC8613] and the EDHOC test vector from Appendix B.2 of | ||||
[I-D.ietf-lake-edhoc] is given in Figure 5. In particular, the | ||||
example assumes that: | ||||
Figure 6 shows the format for a CoAP message containing both the | o The used OSCORE Partial IV is 0, consistently with the first | |||
OSCORE ciphertext and EDHOC message 3, using the Flag Bit 1 in the | request protected with the new OSCORE Security Context. | |||
OSCORE Option for signaling. | ||||
0 1 2 3 | o The OSCORE Sender ID of the Client is 0x20. This corresponds to | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | the EDHOC Connection Identifier C_R, which is encoded as the | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | bstr_identifier 0x08 in EDHOC message_3. | |||
|Ver| T | TKL | Code | Message ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Token (if any, TKL bytes) ... | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| OSCORE opt (with EDHOC bit set) | other options (if any) ... | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|1 1 1 1 1 1 1 1| Payload | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 6: CoAP message for EDHOC and OSCORE combined - signaled | ||||
within the OSCORE option | ||||
An example based on the OSCORE test vector from Appendix C.4 of | o The EDHOC option is registered with CoAP option number 13. | |||
[RFC8613] and the EDHOC test vector from Appendix B.2 of | ||||
[I-D.ietf-lake-edhoc] is given in Figure 7. | ||||
o OSCORE option value without EDHOC bit set: 0x0914 (2 bytes) | o OSCORE option value: 0x090020 (3 bytes) | |||
o OSCORE option value with EDHOC bit set: 0x4914 (2 bytes) | o EDHOC option value: - (0 bytes) | |||
o ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes) | o C_R: 0x20 (1 byte) | |||
o EDHOC message 3: 085253c3991999a5ffb86921e99b607c067770e0 | o CIPHERTEXT_3: 0x5253c3991999a5ffb86921e99b607c067770e0 | |||
(19 bytes) | ||||
o EDHOC message_3: 0x08 5253c3991999a5ffb86921e99b607c067770e0 | ||||
(20 bytes) | (20 bytes) | |||
o OSCORE ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes) | ||||
From there: | From there: | |||
o Protected CoAP request (OSCORE message): 0x44025d1f000039743 | o Protected CoAP request (OSCORE message): | |||
96c6f63616c686f737462 4914 ff 54085253C3991999A5FFB86921E99B | ||||
607C067770E0 4d612f1092f1776f1c1668b3825e (58 bytes) | ||||
Figure 7: CoAP message for EDHOC and OSCORE combined - signaled | 0x44025d1f ; CoAP 4-byte header | |||
within the OSCORE Option | 00003974 ; Token | |||
39 6c6f63616c686f7374 ; Uri-Host Option: "localhost" | ||||
63 090020 ; OSCORE Option | ||||
40 ; EDHOC Option | ||||
ff 5253c3991999a5ffb86921e99b607c067770e0 | ||||
4d612f1092f1776f1c1668b3825e | ||||
(57 bytes) | ||||
4. Security Considerations | Figure 5: Example of CoAP message with EDHOC and OSCORE combined | |||
6. Security Considerations | ||||
The same security considerations from OSCORE [RFC8613] and EDHOC | The same security considerations from OSCORE [RFC8613] and EDHOC | |||
[I-D.ietf-lake-edhoc] hold for this document. | [I-D.ietf-lake-edhoc] hold for this document. | |||
TODO (more considerations) | TODO (more considerations) | |||
5. IANA Considerations | 7. IANA Considerations | |||
Depending on the option chosen, this document will either register a | This document has the following actions for IANA. | |||
new CoAP Option number to the CoAP Option Number registry, or a new | ||||
bit to the OSCORE Flag Bits registry. | ||||
6. Normative References | 7.1. CoAP Option Numbers Registry | |||
[I-D.ietf-cbor-7049bis] | IANA is asked to enter the following option numbers to the "CoAP | |||
Bormann, C. and P. Hoffman, "Concise Binary Object | Option Numbers" registry defined in [RFC7252] within the "CoRE | |||
Representation (CBOR)", Work in Progress, Internet-Draft, | Parameters" registry. | |||
draft-ietf-cbor-7049bis-16, 30 September 2020, | ||||
<http://www.ietf.org/internet-drafts/draft-ietf-cbor- | [ | |||
7049bis-16.txt>. | ||||
The CoAP option numbers 13 and 21 are both consistent with the | ||||
properties of the EDHOC Option defined in Section 3, and they both | ||||
allow the EDHOC Option to always result in an overall size of 1 byte. | ||||
This is because: | ||||
o The EDHOC option is always empty, i.e. with zero-length value; and | ||||
o Since the OSCORE option with option number 9 is always present in | ||||
the CoAP request, the EDHOC option would be encoded with a maximum | ||||
delta of 4 or 12, depending on its option number being 13 or 21. | ||||
At the time of writing, the CoAP option numbers 13 and 21 are both | ||||
unassigned in the "CoAP Option Numbers" registry, as first available | ||||
and consistent option numbers for the EDHOC option. | ||||
] | ||||
+--------+-------+-------------------+ | ||||
| Number | Name | Reference | | ||||
+--------+-------+-------------------+ | ||||
| TBD13 | EDHOC | [[this document]] | | ||||
+--------+-------+-------------------+ | ||||
8. Normative References | ||||
[I-D.ietf-lake-edhoc] | [I-D.ietf-lake-edhoc] | |||
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral | Selander, G., Mattsson, J., and F. Palombini, "Ephemeral | |||
Diffie-Hellman Over COSE (EDHOC)", Work in Progress, | Diffie-Hellman Over COSE (EDHOC)", draft-ietf-lake- | |||
Internet-Draft, draft-ietf-lake-edhoc-01, 2 August 2020, | edhoc-03 (work in progress), December 2020. | |||
<http://www.ietf.org/internet-drafts/draft-ietf-lake- | ||||
edhoc-01.txt>. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | |||
Application Protocol (CoAP)", RFC 7252, | Application Protocol (CoAP)", RFC 7252, | |||
DOI 10.17487/RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
<https://www.rfc-editor.org/info/rfc7252>. | <https://www.rfc-editor.org/info/rfc7252>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, | [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, | |||
"Object Security for Constrained RESTful Environments | "Object Security for Constrained RESTful Environments | |||
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, | (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, | |||
<https://www.rfc-editor.org/info/rfc8613>. | <https://www.rfc-editor.org/info/rfc8613>. | |||
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) | ||||
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, | ||||
<https://www.rfc-editor.org/info/rfc8742>. | ||||
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object | ||||
Representation (CBOR)", STD 94, RFC 8949, | ||||
DOI 10.17487/RFC8949, December 2020, | ||||
<https://www.rfc-editor.org/info/rfc8949>. | ||||
Acknowledgments | Acknowledgments | |||
The authors sincerely thank Christian Amsuess, Klaus Hartke, Jim | The authors sincerely thank Christian Amsuess, Klaus Hartke, Jim | |||
Schaad and Malisa Vucinic for their feedback and comments in the | Schaad and Malisa Vucinic for their feedback and comments in the | |||
discussion leading up to this draft. | discussion leading up to this draft. | |||
The work on this document has been partly supported by VINNOVA and | The work on this document has been partly supported by VINNOVA and | |||
the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home | the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home | |||
(Grant agreement 952652). | (Grant agreement 952652). | |||
Authors' Addresses | Authors' Addresses | |||
Francesca Palombini | Francesca Palombini | |||
Ericsson | Ericsson | |||
Email: francesca.palombini@ericsson.com | Email: francesca.palombini@ericsson.com | |||
Marco Tiloca | Marco Tiloca | |||
RISE AB | RISE AB | |||
Isafjordsgatan 22 | Isafjordsgatan 22 | |||
SE-16440 Stockholm Kista | Kista SE-16440 Stockholm | |||
Sweden | Sweden | |||
Email: marco.tiloca@ri.se | Email: marco.tiloca@ri.se | |||
Rikard Hoeglund | Rikard Hoeglund | |||
RISE AB | RISE AB | |||
Isafjordsgatan 22 | Isafjordsgatan 22 | |||
SE-16440 Stockholm Kista | Kista SE-16440 Stockholm | |||
Sweden | Sweden | |||
Email: rikard.hoglund@ri.se | Email: rikard.hoglund@ri.se | |||
Stefan Hristozov | Stefan Hristozov | |||
Fraunhofer AISEC | Fraunhofer AISEC | |||
Email: stefan.hristozov@aisec.fraunhofer.de | Email: stefan.hristozov@aisec.fraunhofer.de | |||
Goeran Selander | Goeran Selander | |||
End of changes. 89 change blocks. | ||||
225 lines changed or deleted | 271 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |