Re: [core] tiloca-core-muticast-oscoap-4

[peter van der Stok <[e-mail]>]

Hi Marco,

thanks for your reaction.
I will read the new version and comment on that.

Peter

Marco Tiloca schreef op 2018-03-05 23:58:
> Hello Peter,
> 
> Thank you for your review and comments. Please, find some answers in
> line.
> 
> We took into account your comments for producing the latest version of
> the  draft [1]. Please, find some answers in line.
> 
> Best,
> /Marco
> 
> [1] https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-01
> 
> On 2018-02-06 12:04, peter van der Stok wrote:
> 
>> Hi authors,
>> 
>> Many thanks for this very useful document. Below some comments.
>> These are mainly restricted to document structure, relation to other
>> documents, and new concepts and terminology. I hope they are
>> sufficiently clear and help improving the text.
>> 
>> Peter
>> 
>> Abstract:
>> I did not see text that validates the phrase:
>> “All security requirements fulfilled by OSCORE are
>> maintained for multicast OSCORE request messages and related OSCORE
>> response messages.”
>> I did see: this document specifies the parameter values for OSCORE
>> messages applied to group communication.
> 
> [MT] Now rephrased as: “In particular, it is defined how OSCORE
> should be used in a group communication setting, while fulfilling the
> same security requirements for request messages and related response
> message.”
> 
>> Why is source authentication more important (mentioned separately)
>> than all other security aspects of OCORE?
> 
> [MT] In the main OSCORE specification, one has source authentication
> among two parties directly from the usage of the AEAD. Instead, in the
> group communication setting considered by group OSCORE, the Common
> Context is sufficient to ensure group authentication, while the same
> components alone are not sufficient to achieve source authentication
> too. This is the reason why we additionally introduce
> countersignatures trough each individual endpoint's private key, and
> why we present source-authentication as a specific requirement to be
> “brought back again”.
> 
>> Introduction:
>> Benefit from a group communication model: A possible group
>> communication model is the use of unicast for all individual
>> destinations; I don’t see how this increases efficiency. May-be
>> you mean: leveraging the broadcast model of the underlying
>> communication medium?
> 
> [MT] Yes, that's right, however this should already come from RFC7390.
> The advantage from the underlying communication model is limited to
> requests.
> 
>> Across intermediary nodes -> possibly involving intermediary nodes.
> 
> [MT] Done.
> 
>> The phrase: “To this end, …. protected message” is funny. I
>> did not know that you could protect messages by including payload
>> (something went wrong in this phrase).
> 
> [MT] We rephrased as “To this end, a CoAP message is protected by
> including its payload (if any), certain options, and header fields in
> a COSE object, which finally replaces the authenticated and encrypted
> fields in the protected message.”
> 
>> Remove: “while fulfilling the same security requirements”. My
>> suggestion: end-to-end security is assured by using the same
>> security technology as for OSCORE.
> 
> [MT] As aligned with the main OSCORE document, we rephrased as “so
> that end-to-end security is assured by using the same security
> method”.
> 
>> The OSCORE draft mentions:
>> “providing end-to-end encryption, integrity, replay protection,
>> and
>> secure the binding of response to request”. It does not mention
>> source authentication explicitly. So, why is multicast-oscoap
>> different?
> 
> [MT] In OSCORE, one has source authentication among two parties
> directly from the usage of the AEAD. Instead, in the group
> communication setting considered by group OSCORE, the Common Context
> is sufficient to ensure group authentication, while the same
> components alone are not sufficient to achieve source authentication
> too. This is the reason why we additionally introduce
> countersignatures trough each individual endpoint's private key, and
> why we present source-authentication as a specific requirement to be
> “brought back again”.
> 
>> Section 1.1
>> Multicaster: Is M <= N?
> 
> [MT] Not necessarily.
> 
>> sub-question is: are the destinations always all group members and
>> is the source also a destination?
> 
> [MT] Destinations are always group members, while a source is not
> necessarily a destination, it depends on the role(s) in the group. For
> example, an endpoint configured only as multicaster will be
> only-source in a group where all the other members are configured as
> pure listeners.
> 
>> May be you should refer to section 2.2 which provides a better
>> explanation.
> 
> [MT] Section 2.2 has now become Appendix A.2, in order to have the
> document body more in synch with the main OSCORE document. Which
> portion(s) of Appendix A.2 do you think it is better to point at?
> 
>> Endpoint ID: why this exclusion of pure listeners? It complicates
>> the protocol.
> 
> [MT] This was previously discussed with Jim, as a group member
> configured _only_ as pure listener does not need to receive upon join
> (and thereafter store) an Endpoint ID. In fact, that endpoint is never
> going to transmit group messages where including its own Endpoint ID
> as Sender ID.
> 
>> Remove: “That is, …. same time”. Does not clarify uniqueness.
> 
> [MT] Done.
> 
>> Section 2.
>> I do understand the purpose of section 2.2, but not of section 2.1.
>> As far as I understand the Group Manager is essential for secure
>> group communication as specified here; No GM means no group
>> communication (is that correct?) In that case I would suggest two
>> other subsections.
> 
> [MT] “No GM means no group communication” is essentially correct
> in this context, as there would be no provisioning of keying material
> to joining endpoints. To be more precise, with no GM: i) group
> membership has to be static; and ii) all key provisioning has to be
> done once and for all before deployment through other means.
> 
>> Section 2.1a Requirements on group manager, section 2.1b, Protocol
>> characteristics.
> 
> [MT] Also related to other comments, we now have a new Section 6
> listing the responsibilities of the Group Manager (that is, your
> proposed Section 2.1a). Instead, your proposed Section 2.1b is
> essentially the current Appendix A. This was driven by having the
> document body more in synch with the main OSCORE document.
> 
>> Multicast communication topology: remove the lighting use case, and
>> refer to appendix.
> 
> [MT] Done.
> 
>> Multicast group size: is this the number of members? The fact that a
>> member may be listener as well as multicaster is another aspect and
>> not relevant to size. The numbers are interesting to guide
>> implementers.
> 
> [MT] We now put less stress on the roles of group members, but we
> would anyway keep the roles related to the indicative numbers
> provided, i.e. “… The group size is the current number of members
> in a multicast group. In the use cases mentioned in this document, the
> number of multicasters (normally the controlling devices) is expected
> to be much smaller than the number of listeners (i.e. the controlled
> devices). A security solution for group communication that supports 1
> to 50 multicasters would be able to properly cover the group sizes
> required for most use cases that are relevant for this document
> …”.
> 
>> Establishment and Management of Security context: I recommend to
>> mention relation to OSCORE security contexts.
> 
> [MT] Done.
> 
>> Actually, the text seems to discuss requirements on the GM. GM
>> specification is out of scope but not any GM design can be used with
>> oscoap-multicast.
> 
> [MT] Also related to other comments, we now have a new Section 6
> listing the responsibilities of the Group Manager. Do you think any
> particular additional requirement/responsibility on the Group Manager
> is missing?
> 
> [MT] Note that the Group Manager is not expected to necessarily be an
> actual member of the group. That is, it needs to
> generate/manage/provide OSCORE Contexts upon joining and to renew
> Common Contexts within the group, but it is not required to
> communicate by means of group OSCORE itself.
> 
>> Multicast data security Cipher suite: GM requirement??
> 
> [MT] I would not say so. The Group Manager indicates keying material
> and security parameters to new endpoints during the join process (see
> current Section 6 and current Appendix D), specifying also the
> security Cipher Suite to use in the group. However, the Group Manager
> is not required to use such Cipher Suite itself, unless it is also an
> actual group member.
> 
>> Backward security: GM requirement?
> 
> [MT] This is actually a requirement of the group rekeying scheme used
> by the GM to manage the group keying material. So I would not say it
> is a GM requirement.
> 
>> Actually, this poses the question of ordering of messages from
>> different sources; Is there a total ordering of messages or only a
>> partial source order? (I see this is explained in section 2.2) May
>> be a forward reference?
> 
> [MT] At the beginning of current Section 4, we now list the security
> objectives fulfilled by group OSCORE, and point at current Appendix
> A.2 for further details.
> 
>> Forward security: GM requirement?
> 
> [MT] This is actually a requirement of the group rekeying scheme used
> by the GM to manage the group keying material. So I would not say it
> is a GM requirement.
> 
>> Section 2.2 security Objectives
>> Bullet 2; remove “In fact, …plaintext” ; does not add much
> 
> [MT] Done.
> 
>> Bullet 3: shall be authenticated with respect to two sources (sender
>> and group) (simultaneously?)
> 
> [MT] We have group authentication already from the usage of the AEAD,
> plus source authentication through the countersignature. Do you think
> we should have source authentication as a separate bullet?
> 
>> Section 3;
>> Suggestion: Each endpoint stores extensions of the Oscore context. I
>> seem to read that the Contexts used for group communication are
>> extensions to the one specified for OSCORE. If that is true, use
>> different names or use extension of .
>> Common context -> group context? In OSCORE the common context is
>> defined as common between send and receiver, not common to the
>> group.
> 
> [MT] We actually need both “Common context” and “Group
> Context”, as different concepts. In each endpoint, “Group
> Context” is what you would implicitly define as “pair context”
> in OSCORE, and it similarly includes a “Common context”, a
> “Sender context” and _multiple_ (unlike OSCORE) “Recipient
> contexts”, all of which with additional elements with respect to
> their equivalent in OSCORE.
> 
>> Point 1, bullet 2: “ … once the security context is
>> established”: do you mean the common context?
> 
> [MT] Yes, now clarified.
> 
>> Point 2, The phrase “In practice,  … OSCORE messages” is
>> difficult to understand (at least I see multiple explanations)
> 
> [MT] We have rephrased as: “In practice, the symmetric keying
> material in the Sender Context of the sender endpoint is shared with
> all the recipient endpoints that have received group messages from
> that same sender endpoint.”
> 
> [MT] Also, we have similarly rephrased the related sentence in the
> paragraph below about the Recipient Context, i.e.: “In practice, the
> symmetric keying material in a given Recipient Context of the
> recipient endpoint is shared with the associated sender endpoint from
> which group messages are received”.
> 
>> Do you mean that SenderID is equal to its endpointID received at
>> joining?
> 
> [MT] Yes, we have clarified it in the definition of Endpoint ID in
> Section 1.1.
> 
>> It would be nice to give tables with additions to OSCORE security
>> context for Sender Context, Recipient Context and Common (group)
>> context; Now one has to search for them in the text.
> 
> [MT] Done.
> 
>> Point 3 Is Recipient Id also equal to endpointID. The text about
>> Recipient context creation is unclear. Is the creation done by the
>> Recipient endpoint? How are the contexts shared? Who does the
>> sharing? Or do you mean that they are copied over at reception?
>> Sender pubic key is extracted from Sender context (stored in GM, or
>> sent over with message?) or from a trusted key repository? This
>> paragraph is not very clear to me. Parts of the text are good
>> candidates for a GM requirements section. See my comments about
>> appendix C.
> 
> [MT] Also related to other comments, we now have a new Section 6
> listing the responsibilities of the Group Manager.
> 
> [MT] As to the other points:
> 
> - Like in OSCORE, the Recipient ID is the Endpoint ID of a sender
> endpoint from the perspective of the recipient endpoint.
> 
> - Yes, the creation of a Recipient Context is done by the recipient
> endpoint upon the reception of a first message from the corresponding
> other endpoint acting as sender endpoint. Now it is stated explicitly,
> and followed by a pointer to current Sections 4.2 and 4.4 about
> processing incoming messages.
> 
> - The sender's public key has to be retrieved anyway from a trusted
> key repository, using the Endpoint ID of such sender endpoint. As a
> possible configuration (see current Appendix D.2), the Group Manager
> can be configured to act as trusted key repository. This is also
> mentioned as an optional task of the Group Manager in the current
> Section 6.
> 
>> Section 3.1 Remove: “such a risk… office buildings.
>> Nevertheless”. The fun with drones provided by Dutch universities,
>> proves these assumptions to be futile.
> 
> [MT] Done.
> 
>> Distribution of master key is another GM requirement.
> 
> [MT] Also related to other comments, we now have a new Section 6
> listing the responsibilities of the Group Manager. The Group Manager
> distributes the OSCORE Master Secret as part of the Security Common
> Context.
> 
>> Section 4 bullit 1: The phrase “set to the SenderId of the
>> endpoint” creates the impression that an endpoint has multiple
>> IDs. Probably, you mean:  the SenderId of the Context is set to the
>> ID of the endpoint (or similar much better text)
> 
> [MT] The Sender ID is related to the endpoint, which has indeed a
> single one stored in its own Sender Context, but not to the Context.
> We rephrased as “set to the Endpoint ID of the endpoint transmitting
> the message, i.e. the Sender ID”.
> 
>> Bullit 2 star 1: Is the group’s Security Context equal to the
>> Common  context?
> 
> [MT] No, and we actually need both “Common context” and “Group
> Context”, as different concepts. In each endpoint, “Group
> Context” is what you would implicitly define as “pair context”
> in OSCORE, and it similarly includes a “Common context”, a
> “Sender context” and _multiple_ (unlike OSCORE) “Recipient
> contexts”, all of which with additional elements with respect to
> their equivalent in OSCORE.
> 
>> Figure 1 differs from figure 7 in OSCORE draft
> 
> [MT] Figure 1 actually is related to Figure 8 in the OSCORE draft.
> 
>> Section 5; Suggestion: In case of malformed messages a “listening
>> only” receiver endpoint silently rejects the message and sends no
>> error message; all other receivers return an error message x.xx.
> 
> [MT] The current text was the result of a discussion with Jim at
> IETF99, to avoid congesting the group. Perhaps we can rephrase the
> current text as a possible conservative behavior, while adding what
> you suggest especially in case of groups that are small or hard to
> congest.
> 
>> Section 5.1
>> The document uses two terms: multicaster endpoint and sender
>> endpoint; I assume they are equal concepts; If yes, choose one, if
>> no, explain difference.
> 
> [MT] The definition of “Multicaster” is provided in Section 1.1,
> and it refers to an endpoint acting as “Sender” when transmitting
> group requests and “Recipient” when receiving responses. On the
> other hand, a sender can be a multicaster sending a group request or
> as well a listener sending a response. The concepts of “Sender”
> and “Recipient” as such as inherited from the main OSCORE
> document.
> 
>> Point 1; stores where? Find where?
> 
> [MT] I am not sure we should provide similar details here. Not even
> OSCORE specifies this in its Section 8.1, point 6.
> 
>> Section 5.2 point 2; It is not clear how a new Recipient context is
>> created; That is probably due to the vague duties of the GM.
> 
> [MT] It is created just like in OSCORE, plus the inclusion of the
> sender endpoint's public key to be separately retrieved.
> 
>> Section 6; I think that synchronizing sequence numbers is part of
>> the standard and should be specified as requirement on the GM.
> 
> [MT] The GM is expected to indicate to a joining endpoint the approach
> to follow. So, specifying the approach to use can be seen as a GM
> requirement, rather than enforcing that approach in the group itself.
> This is now also part of the GM's responsibilities listed in current
> Section 6.
> 
>> Section 7.1  Remove “for instance .. those roles” Refer to
>> appendix A.
> 
> [MT] Done (now Appendix B).
> 
>> Section 7; Don’t you need some discussion on size of group to
>> discuss security breach probabilities?
> 
> [MT] That's something more we can add. Input are welcome.
> 
>> Appendix A
>> lighting control; here you refer to multicast group, which is
>> sometimes correct. In the introduction you talk about group
>> communication.
> 
> [MT] A group displays group communication including delivery of
> multicast messages (requests) together with unicast messages
> (responses). We have revised the document and simply refer to
> “group” now.
> 
>> Switches but also sensors can control the state of the lights. Why
>> is the backbone multicast enabled? Is that a MUST?
> 
> [MT] That can be relaxed, as long as IP packets having a multicast
> destination address are correctly delivered all the way to the border
> routers acting as entry points.
> 
>> Events within a 200 ms interval are perceived as simultaneous by
>> humans. Necessary in many configurations.
> 
> [MT] Ok, now mentioned.
> 
>> In Building control, intervals of seconds are sufficient.
> 
> [MT] Ok, now mentioned.
> 
>> Commissioning of LLN system; Interesting idea that multicast should
>> be enabled on a subnetwork for discovery. However, that would be
>> after enrollment of the devices? I think the use case needs a bit
>> more thought.
> 
> [MT] Agree, we can think more about it and collect input.
> 
>> Emergency multicast; Also interesting, but that needs a fault
>> tolerant multicast algorithm, like MPL. for example.
> 
> [MT] Ok, now mentioned.
> 
>> Appendix C. I like this appendix, it provides the necessary
>> understanding how things will work in practice. Please keep this
>> appendix but also create a section with GM requirements, with the
>> purpose of the requirements explained in the appendix. (this is a
>> suggestion, don’t know if it will work actually)
> 
> [MT] Also related to other comments, we now have a new Section 6
> listing the responsibilities of the Group Manager.
> 
>> C.1  bullit management keying material: depend -> depends
> 
> [MT] I think that “depend” is correct. The subject is
> “elements”.
> 
>> C.3 I think the utilization of ACE framework SHOULD be part of the
>> standard. Too many options reduce the interoperability. Especially
>> standards about the GM seem rather crucial to me.
> 
> [MT] This is something we can further discuss in the WG. I personally
> support your view, while for the time being the ACE-based approach in
> current Appendix D.3 is seen as a possible incarnation of the more
> generic description in current Appendix D.1. It might be good to still
> leave room for alternative join approaches that are not based on ACE,
> as long as they correctly initialize new endpoints upon joining the
> group.
> 
>> Appendix D. Are the proposed options interoperable within a group?
>> Also here I would advocate interoperable solutions only.
> 
> [MT] Yes, they are. Upon joining, the Group Manager can possibly
> mention the synchronization policy to follow on a per-endpoint basis
> (see current Section 5 introducing this aspect at a high-level).
> 
>> 
> 
> --
> 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.