From 816c42f362cb18a602fbd63d8c72c5f9cb101a5d Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 29 Mar 2024 12:51:42 +0100 Subject: [PATCH 1/6] 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 e98bc4f..85cd12f 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -755,6 +755,6 @@ Expert reviewers should take into consideration the following points: # Acknowledgments {:numbered="false"} -The authors sincerely thank {{{Christian Amsüss}}}, {{{Carsten Bormann}}}, {{{Esko Dijk}}}, {{{Joel Halpern}}}, {{{Wes Hardaker}}}, {{{Klaus Hartke}}}, {{{John Preuß Mattsson}}}, {{{David Navarro}}}, {{{Shuping Peng}}}, {{{Jim Schaad}}}, {{{Jürgen Schönwälder}}}, {{{Mališa Vučinić}}}, and {{{Paul Wouters}}} for their feedback and comments. +The authors sincerely thank {{{Christian Amsüss}}}, {{{Emmanuel Baccelli}}}, {{{Carsten Bormann}}}, {{{Esko Dijk}}}, {{{Joel Halpern}}}, {{{Wes Hardaker}}}, {{{Klaus Hartke}}}, {{{John Preuß Mattsson}}}, {{{David Navarro}}}, {{{Shuping Peng}}}, {{{Jim Schaad}}}, {{{Jürgen Schönwälder}}}, {{{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 70eced51678c2ee05dd901f1688a4fa968215d36 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 29 Mar 2024 12:56:09 +0100 Subject: [PATCH 2/6] Early mentioning of the optimization properties. --- draft-ietf-core-oscore-edhoc.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-ietf-core-oscore-edhoc.md b/draft-ietf-core-oscore-edhoc.md index 85cd12f..c428ddb 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -81,6 +81,8 @@ This optimization is desirable, since the number of message exchanges can have a Without this optimization, it is not possible, not even in theory, to achieve the minimum number of round trips. This optimization makes it possible also in practice, since the message_3 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. +The minimum number of two round trips can be achieved only if the default, forward message flow of EDHOC is used, i.e., when a CoAP client acts as EDHOC Initiator and a CoAP server acts as EDHOC Responder. The performance advantage of using this optimization can be lost when used in combination with Block-wise transfers {{RFC7959}} that rely on specific parameter values and block 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 a resource for CoAP clients. ## Terminology From f763716f48d79d6cf03fe3c5553525e50c0e5844 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 29 Mar 2024 12:58:49 +0100 Subject: [PATCH 3/6] Simplified phrasing. --- 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 c428ddb..88c0a67 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -75,11 +75,11 @@ The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Ove 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 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 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 two 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. -Without this optimization, it is not possible, not even in theory, to achieve the minimum number of round trips. This optimization makes it possible also in practice, since the message_3 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. +Without this optimization, it is not possible to achieve the minimum number of two round trips. This optimization makes it possible, since the message_3 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. The minimum number of two round trips can be achieved only if the default, forward message flow of EDHOC is used, i.e., when a CoAP client acts as EDHOC Initiator and a CoAP server acts as EDHOC Responder. The performance advantage of using this optimization can be lost when used in combination with Block-wise transfers {{RFC7959}} that rely on specific parameter values and block sizes. From 2e5eccc756275148f6fb0cf38241169c5be54665 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 29 Mar 2024 13:01:18 +0100 Subject: [PATCH 4/6] Simplified text in the caption of Figure 1. --- 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 88c0a67..8a4b856 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -161,7 +161,7 @@ OSCORE Sec Ctx | | Payload: OSCORE-protected data | | | ~~~~~~~~~~~~~~~~~ -{: #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"} +{: #fig-non-combined title="EDHOC and OSCORE run sequentially. The optional message_4 is included in this example." artwork-align="center"} 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. From fe60253838fe5c0f90d9c789586f744fe9094044 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 29 Mar 2024 13:06:26 +0100 Subject: [PATCH 5/6] Simpler and more focused background text on web linking --- 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 8a4b856..8c67033 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -443,9 +443,9 @@ Also, in case the application profile indicates that the server shall send EDHOC {{Section 10.10 of I-D.ietf-lake-edhoc}} registers the resource type "core.edhoc", which can be used as target attribute in a web link {{RFC8288}} to an EDHOC resource, e.g., using a link-format document {{RFC6690}}. This enables clients to discover the presence of EDHOC resources at a server, possibly using the resource type as filter criterion. -At the same time, the application profile associated with an EDHOC resource provides information describing how the EDHOC protocol can be used through that resource. While a client may become aware of the application profile through several means, it would be convenient to obtain its information elements upon discovering the EDHOC resources at the server. This might aim at discovering especially the EDHOC resources whose associated application profile denotes a way of using EDHOC which is most suitable to the client, e.g., with EDHOC cipher suites or authentication methods that the client also supports or prefers. +At the same time, the application profile associated with an EDHOC resource provides information describing how the EDHOC protocol can be used through that resource. A client may become aware of the application profile, e.g., by obtaining its information elements upon discovering the EDHOC resources at the server. This allows the client to discover especially the EDHOC resources whose associated application profile denotes a way of using EDHOC which is most suitable to the client, e.g., with EDHOC cipher suites or authentication methods that the client also supports or prefers. -That is, it would be convenient that a client discovering an EDHOC resource contextually obtains relevant pieces of information from the application profile associated with that resource. The resource discovery can occur by means of a direct interaction with the server, or instead by means of the CoRE Resource Directory {{RFC9176}}, where the server may have registered the links to its resources. +That is, while discovering an EDHOC resource, a client can contextually obtain relevant pieces of information from the application profile associated with that resource. The resource discovery can occur by means of a direct interaction with the server, or instead by means of the CoRE Resource Directory {{RFC9176}}, where the server may have registered the links to its resources. In order to enable the above, this section defines a number of parameters, each of which can be optionally specified as a target attribute with the same name in the link to the respective EDHOC resource, or as filter criteria in a discovery request from the client. When specifying these parameters in a link to an EDHOC resource, the target attribute rt="core.edhoc" MUST be included, and the same consistency rules defined in {{app-statements}} for the corresponding information elements of an application profile MUST be followed. From 70a90b47e500f478a7c6bcc8be09fe2eb1ddb3ad Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 29 Mar 2024 13:09:06 +0100 Subject: [PATCH 6/6] Reference to Section 9.4 of EDHOC (on PQ considerations) --- 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 8c67033..8139134 100644 --- a/draft-ietf-core-oscore-edhoc.md +++ b/draft-ietf-core-oscore-edhoc.md @@ -491,7 +491,7 @@ 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 {{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. +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 {{Sections 9.1 and 9.4 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. 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}}.