Re: [Ace] [core] Fwd: review oscore-groupcomm-2

[Marco Tiloca <[e-mail]>]

Hi Peter,

Thanks a lot for your comments! We considered them for version -03.

Please, find our answers in line.

Best,
/Marco

On 9/20/18 10:02 AM, Peter van der Stok wrote:
>
> Hi authors,
>
> Thanks for this useful document.
>
> I have no comments on sections 3 and 4 that read rather easily.
>
> Some comments on the other sections follow below:
>
> Section 1.1
>
> Introduce group request (GR)-message and response message in relation
> to GR-client and GR-server to clarify text in section 2. To be used
> consistently throughout the text.
>

MT: The text actually uses the same terminology from CoAP and OSCORE,
i.e. "client", "server", "sender" and "recipient", as also stated in
Section 1.1. RFC7390 does not use those or similar terms.

MT: To simplify the text, we replaced "group message" with "message".

> End page 3. The phrase on the use of DTLS seems a bit far-fetched; Do
> you mean that multiple DTLS sessions are started for each group
> request sent by a client?
>

MT: We tried to clarify by adding the last sentence "Note that DTLS
cannot be used to secure messages sent over multicast." Other than that,
same considerations as in OSCORE apply here.

> Group ID: s/a same Group Manager/a given Group Manager/
>

MT: Done.

> End section 1.1; remove: “by a different group member or by a
> non-group-member” This only excludes itself.
>

MT: It's actually two different cases that we are both covering. We
rephrased as: "This also provides assurance that the message was not
tampered with by anyone, be it a different legitimate group member or an
endpoint which is not a group member".

> Section 2
>
> Where does the endpoint store all these contexts? I assume local
> storage is used.
>

MT: On this point, this document simply follows what defined in Section
7.5 of draft-ietf-core-object-security-15.

> Text substitution suggestions:
>
> s/Each endpoint in the group stores:/Each endpoint in a group makes
> use of:/
>
> s/endpoints in the group/endpoints in a given group/
>
> s/The ID Context parameter stores the group ID/The ID Context
> parameter contains the group ID/
>

MT: Done.

> The Sender context description is confusing. I understood that both a
> client when sending a group request, and a receiver when sending a
> response message use the sender context for sending the message. The
> text seems to suggest that only a group request need a sender context
> and not the response message.
>

MT: The first interpretation you give is in fact correct. An endpoint
always uses its own single sender context to secure an outgoing message,
regardless if it is a request or a response. Hopefully this is clearer
now that we have removed the term "group message".

> If the Sender context applies only to group request messages, the term
> request context is more appropriate and distinguishes from the sender
> context in OSCORE
>

MT: See above.

> Same confusion about the recipient context; the text seems to exclude
> that a group request client also needs a recipient context.
>

MT: An endpoint always decrypts an incoming message using its own
recipient context associated to the other group member sending that
message. This applies to all incoming messages, regardless if it is a
request or a response.

> Table 1:  why “each” Recipient context and not “each” sender context?
>

MT: The table refers to one given endpoint, which has: i) one common
context; ii) one sender context, used to secure its own outgoing
messages; iii) multiple recipient contexts to process incoming messages,
i.e. one recipient context for each other endpoint in the group sending
such incoming messages to this recipient endpoint.

> Public key of the associated other endpoint: is this the group request
> client endpoint or any endpoint sending to this recipient?
>

MT: Any other endpoint sending to this recipient endpoint.

> Section 2.1:  should the section not refer to oscoap-joining draft in ACE?
>

MT: The text in this section has been slightly restructured. It still
gives an intuition of the issue at hand, while also pointing at the
ace-oscoap-joining draft now covering also group rekeying through the
Group Manager.

> Section 3 ‘kid’ parameter value; Does this only apply to response
> messages sent by group request servers?
>

MT: Now the text explicitly says that, unlike in OSCORE, 'kid' is always
present in all messages, i.e. both requests and responses.

> Section 5; I don’t think that I understand the problem. One of the
> conditions is that a client which is not part of a group cannot
> decrypt the group messages, and a client that has left the group
> cannot decrypt the group messages either. That constitutes already a
> pretty firm synchronization. My assumption was that this would be
> effectuated by distributing new master secret every time the group
> changes. In Appendix C, you suggest the epoch in the GID (Chaging the
> epoch, the GID may remain constant over group changes). My
> recommendation is to make the epoch compulsory for synchronization
> purposes.
>

