Re: [Ace] Comments on ace key groupcomm -01

[Francesca Palombini <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ace