From 5fad2255919a96aa40753019bc2068ca8a794a7c Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 7 Aug 2023 12:56:18 +0200 Subject: [PATCH 1/8] comma that --- 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 bdd0426..c23ac88 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 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 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. @@ -230,7 +230,7 @@ The EDHOC Option has the properties summarized in {{fig-edhoc-option}}, which ex Note to RFC Editor: Following the registration of the CoAP Option Number 21 as per {{iana-coap-options}}, please replace "TBD21" with "21" in the figure above. Then, please delete this paragraph. -The presence of this option means that the message payload contains also EDHOC data, that 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}}, before the rest of the message can be processed. {{fig-edhoc-opt}} shows an example of CoAP message transported over UDP and containing both the EDHOC data and the OSCORE ciphertext, using the newly defined EDHOC option for signalling. From 18f95f8abab220bede65bacdd3d4bd9714061c96 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 7 Aug 2023 12:58:42 +0200 Subject: [PATCH 2/8] impact -> influence --- 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 c23ac88..56b0313 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -77,7 +77,7 @@ Ephemeral Diffie-Hellman Over COSE (EDHOC) {{I-D.ietf-lake-edhoc}} is a lightwei 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 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. +This optimization is desirable, since the number of protocol round trips influences 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.2 of I-D.ietf-lake-edhoc}}), thus allowing additional OSCORE-protected CoAP data within target MTU sizes. From e0f60053f43fccbdaf75d6b6b7f144fee2d97f71 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 7 Aug 2023 13:00:05 +0200 Subject: [PATCH 3/8] missing article --- 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 56b0313..e437a82 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -81,7 +81,7 @@ This optimization is desirable, since the number of protocol round trips influen 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.2 of I-D.ietf-lake-edhoc}}), thus allowing additional OSCORE-protected CoAP data within target MTU sizes. -Furthermore, this document defines a number of parameters corresponding to different information elements of an EDHOC application profile (see {{web-linking}}). These can be specified as target attributes in the link to an EDHOC resource associated with that application profile, thus enabling an enhanced discovery of such resource for CoAP clients. +Furthermore, this document defines a number of parameters corresponding to different information elements of an EDHOC application profile (see {{web-linking}}). These can be specified as target attributes in the link to an EDHOC resource associated with that application profile, thus enabling an enhanced discovery of such a resource for CoAP clients. ## Terminology @@ -232,7 +232,7 @@ Note to RFC Editor: Following the registration of the CoAP Option Number 21 as p 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. -{{fig-edhoc-opt}} shows an example of CoAP message transported over UDP and containing both the EDHOC data and the OSCORE ciphertext, using the newly defined EDHOC option for signalling. +{{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. ~~~~~~~~~~~~~~~~~ From 65a522f0c19855341a7a44a302f602269d5e5e33 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 7 Aug 2023 13:05:17 +0200 Subject: [PATCH 4/8] Avoid weird aasvg artifact --- 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 e437a82..2bf87b6 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -192,7 +192,7 @@ EDHOC verification | OSCORE Sec Ctx | Derivation | | | - | ------------- EDHOC + OSCORE Request -------------> | + | -------------- EDHOC + OSCORE Request ------------> | | Header: 0.02 (POST) | | Payload: EDHOC message_3 + OSCORE-protected data | | | From 43ca69cc48a1bbe08c372737ff71d1ae35bc9425 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 7 Aug 2023 13:17:42 +0200 Subject: [PATCH 5/8] MGS -> MSG --- 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 2bf87b6..798295d 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -264,7 +264,7 @@ The client prepares an EDHOC + OSCORE request as follows. 3. Build COMB_PAYLOAD as the concatenation of EDHOC_MSG_3 and OSCORE_PAYLOAD in this order: COMB_PAYLOAD = EDHOC_MSG_3 \| OSCORE_PAYLOAD, where \| denotes byte string concatenation and: - * EDHOC_MSG_3 is the binary encoding of EDHOC message_3 resulting from step 1. As per {{Section 5.4.1 of I-D.ietf-lake-edhoc}}, EDHOC message_3 consists of one CBOR data item CIPHERTEXT_3, which is a CBOR byte string. Therefore, EDHOC_MGS_3 is the binary encoding of CIPHERTEXT_3. + * EDHOC_MSG_3 is the binary encoding of EDHOC message_3 resulting from step 1. As per {{Section 5.4.1 of I-D.ietf-lake-edhoc}}, EDHOC message_3 consists of one CBOR data item CIPHERTEXT_3, which is a CBOR byte string. Therefore, EDHOC_MSG_3 is the binary encoding of CIPHERTEXT_3. * OSCORE_PAYLOAD is the OSCORE ciphertext of the OSCORE-protected CoAP request resulting from step 2. From 055a50aff3bcba36d16d73084ba34c9c08b8c1e5 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 7 Aug 2023 13:23:28 +0200 Subject: [PATCH 6/8] Another stray comma. But maybe better fix the sentence... --- 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 798295d..56cb757 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -294,7 +294,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 abort 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. -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. ## Server Processing {#server-processing} From 1393dd989f7d9af463dcf81086b9ff1c5eed67e8 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 7 Aug 2023 13:31:02 +0200 Subject: [PATCH 7/8] No used cars, and isn't "addressed" better? --- 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 56cb757..e02fb3a 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -107,7 +107,7 @@ Finally, the client sends a POST request to the same EDHOC resource used earlier 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}}. -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 used EDHOC resource (see {{Section 3.9 of I-D.ietf-lake-edhoc}}. +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}}. ~~~~~~~~~~~~~~~~~ aasvg CoAP client CoAP server @@ -342,7 +342,7 @@ A. If Block-wise is present in the request, then process the Outer Block options {{fig-edhoc-opt-2}} shows an example of EDHOC + OSCORE Request transported over UDP. In particular, the example assumes that: -* The used OSCORE Partial IV is 0, consistently with the first request protected with the new OSCORE Security Context. +* The OSCORE Partial IV in use is 0, consistently with the first request protected with the new OSCORE Security Context. * The OSCORE Sender ID of the client is 0x01. From c49fc5624b39020ff54457fc702409e6b88394e2 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Mon, 7 Aug 2023 13:35:33 +0200 Subject: [PATCH 8/8] unnecessary and distracting ("before" means before) --- 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 e02fb3a..4a49880 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -480,7 +480,7 @@ With reference to the purely sequential workflow in {{fig-non-combined}}, the OS 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}}. -To this end, validated information to perform access control checks (e.g., an access token issued by a trusted party) has to be available at the server latest before starting to process the rebuilt OSCORE-protected application request. Such information may have been provided to the server separately before starting the EDHOC execution altogether, or instead as External Authorization Data during the EDHOC execution (see {{Section 3.8 of I-D.ietf-lake-edhoc}}). +To this end, validated information to perform access control checks (e.g., an access token issued by a trusted party) has to be available at the server before starting to process the rebuilt OSCORE-protected application request. Such information may have been provided to the server separately before starting the EDHOC execution altogether, or instead as External Authorization Data during the EDHOC execution (see {{Section 3.8 of I-D.ietf-lake-edhoc}}). Thus, a successful completion of the EDHOC protocol and the following derivation of the OSCORE Security Context at the server do not play a role in determining whether the rebuilt OSCORE-protected request is authorized to access the target protected resource at the server.