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

[Marco Tiloca <[e-mail]>]

Hello Shuping,

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 
[ARTART-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

[ARTART-PR] https://github.com/core-wg/oscore-edhoc/pull/17


On 2023-11-14 10:27, Shuping Peng via Datatracker wrote:
> Reviewer: Shuping Peng
> Review result: Ready with Issues
>
> I am the assigned ART-ART reviewer for this draft.
>
> Summary:
> I have some minor concerns about this document that I think should be resolved
> before publication.
>
> Comments:
> I think this document is basically ready for publication.
>
> Major Issues:
> "No major issues found."
>
> Minor Issues:
> Where the "C_R" is actually carried is not clear. It would be good if the
> following text in Section 3 could be more clear about it, and it might also be
> helpful to show the "C_R" in Figure 2. "     EDHOC data consisting of the pair
> (C_R, EDHOC message_3) required
>        for completing the EDHOC session.  Note that, as specified in
>        Section 3.2, C_R is transported in the OSCORE Option of the OSCORE
>        Request rather than in the CoAP payload of the EDHOC + OSCORE
>        request.
> "

==>MT

In order to clarify where C_R is transported, we have made the following 
changes.

In Section 3.0, we have revised the bullet list introduced by "That is, 
the EDHOC + OSCORE request ..." to become as follows.

 > That is, the EDHOC + OSCORE request is composed of the following two 
parts combined together in a single CoAP message:
 >
 > * The OSCORE Request from Figure 1, 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, transported as follows:
 >    * 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 RFC 8613). 
Unlike in the sequential workflow shown in Figure 1, 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., 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]).

Also in Section 3.0, we have updated Figure 2 to show the inclusion of 
C_R in the CoAP OSCORE Option of the EDHOC + OSCORE request. That is:

OLD
```
        | -------------- EDHOC + OSCORE Request ------------> |
        |   Header: 0.02 (POST)                               |
        |   Payload: EDHOC message_3 + OSCORE-protected data  |

        ~snip

        | <--------------- OSCORE Response ------------------ |
        |                    Header: 2.04 (Changed)           |
        |                    Payload: OSCORE-protected data   |

```

NEW
```
        | -------------- EDHOC + OSCORE Request ------------> |
        |   Header: 0.02 (POST)                               |
        |   OSCORE: { ... ; kid: C_R }                        |
        |   Payload: EDHOC message_3 + OSCORE-protected data  |


        ~snip

        | <--------------- OSCORE Response ------------------ |
        |                    Header: 2.04 (Changed)           |
        |                    OSCORE: { ... }                  |
        |                    Payload: OSCORE-protected data   |
```

In Section 2, we have similarly updated Figure 1 to show the inclusion 
of C_R in the CoAP OSCORE Option of the OSCORE request. That is:

OLD
```
        | ---------------- OSCORE Request -----------------> |
        |   Header: 0.02 (POST)                              |
        |   Payload: OSCORE-protected data                   |

        ~ snip

        | <--------------- OSCORE Response ----------------- |
        |                 Header: 2.04 (Changed)             |
        |                 Payload: OSCORE-protected data     |
```

NEW
```
        | ---------------- OSCORE Request -----------------> |
        |   Header: 0.02 (POST)                              |
        |   OSCORE: { ... ; kid: C_R }                       |
        |   Payload: OSCORE-protected data                   |

        ~ snip

        | <--------------- OSCORE Response ----------------- |
        |                 Header: 2.04 (Changed)             |
        |                 OSCORE: { ... }                    |
        |                 Payload: OSCORE-protected data     |
```

Also in Section 2, we have extended the ninth paragraph as follows:

OLD
 > 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 Appendix A.1 of 
[I-D.ietf-lake-edhoc]. After that, they can use OSCORE to protect their 
communications as per [RFC8613].

NEW
 > 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 Appendix 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 the OSCORE Sender ID of the client (see 
Appendix 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 RFC 8613).

<==

>
>

-- 
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