Re: [core] 🔔 WG Call for Adoption on draft-tiloca-core-multicast-oscoap

[Esko Dijk <[e-mail]>]

Thanks Marco,

This update solves the issues I think and answers my questions, except for the randomness in the Gid:  “A Gid MUST have a random component and be long enough, in order to achieve a negligible probability of collisions between Group Identifiers from different Group Managers”; and Appendix C.

The example Appendix C uses a single random byte.  Most people would think the collision probability is quite high in this case; so how can this choice satisfy the requirement?  Maybe in this example the Group Managers pick a random value and then mutually verify that there are no collissions?

The name “Group Epoch” could be slightly confusing here – Appendix C states the epoch applies to a single group. However the example there shows the epoch applies to all groups from the same Group Manager, or in other words the epoch *is* the group. (Because there is no thing like “Group ID” in the example, only GM random byte and Group Epoch bytes.)  Was it intended to add a byte or so for “Group ID” ? So that each group can have its own epoch counter.

Esko



From: Marco Tiloca <[e-mail]>
Sent: Monday, March 5, 2018 23:18
To: Esko Dijk <[e-mail]>; Jaime Jiménez <[e-mail]>; [e-mail] WG ([e-mail]) <[e-mail]>
Subject: Re: [core] 🔔 WG Call for Adoption on draft-tiloca-core-multicast-oscoap


Hello Esko,



Thanks for your support and comments, we have considered them when producing the latest version of the  draft [1].



Please, find in line some answers to your comments.



Best,

/Marco



[1] https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-01

On 2017-12-04 14:35, Esko Dijk wrote:
I also support the adoption of this draft as a work item for CoRE. Below are the results of a quick review, also.

Best regards
Esko Dijk


Overall comments – or work that the WG could take up next
·         Detailed example with message sizes would be useful. Since it’s important for multicast over 6lowpan performance that the IPv6 packets stay small enough (one 802.15.4 frame). At this moment, I can’t judge that yet easily based on the draft.


[MT] We have now included detailed examples in Sections 3.1 (Request) and Section 3.2 (Response).


·         Normally, for applications (e.g. Building automation and lighting) groups do need a stable and non-random group ID, that identifies the group over time even as changes occur, e.g. members added/removed. The “Gid” in the draft however changes. There could be some text added to explain how Gid is linked to a stable ID. E.g., this could be configured by the Group Manager. The stable group ID is then not used over-the-wire for multicast OSCORE.


[MT] It is true that the Gid in this draft changes over time, especially upon renewing the group keying material, and the Group Manager is the only responsible for managing its value update. However, this Gid has to be intended as the identifier of the OSCORE “security group”, including as members the endpoints that share the same Common Security Context.

[MT] As you say, applications do rely on a stable and non-random group ID, which is not used over-the-wire for group OSCORE, and instead identifies an “application group” having as members the endpoints that participate in a same group application. There is no relation between this application-level group ID and the OSCORE Gid defined in this draft. However, one may possibly map multiple “application groups” to the same “security group”.

[MT] In order to clarify this point, we included also a definition of “Group” and “Group ID” in Section 1.1.


·         There is normative text in the Appendices; it could be clarified what the status of this is. E.g. only normative if one chooses to implement the optional element described in the Appendix?I have a preference for avoiding normative text in the Appendices, but I’m curious to hear what others think.

[MT] We relaxed the text in Appendices to avoid normative references, with the exception of a “NOT RECOMMENDED” in current Appendix F “No Verification of Signatures”.


·         The text sometimes suggests that a secure group context is linked to one and only one multicast IP address. In practice, there may be more variety – e.g. one multicast IP address plus one or more unicast IP addresses to which the group message is subsequently delivered. E.g. repeat of the group message to members which did not get it yet. The proposed solution could be reviewed with that view in mind, that there may be multiple (multicast/unicast) IP destination addresses to which a group message will be sent. I did not do that yet; can do so in a future in-depth review.


[MT] Thanks, that’s a very good comment. We’ll think more on the possible view you propose. It should be fine as long as a recipient is able to retrieve the right group Security Context, by using the Gid.



Section 2.1
Some things here are listed as out of scope, but they do come back later in the doc – such as forward security and backward security , which are addressed I think – certainly not out of scope.


[MT] Group OSCORE does not ensure forward security and backward security itself. Instead, they are entrusted to the specifying group rekeying protocol enforced by the Group Manager. The specific rekeying protocol if out of scope for Group OSCORE, which however recommends the use of one able to ensure backward and forward security in the group.



Section 3
" Gid MUST be random " -> seems to contradict Appendix B which uses an Epoch counter in the Gid.  Should it say “MUST have a random component” ?


[MT] Right, now fixed (in current Appendix C).



Appendices

  *   Appendix B, a concrete example instance is missing. E.g. “w3fj90f0a_0042” or its bstr equivalent  (just guessing here to the format)


[MT] We added an example, in current Appendix C.



  *
  *   Appendix C, is this an example blueprint of how to do it – fully optional to follow or not follow this?


[MT] We relaxed the text in current Appendix D, as for the time being it is intended to be a guideline example.



  *

Minor

  *   ligthing -> lighting
  *   enpoint  -> endpoint
  *   Pg 25 , [I-D.ietf-ace-dtls-authorize] reference breaks across line and as such becomes non-searchable in the browser. And I like these refs to be searchable 😉





From: core [mailto:[e-mail]] On Behalf Of Jaime Jiménez
Sent: Thursday, November 23, 2017 17:59
To: [e-mail]<mailto:[e-mail]> WG ([e-mail]<mailto:[e-mail]>) <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [core] 🔔 WG Call for Adoption on draft-tiloca-core-multicast-oscoap

Dear all,

The draft on "Secure group communication for CoAP" ( draft-tiloca-core-multicast-oscoap<https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap/> ) had in room consensus for adoption during IETF99 already, now we are clear to confirm it on the mailing list.

Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment.

Target to end the WGA is 14th of December.

Ciao,
- - Jaime Jiménez


________________________________
The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email.




_______________________________________________

core mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/core



--

Marco Tiloca, PhD

Research Institutes of Sweden

RISE ICT/SICS

Isafjordsgatan 22 / Kistagången 16

SE-164 40 Kista (Sweden)

Phone: [phone]

https://www.sics.se



The RISE institutes Innventia, SP and Swedish ICT

have merged in order to become a stronger research

and innovation partner for businesses and society.



SICS Swedish ICT AB, has now changed name to RISE SICS AB.