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

[Göran Selander <[e-mail]>]

Hi Esko,

Thanks for good comments!

Let’s recap the setting: The sender and recipient of a group OSCORE message needs to retrieve/derive the right security context for sending and receiving requests and responses, and the amount of data sent for this purpose should be as small as possible. This should apply to all phases of communication; first time, normal operation, after member has been excluded, etc.


The OSCORE message format includes the 'kid' and the 'kid context'. For the group setting:

* the kid contains the ID of the sending group member (Sender ID), unique in the group, assigned by the group manager (which could be just a short byte string).

* The kid context contains the group identifier, also assigned by the group manager and unique for this group manager. The kid context is a "context hint” helping the recipient endpoint find the security context. If endpoints are deployed with multiple uncoordinated group managers then they need to be able to handle coinciding group identifiers, e.g. by trying multiple security contexts to see if if any verifies. As long as the Master Secret is different for different groups (and different epochs of a group) and the Sender IDs within the group are unique, that is sufficient to make AEAD key and nonce different.


So there is no need for negligable probabilty of coinciding group identifiers as long as the recipient can find its way to the right security context. But in the case of an endpoint being in multiple groups managed by different group managers, it is of course favourable if the group identifiers are different. So we should rephrase this accordingly.


Further comments inline.

From: core <[e-mail]<mailto:[e-mail]>> on behalf of Esko Dijk <[e-mail]<mailto:[e-mail]>>
Date: Wednesday 7 March 2018 at 09:29
To: Marco Tiloca <[e-mail]<mailto:[e-mail]>>, Jaime Jiménez <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]> WG ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [core] 🔔 WG Call for Adoption on draft-tiloca-core-multicast-oscoap

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?

See above.

Maybe in this example the Group Managers pick a random value and then mutually verify that there are no collissions?


Yes, if there is coordination between group managers, but this is not necessary for the scheme to work as noted above.

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.


The intent was that the Group ID consists of a Group Prefix and a Group Epoch. The need for a group prefix is to allow a constant identifier of the group. The need for group epoch is to allow endpoints to find the right Master Keys used in the group at a certain time.

 Group identifiers may be constructed in other ways that makes the recipient find the right security context.

Hope that helps.

Thanks,
Göran


Esko



From: Marco Tiloca <[e-mail]<mailto:[e-mail]>>
Sent: Monday, March 5, 2018 23:18
To: Esko Dijk <[e-mail]<mailto:[e-mail]>>; Jaime Jiménez <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[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.