Re: [core] Opsdir last call review of draft-ietf-core-oscore-edhoc-09

[Marco Tiloca <[e-mail]>]

Hello Jürgen,

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: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se