Hi Jim, Thanks a lot for your detailed review, as you might have seen we have included most comments in the latest version: https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02 Please note that this version includes also review comments from Peter, which in some cases overlapped, so some text might be reformulated to include both inputs.
Inline, detailed comments and some questions. Thanks, Francesca On 13/07/2018, 20:38, "Ace on behalf of Jim Schaad" <[email protected] on behalf of [email protected]> wrote: * Section 2 - client - write rights and/or read rights. Unless you think that write implies read in which case you should state that FP: Right, we now specify: " It can request write and/or read rights." * Section 2 - KDC - should also say what it does in the later parts - FP: Ok, we added the following text: " During the second part (Section 4), which is not based on the ACE Framework, it distributes the keying material." We also added details about the role of the KDC for redistribution of keying material. * Section 2 - Dispatcher - If this is a bus, then you are not really communicating with it securely. Anybody can write on it, but people will just ignore what comes out the other end. FP: Right, reformulated in " entity through which the Clients communicate with the group and which distributes messages to the group members." * Section 3- A brief description of all of the operations would be appreciated. FP: we have now added several sections to describe the operations. In section 2 (starting with " This document specifies the message flows and formats for:") we describe the high level operations. At the beginning of each section (3. and 4.) we also give an overview of the exchange described in the subsections. * Section 3.1 - Can I get authorization for multiple items at a single time? FP: In theory, it would be possible, and that would require to change the format of scope, going from [ group-id, [role1, role2] ] to [ [group-id1, group-id2], [[role1, role2], [role1]] ]. We haven't implemented this change, because it seems to cause a lot of overhead and complexity, for what seems to be a corner case. But if people think this is a valid use case, we can reconsider. We have added a placeholder comment in the md for this. * Section 3.1 - Does it make sense to allow for multiple audiences to be on a single KDC? FP: I am not sure I understand the scenario, could you expand on this? (We have added a comment in the md for this as well) * Section 4.x - cnf - text does not allow for key identifier FP: Did you get the section wrong? In 4.x we do not use cnf. In which section exactly would you send the kid in the cnf? That should be defined in the Ace framework (and params)... * Section X.X - Define a new cnf method to hold the OSCORE context parameters - should it be a normal COSE_Key or something new just to makes sure that it is different. FP: This is the same comment as in the OSCORE Profile. Again, I am not sure why we really need a new structure since COSE_Key is general enough to transfer all the keying material, with the addition of the couple of new parameters defined. But if you think this is necessary, we can definitely change. * Section 3.X - I am not sure if write or POST is a better answer for what the role being requested is. FP: Again, I don't understand this comment. We don't really define what one should use as role, write or POST are both possible. * Section 4 - Should one talk about the ability to use OBSERVE as part of key distribution? FP: We added a comment as a placeholder for this in the md. Observe was just briefly mentioned before and not really elaborated. Although it would work, it seems not useful to have it together with a proper rekeying scheme where the KDC takes the initiative anyway. * Section 4.x - I am having a hard time trying to figure out the difference between a group and a topic. The text does not always seem to distinguish these well. FP: It was our purpose to keep the text high level enough so that it would apply to both. Does that create any problem/confusion? * Seciton 4.1 - POP on client key esp if bound to an identity (Note using it to access the KDC is one POP) FP: Now added the following text at the end of section 4.: " Note that proof-of-possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access token for establishing secure communication between the Client and the KDC." * Section 4.2 - why not use the exp field from OAUTH in the response FP: the exp field from the AS in the response relates to the token. This exp relates to the keying material. Yes, when the token expires the keying material should expire (and that is specified e.g. in the OSCORE profile), but it could expire before/independently as well. * Question - does somebody talk about doing key derivation for a new kid showing up and by the way where is the gid FP: It's in oscore-groupcomm that we describe how a new Recipient Context is derived. This document keeps a high livel perspective (so it does not talk about Gid), while in ace-oscoap-join we explain how the current Group ID is provided to a joining node (in the 'serverID' parameter of the COSE Key in the Join Response). * Seciton 4.2 - if you are using profile, then you should return it FP: The Key distribution request and response, although inspired by ACE, do not use ACE, so "profile" is not really defined here. The profile is used in the first phase, between C - AS - KDC, and it is returned there. * Introduction - introduce the concept of a key management protocol and point to some. Give some basic properties expected from one. FP: Some text was added at the end of the introduction: " If the application requires backward and forward security, updated keying material is generated and distributed to the group members (rekeying), when membership changes. A key management scheme performs the actual distribution of the updated keying material to the group. In particular, the key management scheme rekeys the current group members when a new node joins the group, and the remaining group members when a node leaves the group. This document provides a message format for group rekeying that allows to fulfill these requirements. Rekeying mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627]." * Section 5.2 - What is the message to leave - can I leave one scope but not another? Can I just give up a role? FP: We have now added a TBD: format of the message to leave the group placeholder in Section 5.2. We will address this in a future update. The leave is intended per group, so one scope at the time losing all the roles in that group. Giving up a single role while remaining in the group does not require any particular interaction with the GM. It's just sufficient to stop behaving as that role. * Seciton 6.1 - assumes scopes are unique across all audiences. Or assumes that I look up the correct token - should have an argument about why this is possible so that people can implement it right FP: We already had the check for the access token for a first time key distribution. We have added the following text in section 6.2: "the KDC receiving a Key Re-Distribution Request MUST check that it is storing a valid Access Token from that client for that scope." We also have added a TODO: defines error response if it does not have it / is not valid. Would that be enough? * Comment somewhere about getting strike zones setup correctly for a newly seen sender of messages. Ptr to OSCORE? FP: Sorry I don't understand what you mean by strike zones. Could you expand on that? Jim _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
