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

[peter van der Stok]

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.
Why is source authentication more important (mentioned separately) than
all other security aspects of OCORE?

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?
Across intermediary nodes -> possibly involving intermediary nodes.
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).
Remove: “while fulfilling the same security requirements”. My
suggestion: end-to-end security is assured by using the same security
technology as for OSCORE.
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?

Section 1.1
Multicaster: Is M <= N? sub-question is: are the destinations always all
group members and is the source also a destination? May be you should
refer to section 2.2 which provides a better explanation.
Endpoint ID: why this exclusion of pure listeners? It complicates the
protocol.
Remove: “That is, …. same time”. Does not clarify uniqueness.

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.
Section 2.1a Requirements on group manager, section 2.1b, Protocol
characteristics.

Multicast communication topology: remove the lighting use case, and
refer to appendix.
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.

Establishment and Management of Security context: I recommend to mention
relation to OSCORE security contexts. 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.

Multicast data security Cipher suite: GM requirement??

Backward security: 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?

Forward security: GM requirement?.

Section 2.2 security Objectives
Bullet 2; remove “In fact, …plaintext” ; does not add much
Bullet 3: shall be authenticated with respect to two sources (sender and
group) (simultaneously?)

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.
Point 1, bullet 2: “ … once the security context is established”: do you
mean the common context?
Point 2, The phrase “In practice, … OSCORE messages” is difficult to
understand (at least I see multiple explanations)
Do you mean that SenderID is equal to its endpointID received at
joining?
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.
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.

Section 3.1 Remove: “such a risk… office buildings. Nevertheless”. The
fun with drones provided by Dutch universities, proves these assumptions
to be futile.

Distribution of master key is another GM requirement.

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)
Bullit 2 star 1: Is the group’s Security Context equal to the Common
context?

Figure 1 differs from figure 7 in 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.

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.

Point 1; stores where? Find where?

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.

Section 6; I think that synchronizing sequence numbers is part of the
standard and should be specified as requirement on the GM.

Section 7.1 Remove “for instance .. those roles” Refer to appendix A.

Section 7; Don’t you need some discussion on size of group to discuss
security breach probabilities?

Appendix A
lighting control; here you refer to multicast group, which is sometimes
correct. In the introduction you talk about group communication.
Switches but also sensors can control the state of the lights. Why is
the backbone multicast enabled? Is that a MUST?
Events within a 200 ms interval are perceived as simultaneous by humans.
Necessary in many configurations.

In Building control, intervals of seconds are sufficient.

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.

Emergency multicast; Also interesting, but that needs a fault tolerant
multicast algorithm, like MPL. for example.

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)

C.1 bullit management keying material: depend -> depends

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.

Appendix D. Are the proposed options interoperable within a group? Also
here I would advocate interoperable solutions only.

[Marco Tiloca]

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

Post by peter van der Stok
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
“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.”

Post by peter van der Stok
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”.

Post by peter van der Stok
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.

Post by peter van der Stok
Across intermediary nodes -> possibly involving intermediary nodes.

[MT] Done.

Post by peter van der Stok
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.”

Post by peter van der Stok
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”.

Post by peter van der Stok
“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”.

Post by peter van der Stok
Section 1.1
Multicaster: Is M <= N?

[MT] Not necessarily.

Post by peter van der Stok
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.

Post by peter van der Stok
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?

Post by peter van der Stok
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.

Post by peter van der Stok
Remove: “That is, 
. same time”. Does not clarify uniqueness.

[MT] Done.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
Multicast communication topology: remove the lighting use case, and
refer to appendix.

[MT] Done.

Post by peter van der Stok
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 
”.

Post by peter van der Stok
Establishment and Management of Security context: I recommend to
mention relation to OSCORE security contexts.

[MT] Done.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
Section 2.2 security Objectives
Bullet 2; remove “In fact, 
plaintext” ; does not add much

[MT] Done.

Post by peter van der Stok
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?

Post by peter van der Stok
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.

Post by peter van der Stok
Point 1, bullet 2: “ 
 once the security context is established”: do
you mean the common context?

[MT] Yes, now clarified.

Post by peter van der Stok
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”.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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”.

Post by peter van der Stok
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.

Post by peter van der Stok
Figure 1 differs from figure 7 in OSCORE draft

[MT] Figure 1 actually is related to Figure 8 in the OSCORE draft.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
Section 7.1  Remove “for instance .. those roles” Refer to appendix A.

[MT] Done (now Appendix B).

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
Events within a 200 ms interval are perceived as simultaneous by
humans. Necessary in many configurations.

[MT] Ok, now mentioned.

Post by peter van der Stok
In Building control, intervals of seconds are sufficient.

[MT] Ok, now mentioned.

Post by peter van der Stok
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.

Post by peter van der Stok
Emergency multicast; Also interesting, but that needs a fault tolerant
multicast algorithm, like MPL. for example.

[MT] Ok, now mentioned.

Post by peter van der Stok
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.

Post by peter van der Stok
C.1  bullit management keying material: depend -> depends

[MT] I think that “depend” is correct. The subject is “elements”.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

[peter van der Stok]

Hi Marco,

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

Peter

Post by Marco Tiloca
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

Post by peter van der Stok
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
“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.”

Post by peter van der Stok
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”.

Post by peter van der Stok
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.

Post by peter van der Stok
Across intermediary nodes -> possibly involving intermediary nodes.

[MT] Done.

Post by peter van der Stok
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.”

Post by peter van der Stok
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”.

Post by peter van der Stok
“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”.

Post by peter van der Stok
Section 1.1
Multicaster: Is M <= N?

[MT] Not necessarily.

Post by peter van der Stok
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.

Post by peter van der Stok
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?

Post by peter van der Stok
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.

Post by peter van der Stok
Remove: “That is, …. same time”. Does not clarify uniqueness.

[MT] Done.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
Multicast communication topology: remove the lighting use case, and
refer to appendix.

[MT] Done.

Post by peter van der Stok
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
…”.

Post by peter van der Stok
Establishment and Management of Security context: I recommend to
mention relation to OSCORE security contexts.

[MT] Done.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
Section 2.2 security Objectives
Bullet 2; remove “In fact, …plaintext” ; does not add much

[MT] Done.

Post by peter van der Stok
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?

Post by peter van der Stok
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.

Post by peter van der Stok
Point 1, bullet 2: “ … once the security context is
established”: do you mean the common context?

[MT] Yes, now clarified.

Post by peter van der Stok
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”.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.
- 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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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”.

Post by peter van der Stok
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.

Post by peter van der Stok
Figure 1 differs from figure 7 in OSCORE draft

[MT] Figure 1 actually is related to Figure 8 in the OSCORE draft.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
Section 7.1 Remove “for instance .. those roles” Refer to appendix A.

[MT] Done (now Appendix B).

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
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.

Post by peter van der Stok
Events within a 200 ms interval are perceived as simultaneous by
humans. Necessary in many configurations.

[MT] Ok, now mentioned.

Post by peter van der Stok
In Building control, intervals of seconds are sufficient.

[MT] Ok, now mentioned.

Post by peter van der Stok
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.

Post by peter van der Stok
Emergency multicast; Also interesting, but that needs a fault
tolerant multicast algorithm, like MPL. for example.

[MT] Ok, now mentioned.

Post by peter van der Stok
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.

Post by peter van der Stok
C.1 bullit management keying material: depend -> depends

[MT] I think that “depend” is correct. The subject is
“elements”.

Post by peter van der Stok
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.

Post by peter van der Stok
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.