MT: These are two different aspects. Section 5.1 (former Section 5) is
about enabling a late-joiner or a rebooted device to be synchronized
with the sequence numbers of requests sent by other group members.
Should this synchronization be lost, such a device would not be able to
assert the freshness of request messages using the replay window as per
Section 8.2 of draft-ietf-core-object-security-15.

MT: The epoch part of the Group ID enforces synchronization on the same
Common Security Context, so that all group members have the same Master
Secret, from which they can correctly derive the rest of the keying
material. For the time being, we are referring to the Prefix+Epoch
structure in Appendix C as an example of Gid format, since it would be
good to keep the possibility to have different ones as defined by the
application.

MT: We have extended Section 5.1 (former Section 5), with the new third
paragraph about sender endpoints that should store their outgoing
messages for an application-specific amount of time, sufficient to
handle possible retransmission of Non-Confirmable messages (such as
requests over Multicast).

> During membership of a group, a GR-client can consecutively number its
> messages starting at zero every time a new epoch is started (with a
> new master secret as specified in section 2.1). See also remark on A.2.
>

MT: The anti-replay check would be as simple as possible and just like
in draft-ietf-core-object-security-15. That is, sender Sequence Numbers
used as Partial IVs grow only as requests are transmitted. They are not
related with the occurring of a group rekeying and the consequent change
of Gid (e.g., as an increment of the Epoch part).

> Section 6,
>
> what is the relation of section 6 with with oscoap-joining. Is
> oscoap-joining required to validate all the requirements of section 6?
>

MT: The list in Section 7 (former Section 6) has been compacted. All
points but the first one are now directly related to the
ace-oscoap-joining draft, which now addresses also group rekeying.

> Methods to handle loss of synchronization are not responsibility of GM
> but responsibility of the sender of group request messages. No total
> ordering on all messages is required, only partial ordering on the
> messages of a given sender. I assume that the ordering of epochs is
> done by GM.
>

MT: We have removed the bullet on synchronization methods from the list.

MT: Ordering of epochs is indeed up to the GM.

> Trusted key repository: Also when the group manager makes use of an
> additional secure storage device, it remains responsible for the key
> repository.
>

MT: We have rephrased accordingly the last point in the list of Section
7 (former Section 6).

> Acting as a network router is out of scope IMO. RFCs exist to create
> and route group messages and it is immaterial which devices host the
> routing agents. This is also a subject of appendix D; same remark
> applies there as well.
>

MT: We have removed that bullet point from the list in Section 7 (former
Section 6).

> Autonomously and locally enforcing… ; what is the difference with
> bullet 2  of section 6?
>

MT: Thinking of the ace-oscoap-joining draft, bullet 2 meant that the GM
(i.e. an ACE RS) is expected to define group access policies to be
enforced by a third party (i.e. an ACE AS). The sentence you mention
considers the case where there is no such third party and the GM
entirely enforces access policies locally on its own.

MT: In the current list in Section 7 (former Section 6), the two points
have been merged into the current bullet 2.

> 7.1 I don’t understand the remark that all group members are trusted.
> What does that mean? IMU, They have been authorized to join a group
> and are trusted per definition.
>

MT: We have hopefully clarified by rephrasing the last paragraph of
Section 8.1 (former Section 7.1).

> 7.2 Case A and Case B refer to cases in OSCORE draft?
>

MT: Yes, we have now recalled them explicitly in Section 8.2 (former
Section 7.2)

> 7.3 Does it not need an explanation how one sender belonging to two
> groups with the same GID can be distinguished by a receiver that is
> member of these two groups as well? The text at the end of appendix C
> is not very convincing.
>

MT: We have slightly extended Section 8.5 (former Section 7.3), now also
referred by Section 2 when introducing the Gid and the handling of
possible collisions.

