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

["Pengshuping (Peng Shuping)" <[e-mail]>]

Hi Marco,

Thank you for making the updates. It is much clearer now. I have no other comments. Thank you!

Best Regards,
Shuping

发件人: Marco Tiloca <[e-mail]>
发送时间: 2023年11月23日 23:45
收件人: Pengshuping (Peng Shuping) <[e-mail]>; [e-mail]
抄送: [e-mail]; [e-mail]; [e-mail]
主题: Re: Artart last call review of draft-ietf-core-oscore-edhoc-09

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