From 8fb9d401edee7b51a57bfadd9418f72b52c21a35 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 18:41:51 +0100 Subject: [PATCH 01/19] Acknowledgments --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index e1b2ead..a8a883d 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -721,6 +721,6 @@ Expert reviewers should take into consideration the following points: # Acknowledgments {:numbered="false"} -The authors sincerely thank {{{Christian Amsüss}}}, {{{Carsten Bormann}}}, {{{Esko Dijk}}}, {{{Klaus Hartke}}}, {{{John Preuß Mattsson}}}, {{{David Navarro}}}, {{{Jim Schaad}}}, {{{Mališa Vučinić}}}, and {{{Paul Wouters}}} for their feedback and comments. +The authors sincerely thank {{{Christian Amsüss}}}, {{{Carsten Bormann}}}, {{{Esko Dijk}}}, {{{Wes Hardaker}}}, {{{Klaus Hartke}}}, {{{John Preuß Mattsson}}}, {{{David Navarro}}}, {{{Jim Schaad}}}, {{{Mališa Vučinić}}}, and {{{Paul Wouters}}} for their feedback and comments. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home (Grant agreement 952652). From c57f28af09dd5dcf8146007f48f39dfce030afe9 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 18:43:38 +0100 Subject: [PATCH 02/19] Editorial (removed "purely") --- draft-ietf-core-oscore-edhoc.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index a8a883d..b9555d6 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -159,7 +159,7 @@ OSCORE Sec Ctx | ~~~~~~~~~~~~~~~~~ {: #fig-non-combined title="EDHOC and OSCORE run sequentially. The optional message_4 is included in this example, without which that message needs no payload." artwork-align="center"} -As shown in {{fig-non-combined}}, this purely-sequential flow where EDHOC is run first and then OSCORE is used takes three round trips to complete. +As shown in {{fig-non-combined}}, this sequential flow where EDHOC is run first and then OSCORE is used takes three round trips to complete. {{edhoc-in-oscore}} defines an optimization for combining EDHOC with the first 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. @@ -169,7 +169,7 @@ This section defines an optimization for combining the EDHOC message exchange wi This approach can be used only if the default, forward message flow of EDHOC is used, i.e., when the client acts as Initiator and the server acts as Responder. That is, it cannot be used in the case with reversed roles as per the reverse message flow of EDHOC. -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. +When running the 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}}. @@ -298,7 +298,7 @@ In such a case, the OSCORE processing in step 2 of {{client-processing}} is perf * The client takes the additional following step between steps 3 and 4 of {{client-processing}}. - B. If the size of COMB_PAYLOAD exceeds MAX_UNFRAGMENTED_SIZE (see {{Section 4.1.3.4.2 of RFC8613}}), the client MUST stop processing the request and MUST abandon the Block-wise transfer. Then, the client can continue by switching to the purely sequential workflow shown in {{fig-non-combined}}. That is, the client first sends EDHOC message_3 prepended by the EDHOC Connection Identifier C_R encoded as per {{Section 3.3 of I-D.ietf-lake-edhoc}}, and then sends the OSCORE-protected CoAP request once the EDHOC execution is completed. + B. If the size of COMB_PAYLOAD exceeds MAX_UNFRAGMENTED_SIZE (see {{Section 4.1.3.4.2 of RFC8613}}), the client MUST stop processing the request and MUST abandon the Block-wise transfer. Then, the client can continue by switching to the sequential workflow shown in {{fig-non-combined}}. That is, the client first sends EDHOC message_3 prepended by the EDHOC Connection Identifier C_R encoded as per {{Section 3.3 of I-D.ietf-lake-edhoc}}, and then sends the OSCORE-protected CoAP request once the EDHOC execution is completed. The performance advantage of using the EDHOC + OSCORE request can be lost when used in combination with Block-wise transfers that rely on specific parameter values and block sizes. @@ -354,7 +354,7 @@ A. If Block-wise is present in the request, then process the Outer Block options As per {{Section 3.3.3 of I-D.ietf-lake-edhoc}}, this straightforwardly corresponds to the EDHOC connection identifier C_R 0x01. - As per {{Section 3.3.2 of I-D.ietf-lake-edhoc}}, when using the purely-sequential flow shown in {{fig-non-combined}}, the same C_R with value 0x01 would be encoded on the wire as the CBOR integer 1 (0x01 in CBOR encoding), and prepended to EDHOC message_3 in the payload of the second EDHOC request. + As per {{Section 3.3.2 of I-D.ietf-lake-edhoc}}, when using the sequential flow shown in {{fig-non-combined}}, the same C_R with value 0x01 would be encoded on the wire as the CBOR integer 1 (0x01 in CBOR encoding), and prepended to EDHOC message_3 in the payload of the second EDHOC request. * The EDHOC option is registered with CoAP option number 21. @@ -481,7 +481,7 @@ When using the optimized workflow in Figure 2, a minimum of 128-bit security aga * The Responder is authenticated with 128-bit security against online attacks. This is the sum of the 64-bit MACs in EDHOC message_2 and of the MAC in the AEAD of the first OSCORE-protected CoAP response. -With reference to the purely sequential workflow in {{fig-non-combined}}, the OSCORE request might have to undergo access control checks at the server, before being actually executed for accessing the target protected resource. The same MUST hold when the optimized workflow in {{fig-combined}} is used, i.e., when using the EDHOC + OSCORE request. +With reference to the sequential workflow in {{fig-non-combined}}, the OSCORE request might have to undergo access control checks at the server, before being actually executed for accessing the target protected resource. The same MUST hold when the optimized workflow in {{fig-combined}} is used, i.e., when using the EDHOC + OSCORE request. That is, the rebuilt OSCORE-protected application request from step 7 in {{server-processing}} MUST undergo the same access control checks that would be performed on a traditional OSCORE-protected application request sent individually as shown in {{fig-non-combined}}. From cb3cefbc552332b407a52698c526be18218cdc25 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 18:47:08 +0100 Subject: [PATCH 03/19] Editorial (the examples are successful executions of EDHOC) --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index b9555d6..a35993d 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -99,7 +99,7 @@ After successful processing of EDHOC message_3, both peers agree on a cryptograp {{Section A.2 of I-D.ietf-lake-edhoc}} specifies how to transfer EDHOC over CoAP. That is, the EDHOC data (i.e., the EDHOC message possibly with a prepended connection identifier) are transported in the payload of CoAP requests and responses. The default, forward message flow of EDHOC consists in the CoAP client acting as Initiator and the CoAP server acting as Responder (see {{Section A.2.1 of I-D.ietf-lake-edhoc}}). Alternatively, the two roles can be reversed, as per the reverse message flow of EDHOC (see {{Section A.2.2 of I-D.ietf-lake-edhoc}}). In the rest of this document, EDHOC messages are considered to be transferred over CoAP. -{{fig-non-combined}} shows a CoAP client and a CoAP server running EDHOC as Initiator and Responder, respectively. In particular, it extends Figure 18 from {{Section A.2.1 of I-D.ietf-lake-edhoc}}, by highlighting when the two peers perform EDHOC verification and establish the OSCORE Security Context, and by adding an exchange of OSCORE-protected CoAP messages after completing the EDHOC execution. +{{fig-non-combined}} shows a successful execution of EDHOC, with a CoAP client and a CoAP server running EDHOC as Initiator and Responder, respectively. In particular, it extends Figure 18 from {{Section A.2.1 of I-D.ietf-lake-edhoc}}, by highlighting when the two peers perform EDHOC verification and establish the OSCORE Security Context, and by adding an exchange of OSCORE-protected CoAP messages after completing the EDHOC execution. That is, the client sends a POST request to a reserved *EDHOC resource* at the server, by default at the Uri-Path "/.well-known/edhoc". The request payload consists of the CBOR simple value "true" (0xf5) concatenated with EDHOC message_1, which also includes the EDHOC connection identifier C_I of the client encoded as per {{Section 3.3 of I-D.ietf-lake-edhoc}}. The Content-Format of the request can be set to application/cid-edhoc+cbor-seq. From 6d7a4ab36159c64404925c2470ef7101b49d450c Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 18:50:18 +0100 Subject: [PATCH 04/19] Clarified where EDHOC C_R and EDHOC message_3 are transported --- draft-ietf-core-oscore-edhoc.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index a35993d..b45c8be 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -215,9 +215,11 @@ That is, the EDHOC + OSCORE request is composed of the following two parts combi * The OSCORE Request from {{fig-non-combined}}, which is also in this case sent to a protected resource, with the correct CoAP method and options intended for accessing that resource. -* EDHOC data consisting of the pair (C_R, EDHOC message_3) required for completing the EDHOC session. Note that, as specified in {{client-processing}}, C_R is transported in the OSCORE Option of the OSCORE Request rather than in the CoAP payload of the EDHOC + OSCORE request. +* EDHOC data consisting of the pair (C_R, EDHOC message_3) required for completing the EDHOC session, transported as follows: - Since EDHOC message_3 may be too large to be included in a CoAP Option, e.g., if conveying a large public key certificate chain as ID_CRED_I (see {{Section 3.5.3 of I-D.ietf-lake-edhoc}}) or if conveying large External Authorization Data as EAD_3 (see {{Section 3.8 of I-D.ietf-lake-edhoc}}), EDHOC message_3 has instead to be transported in the CoAP payload of the EDHOC + OSCORE request, as prepended to the payload of the OSCORE Request. + * C_R is the OSCORE Sender ID of the client and hence transported in the 'kid' field of the OSCORE Option (see {{Section 6.1 of RFC8613}}). Unlike in the sequential workflow shown in {{fig-non-combined}}, C_R is thus not transported in the payload of the EDHOC + OSCORE request. + + * EDHOC message_3 is transported in the payload of the EDHOC + OSCORE request prepended to the payload of the OSCORE Request. This is because EDHOC message_3 may be too large to be included in a CoAP Option, e.g., if conveying a large public key certificate chain as ID_CRED_I (see {{Section 3.5.3 of I-D.ietf-lake-edhoc}}) or if conveying large External Authorization Data as EAD_3 (see {{Section 3.8 of I-D.ietf-lake-edhoc}}). 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. From f401adda9d66eb909c30d5cb1e9337c2008eca65 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 18:53:24 +0100 Subject: [PATCH 05/19] Shown C_R in Figures 1 and 2 --- draft-ietf-core-oscore-edhoc.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index b45c8be..5c13b01 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -150,10 +150,12 @@ OSCORE Sec Ctx | | | | ---------------- OSCORE Request -----------------> | | Header: 0.02 (POST) | + | OSCORE: { ... ; kid: C_R } | | Payload: OSCORE-protected data | | | | <--------------- OSCORE Response ----------------- | | Header: 2.04 (Changed) | + | OSCORE: { ... } | | Payload: OSCORE-protected data | | | ~~~~~~~~~~~~~~~~~ @@ -195,6 +197,7 @@ EDHOC verification | | | | -------------- EDHOC + OSCORE Request ------------> | | Header: 0.02 (POST) | + | OSCORE: { ... ; kid: C_R } | | Payload: EDHOC message_3 + OSCORE-protected data | | | | EDHOC verification @@ -204,6 +207,7 @@ EDHOC verification | | | | <--------------- OSCORE Response ------------------ | | Header: 2.04 (Changed) | + | OSCORE: { ... } | | Payload: OSCORE-protected data | | | ~~~~~~~~~~~~~~~~~ From da59032d18bd9c64bb8af1265b5190a25c76ee5a Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 18:56:38 +0100 Subject: [PATCH 06/19] Note on where C_R is transported --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index 5c13b01..8172594 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -107,7 +107,7 @@ This triggers the EDHOC execution at the server, which replies with a 2.04 (Chan Finally, the client sends a POST request to the same EDHOC resource used earlier when it sent EDHOC message_1. The request payload consists of the EDHOC connection identifier C_R encoded as per {{Section 3.3 of I-D.ietf-lake-edhoc}}, concatenated with EDHOC message_3. The Content-Format of the request can be set to application/cid-edhoc+cbor-seq. -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 {{Section A.1 of I-D.ietf-lake-edhoc}}. After that, they can use OSCORE to protect their communications as per {{RFC8613}}. +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 {{Section A.1 of I-D.ietf-lake-edhoc}}. After that, they can use OSCORE to protect their communications as per {{RFC8613}}. Note that the EDHOC Connection Identifier C_R is used as OSCORE Sender ID of the client (see {{Section A.1 of I-D.ietf-lake-edhoc}}). Therefore, C_R is transported in the 'kid' field of the OSCORE Option of the OSCORE Request (see {{Section 6.1 of RFC8613}}). The client and server are required to agree in advance on certain information and parameters describing how they should use EDHOC. These are specified in an application profile associated with the EDHOC resource addressed (see {{Section 3.9 of I-D.ietf-lake-edhoc}}. From 3d9d55227a6317c281dc785355f819de8741ee02 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 18:59:20 +0100 Subject: [PATCH 07/19] Ensuring the advantage of Block-wise transfers is for application policies --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index 8172594..d8556df 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -306,7 +306,7 @@ In such a case, the OSCORE processing in step 2 of {{client-processing}} is perf B. If the size of COMB_PAYLOAD exceeds MAX_UNFRAGMENTED_SIZE (see {{Section 4.1.3.4.2 of RFC8613}}), the client MUST stop processing the request and MUST abandon the Block-wise transfer. Then, the client can continue by switching to the sequential workflow shown in {{fig-non-combined}}. That is, the client first sends EDHOC message_3 prepended by the EDHOC Connection Identifier C_R encoded as per {{Section 3.3 of I-D.ietf-lake-edhoc}}, and then sends the OSCORE-protected CoAP request once the EDHOC execution is completed. -The performance advantage of using the EDHOC + OSCORE request can be lost when used in combination with Block-wise transfers that rely on specific parameter values and block sizes. +The performance advantage of using the EDHOC + OSCORE request can be lost when used in combination with Block-wise transfers that rely on specific parameter values and block sizes. Application policies at the CoAP client can define when and how to detect whether such performance advantage is lost, and, if that is the case, whether to appropriately adjust the parameter values and block sizes, or instead to fallback on the sequential workflow of EDHOC. Further considerations on this topic are out of the scope of this document. ## Server Processing {#server-processing} From 1b1f30bd5d1c058984d1953b88904d8dc834d881 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 19:02:21 +0100 Subject: [PATCH 08/19] IANA considerations - Spelled out the whole range of integers --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index d8556df..6fac0c7 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -548,7 +548,7 @@ The registry uses the "Expert Review" registration procedure {{RFC8126}}. Expert The columns of this registry are: -* Value: This field contains the value used to identify the type of authentication credential. These values MUST be unique. The value can be an unsigned integer or a negative integer. Different ranges of values use different registration policies {{RFC8126}}: +* Value: This field contains the value used to identify the type of authentication credential. These values MUST be unique. The value can be an unsigned integer or a negative integer, in the range from -65536 to 65535. Different ranges of values use different registration policies {{RFC8126}}: * Integer values from -24 to 23 are designated as "Standards Action With Expert Review". * Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required". From f6d3bc448bc8f4734ce2ef5ba9d4547060229d8f Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 19:05:05 +0100 Subject: [PATCH 09/19] Editorial --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index 6fac0c7..d029b07 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -75,7 +75,7 @@ The lightweight authenticated key exchange protocol EDHOC can be run over CoAP a 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 details this use of the EDHOC protocol, and specifies a number of additional and optional mechanisms. These especially include an optimization approach that combines the EDHOC execution with the first OSCORE transaction (see {{edhoc-in-oscore}}). This allows for a minimum number of round trips necessary to setup the OSCORE Security Context and complete an OSCORE transaction, e.g., when an IoT device gets configured in a network for the first time. +This document details the use of the EDHOC protocol with CoAP and OSCORE, and specifies a number of additional and optional mechanisms. These especially include an optimization approach that combines the EDHOC execution with the first OSCORE transaction (see {{edhoc-in-oscore}}). This allows for a minimum number of round trips necessary to setup the OSCORE Security Context and complete an OSCORE transaction, e.g., when an IoT device gets configured in a network for the first time. This optimization is desirable, since the number of message exchanges can have a substantial impact on the latency of conveying the first OSCORE request, when using certain radio technologies. From d6bab9cc444186364504646d18f58dc0e0501d74 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 19:20:23 +0100 Subject: [PATCH 10/19] Processing steps in dedicated subsections --- draft-ietf-core-oscore-edhoc.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index d029b07..bc029cc 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -225,7 +225,7 @@ That is, the EDHOC + OSCORE request is composed of the following two parts combi * EDHOC message_3 is transported in the payload of the EDHOC + OSCORE request prepended to the payload of the OSCORE Request. This is because EDHOC message_3 may be too large to be included in a CoAP Option, e.g., if conveying a large public key certificate chain as ID_CRED_I (see {{Section 3.5.3 of I-D.ietf-lake-edhoc}}) or if conveying large External Authorization Data as EAD_3 (see {{Section 3.8 of I-D.ietf-lake-edhoc}}). -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. +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-intro}} for the client side and in {{server-processing-intro}} for the server side. ## EDHOC Option {#edhoc-option} @@ -240,7 +240,7 @@ The EDHOC Option has the properties summarized in {{fig-edhoc-option}}, which ex C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable" align="center"} -The presence of this option means that the message payload also contains EDHOC data, which must be extracted and processed as defined in {{server-processing}}, before the rest of the message can be processed. +The presence of this option means that the message payload also contains EDHOC data, which must be extracted and processed as defined in {{server-processing-intro}}, before the rest of the message can be processed. {{fig-edhoc-opt}} shows an example of a CoAP message transported over UDP and containing both the EDHOC data and the OSCORE ciphertext, using the newly defined EDHOC option for signalling. @@ -262,7 +262,11 @@ The presence of this option means that the message payload also contains EDHOC d ~~~~~~~~~~~~~~~~~ {: #fig-edhoc-opt title="Example of CoAP message transported over UDP, combining EDHOC data and OSCORE data as signalled with the EDHOC Option." artwork-align="center"} -## Client Processing {#client-processing} +## Client Processing {#client-processing-intro} + +This section describes the processing on the client side. + +### Processing of the EDHOC + OSCORE Request {#client-processing} The client prepares an EDHOC + OSCORE request as follows. @@ -308,7 +312,11 @@ In such a case, the OSCORE processing in step 2 of {{client-processing}} is perf The performance advantage of using the EDHOC + OSCORE request can be lost when used in combination with Block-wise transfers that rely on specific parameter values and block sizes. Application policies at the CoAP client can define when and how to detect whether such performance advantage is lost, and, if that is the case, whether to appropriately adjust the parameter values and block sizes, or instead to fallback on the sequential workflow of EDHOC. Further considerations on this topic are out of the scope of this document. -## Server Processing {#server-processing} +## Server Processing {#server-processing-intro} + +This section describes the processing on the server side. + +### Processing of the EDHOC + OSCORE Request {#server-processing} In order to process a request containing the EDHOC option, i.e., an EDHOC + OSCORE request, the server MUST perform the following steps. From 9aee8ac4e66e5b39690ee2b6e0734800749a8e70 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 19:22:50 +0100 Subject: [PATCH 11/19] Editorial --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index bc029cc..55380e4 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -286,7 +286,7 @@ The client prepares an EDHOC + OSCORE request as follows. Note that the new payload includes EDHOC message_3, but it does not include the EDHOC connection identifier C_R. As the client is the EDHOC Initiator, C_R is the OSCORE Sender ID of the client, which is already specified as 'kid' in the OSCORE Option of the request from step 2, hence of the EDHOC + OSCORE request. -5. Signal the usage of this approach, by including the new EDHOC Option defined in {{edhoc-option}} into the EDHOC + OSCORE request. +5. Include the new EDHOC Option defined in {{edhoc-option}} into the EDHOC + OSCORE request. The application/cid-edhoc+cbor-seq media type does not apply to this message, whose media type is unnamed. From 2e9a5728a9498c3f2c557303eaa44ab22863bb43 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 17 Nov 2023 19:26:08 +0100 Subject: [PATCH 12/19] Editorial --- draft-ietf-core-oscore-edhoc.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index 55380e4..eddb0ca 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -425,9 +425,7 @@ The chosen C_R SHOULD NOT be the Recipient ID of any current OSCORE Security Con ### Initiator Processing of Message 2 -If the following condition holds, the Initiator MUST abort the session and reply with an EDHOC error message with error code 1, formatted as defined in {{Section 6.2 of I-D.ietf-lake-edhoc}}. - -* The EDHOC Connection Identifier C_I is equal to the EDHOC Connection Identifier C_R specified in EDHOC message_2. +If the EDHOC Connection Identifier C_I is equal to the EDHOC Connection Identifier C_R specified in EDHOC message_2, then the Initiator MUST abort the session and reply with an EDHOC error message with error code 1, formatted as defined in {{Section 6.2 of I-D.ietf-lake-edhoc}}. # Extension and Consistency of Application Profiles # {#app-statements} From 3fe2b6c79a315cca952b6ec01799bcfa4f22cc3d Mon Sep 17 00:00:00 2001 From: marco-tiloca-sics Date: Mon, 20 Nov 2023 17:48:52 +0000 Subject: [PATCH 13/19] Update draft-ietf-core-oscore-edhoc.md Co-authored-by: cabo --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index eddb0ca..de33b13 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -310,7 +310,7 @@ In such a case, the OSCORE processing in step 2 of {{client-processing}} is perf B. If the size of COMB_PAYLOAD exceeds MAX_UNFRAGMENTED_SIZE (see {{Section 4.1.3.4.2 of RFC8613}}), the client MUST stop processing the request and MUST abandon the Block-wise transfer. Then, the client can continue by switching to the sequential workflow shown in {{fig-non-combined}}. That is, the client first sends EDHOC message_3 prepended by the EDHOC Connection Identifier C_R encoded as per {{Section 3.3 of I-D.ietf-lake-edhoc}}, and then sends the OSCORE-protected CoAP request once the EDHOC execution is completed. -The performance advantage of using the EDHOC + OSCORE request can be lost when used in combination with Block-wise transfers that rely on specific parameter values and block sizes. Application policies at the CoAP client can define when and how to detect whether such performance advantage is lost, and, if that is the case, whether to appropriately adjust the parameter values and block sizes, or instead to fallback on the sequential workflow of EDHOC. Further considerations on this topic are out of the scope of this document. +The performance advantage of using the EDHOC + OSCORE request can be lost when used in combination with Block-wise transfers that rely on specific parameter values and block sizes. Application policies at the CoAP client can define when and how to detect whether the performance advantage is lost, and, if that is the case, whether to appropriately adjust the parameter values and block sizes, or instead to fall back on the sequential workflow of EDHOC. Further considerations on this topic are out of the scope of this document. ## Server Processing {#server-processing-intro} From 5ca1a2720cf941c7645a8706f15c4e6db1ccfabc Mon Sep 17 00:00:00 2001 From: crimson Date: Mon, 20 Nov 2023 18:58:14 +0100 Subject: [PATCH 14/19] Editorial --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index de33b13..3ee2e82 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -310,7 +310,7 @@ In such a case, the OSCORE processing in step 2 of {{client-processing}} is perf B. If the size of COMB_PAYLOAD exceeds MAX_UNFRAGMENTED_SIZE (see {{Section 4.1.3.4.2 of RFC8613}}), the client MUST stop processing the request and MUST abandon the Block-wise transfer. Then, the client can continue by switching to the sequential workflow shown in {{fig-non-combined}}. That is, the client first sends EDHOC message_3 prepended by the EDHOC Connection Identifier C_R encoded as per {{Section 3.3 of I-D.ietf-lake-edhoc}}, and then sends the OSCORE-protected CoAP request once the EDHOC execution is completed. -The performance advantage of using the EDHOC + OSCORE request can be lost when used in combination with Block-wise transfers that rely on specific parameter values and block sizes. Application policies at the CoAP client can define when and how to detect whether the performance advantage is lost, and, if that is the case, whether to appropriately adjust the parameter values and block sizes, or instead to fall back on the sequential workflow of EDHOC. Further considerations on this topic are out of the scope of this document. +The performance advantage of using the EDHOC + OSCORE request can be lost when used in combination with Block-wise transfers that rely on specific parameter values and block sizes. Application policies at the CoAP client can define when and how to detect whether the performance advantage is lost, and, if that is the case, whether to appropriately adjust the parameter values and block sizes, or instead to fall back on the sequential workflow of EDHOC. ## Server Processing {#server-processing-intro} From 71c456f34fbaa8834eb83489284946af055ca24e Mon Sep 17 00:00:00 2001 From: crimson Date: Tue, 21 Nov 2023 09:56:33 +0100 Subject: [PATCH 15/19] Changed "sum" to "combination" of MACs --- draft-ietf-core-oscore-edhoc.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index 3ee2e82..50cd5fe 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -487,11 +487,11 @@ The same security considerations from OSCORE {{RFC8613}} and EDHOC {{I-D.ietf-la {{client-processing}} specifies that a client SHOULD NOT have multiple outstanding EDHOC + OSCORE requests pertaining to the same EDHOC session. Even if a client did not fulfill this requirement, it would not have any impact in terms of security. That is, the server would still not process different instances of the same EDHOC message_3 more than once in the same EDHOC session (see {{Section 5.1 of I-D.ietf-lake-edhoc}}), and would still enforce replay protection of the OSCORE-protected request (see {{Sections 7.4 and 8.2 of RFC8613}}). -When using the optimized workflow in Figure 2, a minimum of 128-bit security against online brute force attacks is achieved after the client receives and successfully verifies the first OSCORE-protected response (see {{Section 9.1 of I-D.ietf-lake-edhoc}}). As an example, if EDHOC is used with method 3 (see {{Section 3.2 of I-D.ietf-lake-edhoc}}) and cipher suite 2 (see {{Section 3.6 of I-D.ietf-lake-edhoc}}), then the following holds. +When using the optimized workflow in {{fig-combined}}, a minimum of 128-bit security against online brute force attacks is achieved after the client receives and successfully verifies the first OSCORE-protected response (see {{Section 9.1 of I-D.ietf-lake-edhoc}}). As an example, if EDHOC is used with method 3 (see {{Section 3.2 of I-D.ietf-lake-edhoc}}) and cipher suite 2 (see {{Section 3.6 of I-D.ietf-lake-edhoc}}), then the following holds. -* The Initiator is authenticated with 128-bit security against online attacks. This is the sum of the 64-bit MACs in EDHOC message_3 and of the MAC in the AEAD of the first OSCORE-protected CoAP request, as rebuilt at step 7 of {{server-processing}}. +* The Initiator is authenticated with 128-bit security against online attacks. This is the combination of the 64-bit MACs in EDHOC message_3 and of the MAC in the AEAD of the first OSCORE-protected CoAP request, as rebuilt at step 7 of {{server-processing}}. -* The Responder is authenticated with 128-bit security against online attacks. This is the sum of the 64-bit MACs in EDHOC message_2 and of the MAC in the AEAD of the first OSCORE-protected CoAP response. +* The Responder is authenticated with 128-bit security against online attacks. This is the combination of the 64-bit MACs in EDHOC message_2 and of the MAC in the AEAD of the first OSCORE-protected CoAP response. With reference to the sequential workflow in {{fig-non-combined}}, the OSCORE request might have to undergo access control checks at the server, before being actually executed for accessing the target protected resource. The same MUST hold when the optimized workflow in {{fig-combined}} is used, i.e., when using the EDHOC + OSCORE request. From e859cacf036443186fd9b7c8499f1ad6a383304d Mon Sep 17 00:00:00 2001 From: crimson Date: Wed, 22 Nov 2023 09:31:44 +0100 Subject: [PATCH 16/19] Editorial --- draft-ietf-core-oscore-edhoc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index 50cd5fe..aae90c0 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -489,9 +489,9 @@ The same security considerations from OSCORE {{RFC8613}} and EDHOC {{I-D.ietf-la When using the optimized workflow in {{fig-combined}}, a minimum of 128-bit security against online brute force attacks is achieved after the client receives and successfully verifies the first OSCORE-protected response (see {{Section 9.1 of I-D.ietf-lake-edhoc}}). As an example, if EDHOC is used with method 3 (see {{Section 3.2 of I-D.ietf-lake-edhoc}}) and cipher suite 2 (see {{Section 3.6 of I-D.ietf-lake-edhoc}}), then the following holds. -* The Initiator is authenticated with 128-bit security against online attacks. This is the combination of the 64-bit MACs in EDHOC message_3 and of the MAC in the AEAD of the first OSCORE-protected CoAP request, as rebuilt at step 7 of {{server-processing}}. +* The Initiator is authenticated with 128-bit security against online attacks. Consistent with {{Section 9.1 of I-D.ietf-lake-edhoc}}, this results from the combination of the strength of the 64-bit MAC in EDHOC message_3 and of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP request, as rebuilt at step 7 of {{server-processing}}. -* The Responder is authenticated with 128-bit security against online attacks. This is the combination of the 64-bit MACs in EDHOC message_2 and of the MAC in the AEAD of the first OSCORE-protected CoAP response. +* The Responder is authenticated with 128-bit security against online attacks. Consistent with {{Section 9.1 of I-D.ietf-lake-edhoc}}, this results from the combination of the strength of the 64-bit MAC in EDHOC message_2 and of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP response. With reference to the sequential workflow in {{fig-non-combined}}, the OSCORE request might have to undergo access control checks at the server, before being actually executed for accessing the target protected resource. The same MUST hold when the optimized workflow in {{fig-combined}} is used, i.e., when using the EDHOC + OSCORE request. From 0ab26e2751b6ca062d2244413675bfcdafde1ddf Mon Sep 17 00:00:00 2001 From: marco-tiloca-sics Date: Wed, 22 Nov 2023 09:43:19 +0000 Subject: [PATCH 17/19] Update draft-ietf-core-oscore-edhoc.md Co-authored-by: cabo --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index aae90c0..21b3226 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -489,7 +489,7 @@ The same security considerations from OSCORE {{RFC8613}} and EDHOC {{I-D.ietf-la When using the optimized workflow in {{fig-combined}}, a minimum of 128-bit security against online brute force attacks is achieved after the client receives and successfully verifies the first OSCORE-protected response (see {{Section 9.1 of I-D.ietf-lake-edhoc}}). As an example, if EDHOC is used with method 3 (see {{Section 3.2 of I-D.ietf-lake-edhoc}}) and cipher suite 2 (see {{Section 3.6 of I-D.ietf-lake-edhoc}}), then the following holds. -* The Initiator is authenticated with 128-bit security against online attacks. Consistent with {{Section 9.1 of I-D.ietf-lake-edhoc}}, this results from the combination of the strength of the 64-bit MAC in EDHOC message_3 and of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP request, as rebuilt at step 7 of {{server-processing}}. +* The Initiator is authenticated with 128-bit security against online attacks. As per {{Section 9.1 of I-D.ietf-lake-edhoc}}, this results from the combination of the strength of the 64-bit MAC in EDHOC message_3 and of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP request, as rebuilt at step 7 of {{server-processing}}. * The Responder is authenticated with 128-bit security against online attacks. Consistent with {{Section 9.1 of I-D.ietf-lake-edhoc}}, this results from the combination of the strength of the 64-bit MAC in EDHOC message_2 and of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP response. From 2cfa71c5f691f019ce7ddbbacd73b7b77118c5ae Mon Sep 17 00:00:00 2001 From: marco-tiloca-sics Date: Wed, 22 Nov 2023 09:43:28 +0000 Subject: [PATCH 18/19] Update draft-ietf-core-oscore-edhoc.md Co-authored-by: cabo --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index 21b3226..5eb4bcd 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -491,7 +491,7 @@ When using the optimized workflow in {{fig-combined}}, a minimum of 128-bit secu * The Initiator is authenticated with 128-bit security against online attacks. As per {{Section 9.1 of I-D.ietf-lake-edhoc}}, this results from the combination of the strength of the 64-bit MAC in EDHOC message_3 and of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP request, as rebuilt at step 7 of {{server-processing}}. -* The Responder is authenticated with 128-bit security against online attacks. Consistent with {{Section 9.1 of I-D.ietf-lake-edhoc}}, this results from the combination of the strength of the 64-bit MAC in EDHOC message_2 and of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP response. +* The Responder is authenticated with 128-bit security against online attacks. As per {{Section 9.1 of I-D.ietf-lake-edhoc}}, this results from the combination of the strength of the 64-bit MAC in EDHOC message_2 and of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP response. With reference to the sequential workflow in {{fig-non-combined}}, the OSCORE request might have to undergo access control checks at the server, before being actually executed for accessing the target protected resource. The same MUST hold when the optimized workflow in {{fig-combined}} is used, i.e., when using the EDHOC + OSCORE request. From 69f7ec8ab29589b08b848d6db275da5f3988db57 Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 23 Nov 2023 17:13:48 +0100 Subject: [PATCH 19/19] Nits (s/if/when) --- draft-ietf-core-oscore-edhoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index 5eb4bcd..ecadeeb 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -223,7 +223,7 @@ That is, the EDHOC + OSCORE request is composed of the following two parts combi * C_R is the OSCORE Sender ID of the client and hence transported in the 'kid' field of the OSCORE Option (see {{Section 6.1 of RFC8613}}). Unlike in the sequential workflow shown in {{fig-non-combined}}, C_R is thus not transported in the payload of the EDHOC + OSCORE request. - * EDHOC message_3 is transported in the payload of the EDHOC + OSCORE request prepended to the payload of the OSCORE Request. This is because EDHOC message_3 may be too large to be included in a CoAP Option, e.g., if conveying a large public key certificate chain as ID_CRED_I (see {{Section 3.5.3 of I-D.ietf-lake-edhoc}}) or if conveying large External Authorization Data as EAD_3 (see {{Section 3.8 of I-D.ietf-lake-edhoc}}). + * EDHOC message_3 is transported in the payload of the EDHOC + OSCORE request prepended to the payload of the OSCORE Request. This is because EDHOC message_3 may be too large to be included in a CoAP Option, e.g., when conveying a large public key certificate chain as ID_CRED_I (see {{Section 3.5.3 of I-D.ietf-lake-edhoc}}) or when conveying large External Authorization Data as EAD_3 (see {{Section 3.8 of I-D.ietf-lake-edhoc}}). 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-intro}} for the client side and in {{server-processing-intro}} for the server side.