MT: The only problem at hand is an overlap of Group IDs, which results
in the recipient endpoint retrieving multiple Common Security Contexts.
As per Appendix C, the way to find the right Security Context is by
trial and error. Note that each attempt considers the same Sender ID
associated to the client sending the request, and specified in the 'kid'
parameter of the request. Also, uniqueness of Sender ID values within a
given group is ensured by the responsible GM. It follows that, once
found the right group and related Common Security Context, there is no
risk for the recipient endpoint to confuse the sender endpoint with a
different one in that group.

> A.1 bullet 2; remove: “e.g. by grouping lights…..”  (it is unknown how
> large groups in one room can be, leave alone a floor)
>

MT: Done.

> A.1 Establishments an management of security contexts: I hope that a
> general key management scheme is not necessary to provide the GM with
> a protocol to distribute new master secrets for the next group epoch.
>

MT: We don't need a whole new "general scheme". The GM can refer to one
rekeying protocol in agreement with all the group members.

MT: The exact protocol the GM uses to rekey the group is out of the
scope of this document. An actual way to rekey the group is now provided
in the ace-oscoap-joining draft.

> A.2
>
> Source Authentication, s/ensure/verify/
>

MT: Here "ensure" is more a short equivalent of "make it possible to
verify".

> Message Integrity, s/ensure/verify/
>

MT: Here "ensure" is more a short equivalent of "make it possible to
verify".

> Message ordering: Messages should be given a sequence number by the
> sender, a new coap option could be defined. Total ordering of the
> messages in a Group is not required.
>

MT: Like in draft-ietf-core-object-security-15 , each sender maintains
sequence numbers, and uses them as Partial IVs included in the OSCORE
option of requests and used for building the AEAD nonce.

MT: Current Section 5 now points explicitly to Section 7 "Message
Binding, Sequence Numbers, Freshness and Replay Protection" of
draft-ietf-core-object-security-15

>
> Appendix C: Could this text (or a variant) not become normative text
> to provide simple source ordering.
>

MT: For the time being, we think it would be good to allow for different
Gid structures, as defined by the application.

> Appendix D: first three paragraphs double with Appendix A, just
> differently formulated. Suggest to remove or better review separation
> with appendix A.
>

MT: We have re-written Appendix D. It is now much shorter, gives only a
high-level overview of a new endpoint set-up, and points at the
ace-oscoap-joining draft for the actual join process.

> See router comment of section 6.
>

MT: Done.

> Appendix D.1 is very informative but provides many choices. Oscoap
> join should specify the choices. According to me much of the text of
> Appendix D.1 should go to oscoap-join to motivate the choices made for
> oscoap join.
>

MT: The Appendix has been rewritten (see above).

> Appendix D.2. My suggestion is to make the GM the key repository, or
> connect a key repository to it, that needs to be accessed through the GM.
>

MT: The Appendix has been rewritten (see above).

MT: The draft now considers the GM as the key repository.

> Appendix D3. Should this not be normative text in oscoap-join?
>

MT: The Appendix has been rewritten (see above).

> Appendix E. A relation between message freshness and message ordering
> is suggested that I do not understand. When a sender sends only one
> message ever, the ordering is assured, but freshness is not guaranteed
> on reception.
>

MT: A recipient endpoint can have lost synchronization with the sender's
sequence number and hence not be able anymore to assert freshness by
relying only on its own local anti-replay window.

> Suppose only ordering is guaranteed with sequence numbers in the
> message; Losing messages can be detected. A procedure to receive lost
> messages is indeed necessary. But this involves storage of messages at
> the sender (how many?), and possibly re-encrypting to guarantee
> freshness when they are repeated on loss detection.
>

MT: Handling lost messages through retransmission happens like in OSCORE.

MT: We have added the new third paragraph in Section 5.1 (former Section
5) about sender endpoints storing Non-Confirmable messages to handle
possible retransmissions. Details are application-specific and out of
the scope of this document.

> Hope this helps.

MT: It really does, thanks a lot again!

>
> Greetings,
>
> peter
> -- 
> Peter van der Stok
> vanderstok consultancy
> mailto: [e-mail]
> <mailto:[e-mail]>, [e-mail]
> <mailto:[e-mail]>
> www: www.vanderstok.org <http://www.vanderstok.org>
> tel NL: [phone]     F: [phone]
>
> _______________________________________________
> Ace mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se