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