Thanks a lot for your review! Please find in line below our detailed replies to your comments.
A Github PR where we have addressed your comments is available at [OPSDIR-PR].
Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews), and to submit the result as version -10 of the document.
Thanks,
/Marco
[OPSDIR-PR] https://github.com/core-wg/oscore-edhoc/pull/16
On 2023-11-13 19:24, Jürgen Schönwälder
via Datatracker wrote:
Reviewer: Jürgen Schönwälder
Review result: Has Issues
I have reviewed draft-ietf-core-oscore-edhoc-09 and while I have a
general understanding about CoAP, I am not familiar with EDHOC or the
details of OSCORE. Perhaps some of my questions have simple obvious
answers for those familiar with the technologies.
- The document title consists of six token, three of them are
acronyms. This is crisp and short but unless you know the acronyms,
it is hard to tell what this document is about. Sure, expanding all
acronyms in the title makes it long but it might make the abstract,
which uses the acronyms as well, more accessible as well...
Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the
Constrained Application Protocol (CoAP) and Object Security for
Constrained RESTful Environments (OSCORE)
==>MT
We have changed the title and the abstract, by expanding the acronyms as suggested.
<==
- It is difficult to judge whether there are any possible side effects of the proposed optimization, which essentially piggybacks the first OSCORE exchange on the last EDHOC exchange. Optimizations of this kind sometimes cause subtle side-effects. A security review should be done to ensure that there is no impact on the security of EDHOC and OSCORE. I am not able to judge this in a time efficient manner.
==>MT
This document builds on the security properties and considerations of EDHOC and OSCORE. There have been security reviews, and no issues have been found.
<==
- It is not clear to me how this works in mixed deployments where some responders implement this specification but others do not. How does the initiator figure out whether sending a combined message makes sense? It seems question is handled by the application profile. But then section 5. starts with "can include the information below" followed by some SHOULD text. So what does this combination of "can include ... SHOULD ..." mean?
==>MT
Regarding the first part of the comment:
> - It is not clear to me how this works in mixed deployments where some
> responders implement this specification but others do not. How does
> the initiator figure out whether sending a combined message makes
> sense? It seems question is handled by the application profile.
Yes, the way for the CoAP Client (the EDHOC Initiator) to know for sure how to run EDHOC in advance is based on its knowledge of the EDHOC application profile to refer to, see https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-application-profile
Note that the general requirement for such a knowledge is not something that this document is creating. Instead, it holds for several aspects of EDHOC, ranging from its authentication methods, to the possible types of authentication credential to use, to the supported External Authorization Data (EAD) items that can be used during the protocol execution.
In turn, there are different ways for the Client to gain knowledge of the EDHOC application profile and the information elements included therein.
* One way is actually specified in the present document, as relying on link target attributes applicable to the discovery of server resources where to run EDHOC. See Section 6, and in particular the target attribute "ed-comb-req" indicating support at the server for the EDHOC + OSCORE combined request defined in this document.
* Another way is being defined in the EDHOC and OSCORE transport profile of the ACE framework for authentication and authorization, as relying on a descriptive EDHOC_Information object that an Authorization Server provides to the Client during the ACE authorization workflow, see https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-profile/
* Further ways are being defined in https://datatracker.ietf.org/doc/draft-tiloca-lake-app-profiles/ , as more general methods for coordinating the use of EDHOC application profiles. Such methods include registered numeric identifiers of EDHOC application profiles (in turn possible to express by means of a link target attribute or of a parameter in an EDHOC_Information object mentioned above), as well as a canonical representation of an EDHOC Application Profile as a CBOR data item that can be conveniently distributed and stored.
Overall, like it is the case for the main EDHOC specification draft-ietf-lake-edhoc , the present document is not intended to discuss in detail how an EDHOC peer gains knowledge of the EDHOC Application Profile to consider. Yet, it does provide a means to gain knowledge of such related information, i.e., through target attributes in link to EDHOC resources.
On the second part of the comment:
> But
> then section 5. starts with "can include the information below"
> followed by some SHOULD text. So what does this combination of "can
> include ... SHOULD ..." mean?
We literally mean "can include", as "it is possible for it to include". We have rephrased as follows.
> It is possible to include the information below in the application profile referred by the client and server, according to the specified consistency rules.
Then, the second paragraph builds on the first one with a normative requirement. That is, given the fact that the EDHOC application profiles can include such information (first paragraph), then the application profile associated with an EDHOC resource where the EDHOC + OSCORE request is supported SHOULD say so. This provides early knowledge to a Client, sparing a possible use of the optimized workflow that fails due to lack of support on the Server side.
<==
- What does it mean for the client to 'bear [something] in mind'? Should the text not spell out clearly what the client is expected to do in this case (SHOULDS not send a combined EDHOC + OSCORE request)?
==>MT
The quoted paragraph tries to describe two concepts without going too much into details, but admittedly in way that ended up being too terse.
We have replaced the paragraph with the following two paragraphs, each mentioning one concept.
> In case the application profile indicates that the server supports the optional EDHOC message_4 (see Section 5.5 of [I-D.ietf-lake-edhoc]), it is still possible to use the optimized workflow based on the EDHOC + OSCORE request. However, this means the server is not going to send EDHOC message_4, since it is not applicable to the optimized workflow (see Section 3.3).
>
> Also, in case the application profile indicates that the server shall send EDHOC message_4, then the application profile MUST NOT specify support for the EDHOC + OSCORE request, and there is no point for the client to use the optimized workflow, which is bound to fail (see Section 3.3).
<==
- Is section 4 telling me that the OSCORE ID and EDHOC ID can be the same (but they do not have to be the same) while with the proposed optimization they must be the same? Or is there always an identity mapping between the OSCORE ID and EDHOC ID? If so, why is section 4 even necessary?
==>MT
Section 4 covers several points, only one of which comes from draft-ietf-lake-edhoc.
In Section 4.0, we provide the following information:
* The first paragraph is a reminder of the identity mapping between EDHOC Connection Identifiers and OSCORE Sender/Recipient IDs. This is the only information already defined in draft-ietf-lake-edhoc and reminded here.
* The second paragraph clarifies that, in the EDHOC + OSCORE request, the EDHOC Connection Identifier C_R is the value of the 'kid' field in the OSCORE Option.
To make the text clearer and simpler, we have replaced both paragraphs in Section 4.0 as shown below.
OLD
> Section 3.3.3 of [I-D.ietf-lake-edhoc] defines the straightforward mapping from an EDHOC connection identifier to an OSCORE Sender/Recipient ID. That is, an EDHOC identifier and the corresponding OSCORE Sender/Recipient ID are both byte strings with the same value.
>
> Therefore, the conversion from an OSCORE Sender/Recipient ID to an EDHOC identifier is equally straightforward. In particular, at step 3 of Section 3.3, the value of ’kid’ in the OSCORE Option of the EDHOC + OSCORE request is both the server’s Recipient ID (i.e., the client’s Sender ID) and the EDHOC Connection Identifier C_R of the server.
NEW
> The OSCORE Sender/Recipient IDs are the EDHOC connection identifiers (see Section 3.3.3 of [I-D.ietf-lake-edhoc]). This applies also to the optimized workflow defined in Section 3 of this document.
>
> Note that, at step 3 of Section 3.3, the value of ’kid’ in the OSCORE Option of the EDHOC + OSCORE request is both the server’s Recipient ID (i.e., the client’s Sender ID) and the EDHOC Connection Identifier C_R of the server.
As to Section 4.1, its content is definitely necessary. It defines additional processing required on EDHOC messages, with respect to their base-processing defined in draft-ietf-lake-edhoc, and specifically due to the fact that EDHOC is used to derive keying material for OSCORE.
This especially includes normative requirements on the selection of the EDHOC Connection Identifiers C_I and C_R.
<==
I have ticked 'has issues' because there is no reviewer 'has questions' option. It is most likely that my questions have very simple answers - so take a look at my questions and it is absolutely fine to move ahead if my questions have obvious answers or are just a lack of understanding of the context.
==>MT
Thanks again for your comments and questions!
<==
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
Attachment:
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
