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

[Marco Tiloca <[e-mail]>]

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 hassource authentication
among two parties directly from the usage of the AEAD. Instead, in the
group communication setting considered bygroup 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 hassource 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 aseparate 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 Sections4.2 and 4.4about 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.