--- 1/draft-ietf-ace-key-groupcomm-oscore-03.txt 2020-01-15 07:13:44.737253740 -0800 +++ 2/draft-ietf-ace-key-groupcomm-oscore-04.txt 2020-01-15 07:13:46.141289451 -0800 @@ -1,349 +1,242 @@ ACE Working Group M. Tiloca Internet-Draft RISE AB Intended status: Standards Track J. Park -Expires: May 7, 2020 Universitaet Duisburg-Essen +Expires: July 18, 2020 Universitaet Duisburg-Essen F. Palombini Ericsson AB - November 04, 2019 + January 15, 2020 Key Management for OSCORE Groups in ACE - draft-ietf-ace-key-groupcomm-oscore-03 + draft-ietf-ace-key-groupcomm-oscore-04 Abstract - This document describes a method to request and provision keying - material in group communication scenarios where the group - communication is based on CoAP and secured with Object Security for - Constrained RESTful Environments (OSCORE). The proposed method - delegates the authentication and authorization of new client nodes - that join an OSCORE group through a Group Manager server. This - approach builds on the ACE framework for Authentication and - Authorization, and leverages protocol-specific transport profiles of - ACE to achieve communication security, proof-of-possession and server - authentication. + This specification defines an application profile of the ACE + framework for Authentication and Authorization, to request and + provision keying material in group communication scenarios that are + based on CoAP and secured with Group Object Security for Constrained + RESTful Environments (OSCORE). This application profile delegates + the authentication and authorization of Clients that join an OSCORE + group through a Resource Server acting as Group Manager for that + group. This application profile leverages protocol-specific + transport profiles of ACE to achieve communication security, server + authentication and proof-of-possession for a key owned by the Client + and bound to an OAuth 2.0 access token. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 7, 2020. + This Internet-Draft will expire on July 18, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Overview of the Joining Process . . . . . . . . . . . . . 7 - 2.2. Overview of the Group Rekeying Process . . . . . . . . . 8 - 3. Joining Node to Authorization Server . . . . . . . . . . . . 8 - 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 9 - 3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 - 4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 10 - 4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2. Joining Request . . . . . . . . . . . . . . . . . . . . . 12 - 4.3. Joining Response . . . . . . . . . . . . . . . . . . . . 13 - 5. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 17 - 6. Retrieval of Updated Keying Material . . . . . . . . . . . . 19 - 7. Retrieval of New Keying Material . . . . . . . . . . . . . . 19 - 8. Retrieval of Public Keys of Group Members . . . . . . . . . . 20 - 9. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 20 - 10. Retrieval of Keying Material Version . . . . . . . . . . . . 21 - 11. Request to Leave the Group . . . . . . . . . . . . . . . . . 21 - 12. Removal of a Group Member . . . . . . . . . . . . . . . . . . 21 - 13. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 22 - 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 - 15.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 24 - 15.2. OSCORE Security Context Parameters Registry . . . . . . 24 - 15.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 26 - 15.4. Sequence Number Synchronization Method Registry . . . . 26 - 15.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 27 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 16.1. Normative References . . . . . . . . . . . . . . . . . . 27 - 16.2. Informative References . . . . . . . . . . . . . . . . . 28 - Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 29 - Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 31 - B.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 31 - B.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 32 - B.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 32 - - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 + 2.1. Overview of the Joining Process . . . . . . . . . . . . . 5 + 2.2. Overview of the Group Rekeying Process . . . . . . . . . 6 + 3. Joining Node to Authorization Server . . . . . . . . . . . . 6 + 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6 + 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 + 4. Joining a Group . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Sending the Joining Request . . . . . . . . . . . . . . . 8 + 4.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 9 + 4.3. Processing the Joining Request . . . . . . . . . . . . . 10 + 4.4. Joining Response . . . . . . . . . . . . . . . . . . . . 11 + 5. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 14 + 6. Retrieval of Updated Keying Material . . . . . . . . . . . . 15 + 6.1. Retrieval of Group Keying Material . . . . . . . . . . . 16 + 6.2. Retrieval of Group Keying Material and Sender ID . . . . 16 + 7. Retrieval of New Keying Material . . . . . . . . . . . . . . 16 + 8. Retrieval of Public Keys of Group Members . . . . . . . . . . 17 + 9. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 18 + 10. Retrieval of Keying Material Version . . . . . . . . . . . . 18 + 11. Request to Leave the Group . . . . . . . . . . . . . . . . . 18 + 12. Removal of a Group Member . . . . . . . . . . . . . . . . . . 18 + 13. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 19 + 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 15.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 21 + 15.2. OSCORE Security Context Parameters Registry . . . . . . 22 + 15.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 23 + 15.4. Sequence Number Synchronization Method Registry . . . . 23 + 15.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 24 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 16.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 16.2. Informative References . . . . . . . . . . . . . . . . . 26 + Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 27 + Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 29 + B.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 29 + B.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 29 + B.3. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 30 + B.4. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 31 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] is a method for application-layer protection of the Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object Signing and Encryption (COSE) [RFC8152] and enabling end-to-end security of CoAP payload and options. As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is used to protect CoAP group communication over IP multicast - [RFC7390][I-D.dijk-core-groupcomm-bis]. This relies on a Group - Manager, which is responsible for managing an OSCORE group, where - members exchange CoAP messages secured with Group OSCORE. The Group - Manager can be responsible for multiple groups, coordinates the - joining process of new group members, and is entrusted with the - distribution and renewal of group keying material. - - This specification builds on the ACE framework for Authentication and - Authorization [I-D.ietf-ace-oauth-authz] and defines a method to: - - o Authorize a node to join an OSCORE group, and provide it with the - group keying material to communicate with other group members. - - o Provide updated keying material to group members upon request. - - o Renew the group keying material and distribute it to the OSCORE - group (rekeying) upon changes in the group membership. - - A client node joins an OSCORE group through a resource server acting - as Group Manager for that group. The joining process relies on an - Access Token, which is bound to a proof-of-possession key and - authorizes the client to access a specific group-membership resource - at the Group Manager. - - Message exchanges among the participants as well as message formats - and processing follow what specified in [I-D.ietf-ace-key-groupcomm] - for provisioning and renewing keying material in group communication - scenarios. + [I-D.dijk-core-groupcomm-bis]. This relies on a Group Manager, which + is responsible for managing an OSCORE group, where members exchange + CoAP messages secured with Group OSCORE. The Group Manager can be + responsible for multiple groups, coordinates the joining process of + new group members, and is entrusted with the distribution and renewal + of group keying material. - In order to achieve communication security, proof-of-possession and - server authentication, the client and the Group Manager leverage - protocol-specific transport profiles of ACE. These include also - possible forthcoming transport profiles that comply with the - requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. + This specification is an application profile of + [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE + framework for Authentication and Authorization + [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants + as well as message formats and processing follow what specified in + [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying + material in group communication scenarios, where Group OSCORE is used + to protect CoAP group communication over IP multicast. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. - Readers are expected to be familiar with the terms and concepts - described in the ACE framework for authentication and authorization - [I-D.ietf-ace-oauth-authz]. The terminology for entities in the - considered architecture is defined in OAuth 2.0 [RFC6749]. In - particular, this includes Client (C), Resource Server (RS), and - Authorization Server (AS). - - Readers are expected to be familiar with the terms and concepts - related to the CoAP protocol described in - [RFC7252][RFC7390][I-D.dijk-core-groupcomm-bis]. Note that, unless - otherwise indicated, the term "endpoint" is used here following its - OAuth definition, aimed at denoting resources such as /token and - /introspect at the AS and /authz-info at the RS. This document does - not use the CoAP definition of "endpoint", which is "An entity - participating in the CoAP protocol". + Readers are expected to be familiar with: - Readers are expected to be familiar with the terms and concepts for - protection and processing of CoAP messages through OSCORE [RFC8613] - and through Group OSCORE [I-D.ietf-core-oscore-groupcomm] in group - communication scenarios. These include the concept of Group Manager, - as the entity responsible for a set of groups where communications - are secured with Group OSCORE. In this specification, the Group - Manager acts as Resource Server. + o The terms and concepts described in the ACE framework for + authentication and authorization [I-D.ietf-ace-oauth-authz]. The + terminology for entities in the considered architecture is defined + in OAuth 2.0 [RFC6749]. In particular, this includes Client (C), + Resource Server (RS), and Authorization Server (AS). - This document refers also to the following terminology. + o The terms and concepts related to the CoAP protocol described in + [RFC7252][I-D.dijk-core-groupcomm-bis]. Unless otherwise + indicated, the term "endpoint" is used here following its OAuth + definition, aimed at denoting resources such as /token and + /introspect at the AS and /authz-info at the RS. This document + does not use the CoAP definition of "endpoint", which is "An + entity participating in the CoAP protocol". - o Joining node: a network node intending to join an OSCORE group, - where communication is based on CoAP - [RFC7390][I-D.dijk-core-groupcomm-bis] and secured with Group - OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. + o The terms and concept related to the message formats and + processing specified in [I-D.ietf-ace-key-groupcomm], for + provisioning and renewing keying material in group communication + scenarios. - o Joining process: the process through which a joining node becomes - a member of an OSCORE group. The joining process is enforced and - assisted by the Group Manager responsible for that group. + o The terms and concepts for protection and processing of CoAP + messages through OSCORE [RFC8613] and through Group OSCORE + [I-D.ietf-core-oscore-groupcomm] in group communication scenarios. + These include the concept of Group Manager, as the entity + responsible for a set of groups where communications are secured + with Group OSCORE. In this specification, the Group Manager acts + as Resource Server. - o Group name: stable and invariant identifier of an OSCORE group. - The group name MUST be unique under the same Group Manager, and - MUST include only characters that are valid for a url-path - segment, namely unreserved and pct-encoded characters [RFC3986]. + Additionally, this document makes use of the following terminology. - o Group-membership resource: a resource hosted by the Group Manager, - associated to an OSCORE group under that Group Manager. A group- - membership resource is identifiable with the name of the - respective OSCORE group. A joining node accesses a group- - membership resource to start the joining process and become a - member of that group. The url-path of a group-membership resource - is fixed, and ends with the segments /group-oscore/NAME , where - "NAME" is the name of the associated OSCORE group. This replaces - the url-path /ace-group/gid at the KDC used in - [I-D.ietf-ace-key-groupcomm], with "gid" indicating the group - identifier. The url-path /group-oscore/NAME is a default name: - implementations are not required to use this name, and can define - their own instead. + o Group name is used as a synonym for group identifier in + [I-D.ietf-ace-key-groupcomm]. - o Group-membership endpoint: an endpoint at the Group Manager - associated to a group-membership resource. + o GROUPNAME and NODENAME are used to indicate the variant parts of + the resource endpoint, i.e. "gid" and "node" URI path in + [I-D.ietf-ace-key-groupcomm]. o Requester: member of an OSCORE group that sends request messages to other members of the group. o Responder: member of an OSCORE group that receives request messages from other members of the group. A responder may reply back, by sending a response message to the requester which has sent the request message. o Monitor: member of an OSCORE group that is configured as responder and never replies back to requesters after receiving request messages. This corresponds to the term "silent server" used in [I-D.ietf-core-oscore-groupcomm]. - o Group rekeying process: the process through which the Group - Manager renews the security parameters and group keying material, - and (re-)distributes them to the OSCORE group members. - 2. Protocol Overview Group communication for CoAP over IP multicast has been enabled in - [RFC7390][I-D.dijk-core-groupcomm-bis] and can be secured with Group - Object Security for Constrained RESTful Environments (OSCORE) - [RFC8613] as described in [I-D.ietf-core-oscore-groupcomm]. A - network node joins an OSCORE group by interacting with the - responsible Group Manager. Once registered in the group, the new - node can securely exchange messages with other group members. - - This specification describes how to use the ACE framework for - authentication and authorization [I-D.ietf-ace-oauth-authz] to: - - o Enable a node to join an OSCORE group through the Group Manager - and receive the security parameters and keying material to - communicate with the other members of the group. - - o Enable members of OSCORE groups to retrieve updated group keying - material and public key of other group members, from the Group - Manager. + [I-D.dijk-core-groupcomm-bis] and can be secured with Group Object + Security for Constrained RESTful Environments (OSCORE) [RFC8613] as + described in [I-D.ietf-core-oscore-groupcomm]. A network node joins + an OSCORE group by interacting with the responsible Group Manager. + Once registered in the group, the new node can securely exchange + messages with other group members. - o Enable the Group Manager to renew the security parameters and - group keying material, and to (re-)distribute them to the members - of the OSCORE group (rekeying). + This specification describes how to use [I-D.ietf-ace-key-groupcomm] + and [I-D.ietf-ace-oauth-authz] to perform a number of authentication, + authorization and key distribution actions, as defined in Section 2. + of [I-D.ietf-ace-key-groupcomm], for an OSCORE group. - With reference to the ACE framework and the terminology defined in - OAuth 2.0 [RFC6749]: + With reference to [I-D.ietf-ace-key-groupcomm]: - o The Group Manager acts as Resource Server (RS), and hosts one - group-membership resource for each OSCORE group it manages. Each - group-membership resource is exported by a distinct group- - membership endpoint. During the joining process, the Group - Manager provides joining nodes with the parameters and keying - material for taking part to secure communications in the OSCORE - group. The Group Manager also maintains the group keying material - and performs the group rekeying process to distribute updated - keying material to the group members. + o The node wishing to joining the OSCORE group, i.e. the joining + node, is the Client. - o The joining node acts as Client (C), and requests to join an - OSCORE group by accessing the related group-membership endpoint at - the Group Manager. + o The Group Manager is the Key Distribution Center (KDC), acting as + a Resource Server. - o The Authorization Server (AS) authorizes joining nodes to join - OSCORE groups under their respective Group Manager. Multiple - Group Managers can be associated to the same AS. The AS MAY - release Access Tokens for other purposes than joining OSCORE - groups under registered Group Managers. For example, the AS may - also release Access Tokens for accessing resources hosted by - members of OSCORE groups. + o The Authorization Server associated to the Group Manager is the + AS. All communications between the involved entities rely on the CoAP protocol and MUST be secured. - In particular, communications between the joining node and the Group + In particular, communications between the Client and the Group Manager leverage protocol-specific transport profiles of ACE to achieve communication security, proof-of-possession and server - authentication. To this end, the AS MAY signal the specific - transport profile to use, consistently with requirements and - assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz]. - Note that in the commonly referred base-case the transport profile to + authentication. Note that it is expected that in the commonly + referred base-case of this specification, the transport profile to use is pre-configured and well-known to nodes participating in constrained applications. - With reference to the AS, communications between the joining node and - the AS (/token endpoint) as well as between the Group Manager and the - AS (/introspect endpoint) can be secured by different means, for - instance using DTLS [RFC6347] or OSCORE [RFC8613]. Further details - on how the AS secures communications (with the joining node and the - Group Manager) depend on the specifically used transport profile of - ACE, and are out of the scope of this specification. - 2.1. Overview of the Joining Process - A node performs the following steps in order to join an OSCORE group. - The format and processing of messages exchanged among the - participants follow what is defined in [I-D.ietf-ace-key-groupcomm], - and are further specified in Section 3 and Section 4 of this - document. The Group Manager acts as the Key Distribution Center - (KDC) defined in [I-D.ietf-ace-key-groupcomm]. - - 1. The joining node requests an Access Token from the AS, in order - to access a group-membership resource on the Group Manager and - hence join the associated OSCORE group (see Section 3). The - joining node will start or continue using a secure communication - association with the Group Manager, according to the response - from the AS. - - 2. The joining node transfers authentication and authorization - information to the Group Manager, by posting the obtained Access - Token to the /authz-info endpoint at the Group Manager (see - Section 4). After that, a joining node MUST have a secure - communication association established with the Group Manager, - before starting to join an OSCORE group under that Group Manager - (see Section 4). Possible ways to provide a secure communication - association are DTLS [RFC6347] and OSCORE [RFC8613]. - - 3. The joining node starts the joining process to become a member of - the OSCORE group, by accessing the related group-membership - resource hosted by the Group Manager (see Section 4). - - 4. At the end of the joining process, the joining node has received - from the Group Manager the parameters and keying material to - securely communicate with the other members of the OSCORE group. - - 5. The joining node and the Group Manager maintain the secure - association, to support possible future communications. These - especially include key management operations, such as retrieval - of updated keying material from the Group Manager or - participation to a group rekeying process (see Section 2.2). - - All further communications between the joining node and the Group - Manager MUST be secured, for instance with the same secure - association mentioned in step 2. + A node performs the steps described in Section 4.2 of + [I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The + format and processing of messages exchanged among the participants + are further specified in Section 3 and Section 4 of this document. 2.2. Overview of the Group Rekeying Process If the application requires backward and forward security, the Group Manager MUST generate new security parameters and group keying material, and distribute them to the group (rekeying) upon membership changes. That is, the group is rekeyed when a node joins the group as a new member, or after a current member leaves the group. By doing so, a @@ -364,318 +257,272 @@ 3. Joining Node to Authorization Server This section describes how the joining node interacts with the AS in order to be authorized to join an OSCORE group under a given Group Manager. In particular, it considers a joining node that intends to contact that Group Manager for the first time. The message exchange between the joining node and the AS consists of the messages Authorization Request and Authorization Response defined - in Section 3 of [I-D.ietf-ace-key-groupcomm]. - - In case the specific AS associated to the Group Manager is unknown to - the joining node, the latter can rely on mechanisms like the - Unauthorized Resource Request message described in Section 5.1.1 of - [I-D.ietf-ace-oauth-authz] to discover the correct AS to contact. + in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is + defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions + or modifications to that specification are defined here. 3.1. Authorization Request - The joining node contacts the AS, in order to request an Access Token - for accessing the group-membership resource hosted by the Group - Manager and associated to the OSCORE group. The Access Token request - sent to the /token endpoint follows the format of the Authorization - Request message defined in Section 3.1 of - [I-D.ietf-ace-key-groupcomm]. In particular: + The Authorization Request message defined in Section 3.1 of + [I-D.ietf-ace-key-groupcomm], with the following additions: - o The 'scope' parameter MUST be present and MUST include: + o The 'scope' parameter MUST be present. - * in the first element, the name of the OSCORE group to join - under the Group Manager, encoded as a CBOR text string. + o The group name of the OSCORE group to join under the Group Manager + is encoded as a CBOR text string. - * in the second element, the role (encoded as a text string) or - CBOR array of roles that the joining node intends to have in - the group it intends to join. Accepted values of roles are: - "requester", "responder", and "monitor". Possible combinations - are: ["requester" , "responder"]; ["requester" , "monitor"]. + o The role in the OSCORE group to join is encoded as a text string. + Accepted values of roles are: "requester", "responder", and + "monitor". Possible combinations are: ["requester" , + "responder"]; ["requester" , "monitor"]. - o The 'audience' parameter MUST be present and is set to the - identifier of the Group Manager. + o The 'audience' parameter MUST be present. 3.2. Authorization Response - The AS is responsible for authorizing the joining node to join - specific OSCORE groups, according to join policies enforced on behalf - of the respective Group Manager. - - In case of successful authorization, the AS releases an Access Token - bound to a proof-of-possession key associated to the joining node. - - Then, the AS provides the joining node with the Access Token as part - of an Access Token response, which follows the format of the - Authorization Response message defined in Section 3.2 of - [I-D.ietf-ace-key-groupcomm]. - - The AS MUST include the 'exp' parameter in the response to the - joining node. Other means for the AS to specify the lifetime of - Access Tokens are out of the scope of this specification. - - The AS must include the 'scope' parameter in the response to the - joining node, when the value included in the Access Token differs - from the one specified by the joining node in the request. In such a - case, the second element of 'scope' MUST be present and includes the - role or CBOR array of roles that the joining node is actually - authorized to take in the group, encoded as specified in Section 3.1 - of this document. + The Authorization Response message defined in Section 3.2 of + [I-D.ietf-ace-key-groupcomm], with the following additions: - The AS MAY also include the 'profile' parameter in the response to - the joining node, in order to indicate the specific transport profile - of ACE to use for securing communications between the joining node - and the Group Manager (see Section 5.6.4.3 of - [I-D.ietf-ace-oauth-authz]). + o The AS MUST include the 'exp' parameter. Other means for the AS + to specify the lifetime of Access Tokens are out of the scope of + this specification. - In particular, if symmetric keys are used, the AS generates a proof- - of-possession key, binds it to the Access Token, and provides it to - the joining node in the 'cnf' parameter of the Access Token response. - Instead, if asymmetric keys are used, the joining node provides its - own public key to the AS in the 'req_cnf' parameter of the Access - Token request. Then, the AS uses it as proof-of-possession key bound - to the Access Token, and provides the joining node with the Group - Manager's public key in the 'rs_cnf' parameter of the Access Token - response. + o The AS MUST include the 'scope' parameter, when the value included + in the Access Token differs from the one specified by the joining + node in the request. In such a case, the second element of + 'scope' MUST be present and includes the role or CBOR array of + roles that the joining node is actually authorized to take in the + OSCORE group, encoded as specified in Section 3.1 of this + document. -4. Joining Node to Group Manager +4. Joining a Group The following subsections describe the interactions between the joining node and the Group Manager, i.e. the sending of the Access Token and the Request-Response exchange to join the OSCORE group. + The message exchange between the joining node and the KDC consists of + the messages defined in Section 3.3 and 4.2 of + [I-D.ietf-ace-key-groupcomm]. Note that what is defined in + [I-D.ietf-ace-key-groupcomm] applies, and only additions or + modifications to that specification are defined here. 4.1. Token Post - The joining node posts the Access Token to the /authz-info endpoint - at the Group Manager, according to the Token post defined in - Section 3.3 of [I-D.ietf-ace-key-groupcomm]. - - At this point in time, the joining node might not have all the - necessary information concerning the public keys in the OSCORE group, - as well as concerning the algorithm and related parameters for - computing countersignatures in the OSCORE group. In such a case, the - joining node MAY use the 'sign_info' and 'pub_key_enc' parameters - defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm] to ask for - such information. - - Alternatively, the joining node may retrieve this information by - other means, e.g. by using the approach described in - [I-D.tiloca-core-oscore-discovery]. - - If the Access Token is valid, the Group Manager responds to the POST - request with a 2.01 (Created) response, according to what is - specified in the signalled transport profile of ACE. The Group - Manager MUST use the Content-Format "application/ace+cbor" defined in - Section 8.14 of [I-D.ietf-ace-oauth-authz]. - - The payload of the 2.01 (Created) response is a CBOR map, which MUST - include the 'rsnonce' parameter defined in Section 3.3.3 of + The Token post exchange is defined in Section 3.3 of + [I-D.ietf-ace-key-groupcomm]. - [I-D.ietf-ace-key-groupcomm], and MAY include the 'sign_info' - parameter as well as the 'pub_key_enc' parameter, defined in its - Sections 3.3.1 and 3.3.2, respectively. Note that this deviates from - the default payload format for this response message as defined in - the ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]). + Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the + following applies. - The 'rsnonce' parameter includes a dedicated nonce N_S generated by - the Group Manager. The joining node may use this nonce in order to - prove the possession of its own private key, upon joining the group - (see Section 4.2). + o The 'rsnonce' parameter contains a dedicated 8-byte nonce N_S + generated by the Group Manager. The joining node may use this + nonce in order to prove the possession of its own private key, + upon joining the group (see Section 4.2). - If present in the response: + o If 'sign_info' is present in the response: - o 'sign_alg', i.e. the first element of the 'sign_info' parameter, - takes value from Tables 5 and 6 of [RFC8152]. + * 'sign_alg' takes value from Tables 5 and 6 of [RFC8152]. - o 'sign_parameters', i.e. the second element of the 'sign_info' - parameter, takes values from the "Counter Signature Parameters" - Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]). - Its structure depends on the value of 'sign_alg'. If no - parameters of the counter signature algorithm are specified, - 'sign_parameters' MUST be encoding the CBOR simple value Null. + * 'sign_parameters' takes values from the "Counter Signature + Parameters" Registry (see Section 9.1 of + [I-D.ietf-core-oscore-groupcomm]). Its structure depends on + the value of 'sign_alg'. If no parameters of the counter + signature algorithm are specified, 'sign_parameters' MUST be + encoding the CBOR simple value Null. - o 'sign_key_parameters', i.e. the third element of the 'sign_info' - parameter, takes values from the "Counter Signature Key - Parameters" Registry (see Section 9.2 of - [I-D.ietf-core-oscore-groupcomm]). Its structure depends on the - value of 'sign_alg'. If no parameters of the key used with the - counter signature algorithm are specified, 'sign_key_parameters' - MUST be encoding the CBOR simple value Null. + * 'sign_key_parameters' takes values from the "Counter Signature + Key Parameters" Registry (see Section 9.2 of + [I-D.ietf-core-oscore-groupcomm]). Its structure depends on + the value of 'sign_alg'. If no parameters of the key used with + the counter signature algorithm are specified, + 'sign_key_parameters' MUST be encoding the CBOR simple value + Null. - o 'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation - Key' column of the "CWT Confirmation Method" Registry defined in - [I-D.ietf-ace-cwt-proof-of-possession], so indicating that public - keys in the OSCORE group are encoded as COSE Keys [RFC8152]. - Future specifications may define additional values for this - parameter. + * 'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation + Key' column of the "CWT Confirmation Method" Registry defined + in [I-D.ietf-ace-cwt-proof-of-possession], so indicating that + public keys in the OSCORE group are encoded as COSE Keys + [RFC8152]. Future specifications may define additional values + for this parameter. - The CBOR map specified as payload of the 2.01 (Created) response may - include further parameters, e.g. according to the signalled transport - profile of ACE. + Note that, other than through the above parameters as defined in + Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY + have previously retrieved this information by other means, e.g. by + using the approach described in + [I-D.tiloca-core-oscore-discovery]. - Finally, the joining node establishes a secure channel with the Group - Manager, according to what is specified in the Access Token response - and the signalled transport profile of ACE. + Additionally, if allowed by the used transport profile of ACE, the + joining node may instead provide the Access Token to the Group + Manager by other means, e.g. during a secure session establishment + (see Section 3.3.1 of [I-D.ietf-ace-dtls-authorize]). -4.2. Joining Request +4.2. Sending the Joining Request - Once a secure communication channel with the Group Manager has been - established, the joining node requests to join the OSCORE group, by - sending a Joining Request message to the related group-membership - resource at the Group Manager, as per Section 4.2 of + The joining node requests to join the OSCORE group, by sending a + Joining Request message to the related group-membership resource at + the Group Manager, as per Section 4.2 of [I-D.ietf-ace-key-groupcomm]. - In particular, the joining node sends a CoAP POST request to the - endpoint /group-oscore/NAME at the Group Manager, where NAME is the - name of the OSCORE group to join. This Joining Request is formatted - as defined in Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. - Specifically: + Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the + following applies. + + o The string "group-oscore" is used instead of "ace-group" (see + Section 4.1 of [I-D.ietf-ace-key-groupcomm]) as the top level path + to the group-membership resource. The url-path /group-oscore/ is + a default name of this specifications: implementations are not + required to use this name, and can define their own instead. o The 'scope' parameter MUST be present. o The 'get_pub_keys' parameter is present only if the joining node wants to retrieve the public keys of the group members from the Group Manager during the joining process (see Section 5). Otherwise, this parameter MUST NOT be present. - o The 'client_cred' parameter, if present, includes the public key - of the joining node. In case the joining node knows the encoding - of public keys in the OSCORE group, as well as the - countersignature algorithm and possible associated parameters used - in the OSCORE group, the included public key MUST be compatible - with those criteria. That is, the public key MUST be encoded - according to the encoding of public keys in the OSCORE group, and - MUST be compatible with the countersignature algorithm and - possible associated parameters used in the OSCORE group. This - parameter MAY be omitted if: i) the joining node is asking to - access the group exclusively as monitor; or ii) the Group Manager - already acquired this information, for instance during a past - joining process. In any other case, this parameter MUST be - present. + o 'cnonce' contains a dedicated 8-byte nonce N_C generated by the + joining node. - Furthermore, if the 'client_cred' parameter is present, the CBOR map - specified as payload of the Joining Request MUST also include the - following parameters. + o The signature encoded in the 'client_cred_verify' parameter is + computed by the joining node by using the same private key and + countersignature algorithm it intends to use for signing messages + in the OSCORE group. Moreover, N_S is as defined in + Section 4.2.1. - o 'cnonce', as defined in Section 5.1.2 of - [I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C - generated by the Client. +4.2.1. Value of the N_S Challenge - o The 'client_cred_verify' parameter, including a signature encoded - as a CBOR byte string, computed by the joining node to prove - possession of its own private key. The signature is computed over - N_S concatenated with N_C, where N_S is the nonce received in the - 'rsnonce' parameter of the 2.01 (Created) response to the Token - POST (see Section 4.1), while N_C is the nonce generated by the - Client and specified in the 'cnonce' parameter above. The joining - node computes the signature by using the same private key and - countersignature algorithm it intends to use for signing messages - in the OSCORE group. + The N_S challenge takes one of the following values. -4.3. Joining Response + 1. If the joining node has posted the Access Token to the /authz- + info endpoint of the Group Manager as in Section 4.1, N_S takes + the same value of the 'rsnonce' parameter in the 2.01 (Created) + response to the Token POST. - The Group Manager processes the Joining Request as defined in - Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Also, the Group - Manager MUST return a 4.00 (Bad Request) response in case the Joining - Request includes the 'client_cred' parameter but does not include - both the 'cnonce' and 'client_cred_verify' parameters. + 2. If the Token posting has relied on the DTLS profile of ACE + [I-D.ietf-ace-dtls-authorize] and the joining node included the + Access Token as content of the "psk_identity" field of the + ClientKeyExchange message [RFC6347], N_S is an exporter value + computed as defined in Section 7.5 of [RFC8446]. Specifically, + N_S is exported from the DTLS session between the joining node + and the Group Manager, using an empty 'context_value', 32 bytes + as 'key_length', and the exporter label "EXPORTER-ACE-Sign- + Challenge" defined in Section 7 of + [I-D.ietf-ace-mqtt-tls-profile]. - If the request processing yields a positive outcome, the Group - Manager performs the further following checks. + 3. If the joining node is in fact re-joining the group, without + posting again the same and still valid Access Token: - o In case the Joining Request includes the 'client_cred' parameter, - the Group Manager checks that the public key of the joining node - has an accepted format. That is, the public key has to be encoded - as expected in the OSCORE group, and has to be compatible with the - counter signature algorithm and possible associated parameters - used in the OSCORE group. The joining process fails if the public - key of the joining node does not have an accepted format. + * If the joining node and the Group Manager communicates using + DTLS, N_S is an exporter value, computed as described in point + (2) above. + + * If the joining node and the Group Manager communicates using + OSCORE [RFC8613], the N_S is the output PRK of a HKDF-Extract + step [RFC5869], i.e. PRK = HMAC-Hash(salt, IKM). In + particular, 'salt' takes (x1 | x2), where x1 is the ID Context + of the OSCORE Security Context between the joining node and + the Group Manager, x2 is the Sender ID of the joining node in + that Context, and | denotes byte string concatenation. Also, + 'IKM' is the OSCORE Master Secret of the OSCORE Security + Context between the joining node and the Group Manager. The + HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms + defined for COSE [RFC8152]. HKDF SHA-256 is mandatory to + implement. + + It is up to applications to define how N_S is computed in further + alternative settings. + +4.3. Processing the Joining Request + + The Group Manager processes the Joining Request as defined in + Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the + following applies. o In case the Joining Request does not include the 'client_cred' - parameter, the Group Manager checks whether it is storing a public - key for the joining node, which is compatible with the encoding, - counter signature algorithm and possible associated parameters - used in the OSCORE group. The joining process fails if the Group - Manager either: i) does not store a public key with an accepted - format for the joining node; or ii) stores multiple public keys - with an accepted format for the joining node. + parameter, the joining process fails if the Group Manager either: + i) does not store a public key with an accepted format for the + joining node; or ii) stores multiple public keys with an accepted + format for the joining node. - o In case the Joining Request includes the 'client_cred_verify' - parameter, the Group Manager verifies the signature contained in - the parameter. To this end, it considers: i) as signed value, N_S - concatenated with N_C, where N_S is the nonce previously provided - in the 'rsnonce' parameter of the 2.01 (Created) response to the - Token POST (see Section 4.1), while N_C is the nonce provided in - the 'cnonce' parameter of the Joining Request; ii) the - countersignature algorithm used in the OSCORE group, and possible - correponding parameters; and iii) the public key of the joining - node, either retrieved from the 'client_cred' parameter, or - already stored as acquired from previous interactions with the - joining node. The joining process fails if the Group Manager does - not successfully verify the signature. + o To compute the signature contained in 'client_cred_verify', the GM + considers: i) as signed value, N_S concatenated with N_C, where + N_S is determined as described in Section 4.2.1, while N_C is the + nonce provided in the 'cnonce' parameter of the Joining Request; + ii) the countersignature algorithm used in the OSCORE group, and + possible correponding parameters; and iii) the public key of the + joining node, either retrieved from the 'client_cred' parameter, + or already stored as acquired from previous interactions with the + joining node. - If the joining process has failed, the Group Manager MUST reply to - the joining node with a 4.00 (Bad Request) response. The payload of - this response is a CBOR map, which includes a 'sign_info' parameter - and a 'pub_key_enc' parameter, formatted as in the Token POST - response in Section 4.1. + o A 4.00 Bad Request response from the Group Manager to the joining + node MUST have content format application/ace-group+cbor. The + response payload is a CBOR map which MUST contain the 'sign_info' + as well as the 'pub_key_enc' parameters. - Upon receiving this response, the joining node SHOULD send a new - Joining Request to the Group Manager, which contains: + o The Group Manager MUST return a 4.00 (Bad Request) response in + case the Joining Request includes the 'client_cred' parameter but + does not include both the 'cnonce' and 'client_cred_verify' + parameters. - o The 'client_cred' parameter, including a public key compatible + o The Group Manager MUST return a 4.00 (Bad Request) response in + case it cannot retrieve a public key with an accepted format for + the joining node, either from the 'client_cred' parameter or as + already stored. + + o When receiving a 4.00 Bad Request response, the joining node + SHOULD send a new Joining Request to the Group Manager, + containing: + + * The 'client_cred' parameter, including a public key compatible with the encoding, countersignature algorithm and possible associated parameters indicated by the Group Manager. - o The 'client_cred_verify' parameter, including a signature computed - as described in Section 4.2, by using the public key indicated in - the current 'client_cred' parameter, with the countersignature - algorithm and possible associated parameters indicated by the - Group Manager. + * The 'client_cred_verify' parameter, including a signature + computed as described in Section 4.2, by using the public key + indicated in the current 'client_cred' parameter, with the + countersignature algorithm and possible associated parameters + indicated by the Group Manager. - Otherwise, in case of success, the Group Manager updates the group - membership by registering the joining node as a new member of the - OSCORE group. If the joining node is not exclusively configured as - monitor, the Group Manager performs also the following actions. +4.4. Joining Response - o The Group Manager selects an available OSCORE Sender ID in the - OSCORE group, and exclusively assigns it to the joining node. + If the processing of the Joining Request described in Section 4.3 is + successful, the Group Manager updates the group membership by + registering the joining node NODENAME as a new member of the OSCORE + group GROUPNAME, as described in Section 4.1.2.1 of + [I-D.ietf-ace-key-groupcomm]. - o If the 'client_cred' parameter was present in the request, the - Group Manager adds the specified public key of the joining node to - the list of public keys of the current group members. + If the joining node is not exclusively configured as monitor, the + Group Manager performs also the following actions. - o If the 'client_cred' parameter was not present in the request, the - Group Manager retrieves the already stored public key of the - joining node, as acquired from previous interactions (see also - Section 5). Then, the Group Manager adds the retrieved public key - to the list of public keys of the current group members. + o The Group Manager selects an available OSCORE Sender ID in the + OSCORE group, and exclusively assigns it to the joining node. o The Group Manager stores the association between i) the public key - of the joining node; and ii) the Group Identifier (Gid) associated - to the OSCORE group together with the OSCORE Sender ID assigned to - the joining node in the group. The Group Manager MUST keep this - association updated over time. + of the joining node; and ii) the Group Identifier (Gid), i.e. the + OSCORE ID Context, associated to the OSCORE group together with + the OSCORE Sender ID assigned to the joining node in the group. + The Group Manager MUST keep this association updated over time. - Then, the Group Manager replies to the joining node providing the + Then, the Group Manager replies to the joining node, providing the updated security parameters and keying meterial necessary to participate in the group communication. This success Joining Response is formatted as defined in Section 4.1.2.1 of - [I-D.ietf-ace-key-groupcomm]. In particular: + [I-D.ietf-ace-key-groupcomm], with the following additions: - o The 'kty' parameter identifies a key of type + o The 'gkty' parameter identifies a key of type "Group_OSCORE_Security_Context object", defined in Section 15.1 of this specification. o The 'key' parameter includes what the joining node needs in order to set up the OSCORE Security Context as per Section 2 of [I-D.ietf-core-oscore-groupcomm]. This parameter has as value a Group_OSCORE_Security_Context object, which is defined in this specification and extends the OSCORE_Security_Context object encoded in CBOR as defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. In particular, it contains the @@ -696,21 +543,22 @@ * The 'hkdf' parameter, if present, has as value the KDF algorithm used in the group. * The 'alg' parameter, if present, has as value the AEAD algorithm used in the group. * The 'salt' parameter, if present, has as value the OSCORE Master Salt. * The 'contextId' parameter MUST be present and has as value the - Group Identifier (Gid) associated to the OSCORE group. + Group Identifier (Gid), i.e. the OSCORE ID Context of the + OSCORE group. * The 'rpl' parameter, if present, specifies the OSCORE Replay Window Size and Type value. * The 'cs_alg' parameter MUST be present and specifies the algorithm used to countersign messages in the group. This parameter takes values from Tables 5 and 6 of [RFC8152]. * The 'cs_params' parameter MAY be present and specifies the additional parameters for the counter signature algorithm. @@ -729,62 +577,54 @@ encoding of the public keys of the group members. This parameter is a CBOR integer, whose value is 1 ("COSE_Key") taken from the 'Confirmation Key' column of the "CWT Confirmation Method" Registry defined in [I-D.ietf-ace-cwt-proof-of-possession], so indicating that public keys in the OSCORE group are encoded as COSE Keys [RFC8152]. Future specifications may define additional values for this parameter. If this parameter is not present, 1 ("COSE_Key") MUST be assumed as default value. - o The 'num' parameter MUST be present and specifies the current - version number of the group keying material. + o The 'num' parameter MUST be present. - o The 'profile' parameter MUST be present and has value - coap_group_oscore_app (TBD), which is defined in Section 15.3 of - this specification. + o The 'ace-groupcomm-profile' parameter MUST be present and has + value coap_group_oscore_app (TBD), which is defined in + Section 15.3 of this specification. - o The 'exp' parameter MUST be present and specifies the expiration - time in seconds after which the OSCORE Security Context derived - from the 'key' parameter is not valid anymore. + o The 'exp' parameter MUST be present. - o The 'pub_keys' parameter is present only if the 'get_pub_keys' - parameter was present in the Joining Request. If present, this - parameter includes the public keys of the group members that are - relevant to the joining node. That is, it includes: i) the public - keys of the responders currently in the group, in case the joining - node is configured (also) as requester; and ii) the public keys of - the requesters currently in the group, in case the joining node is - configured (also) as responder or monitor. If public keys are - encoded as COSE_Keys, each of them has as 'kid' the Sender ID that - the corresponding owner has in the group, thus used as group - member identifier. + o The 'pub_keys' parameter, if present, includes the public keys of + the group members that are relevant to the joining node. That is, + it includes: i) the public keys of the responders currently in the + group, in case the joining node is configured (also) as requester; + and ii) the public keys of the requesters currently in the group, + in case the joining node is configured (also) as responder or + monitor. If public keys are encoded as COSE_Keys, each of them + has as 'kid' the Sender ID that the corresponding owner has in the + group, thus used as group member identifier. - o The 'group_policies' parameter SHOULD be present and includes a - list of parameters indicating particular policies enforced in the - group. In particular, if the field "Sequence Number - Synchronization Method" is present, it indicates the method to - achieve synchronization of sequence numbers among group members - (see Appendix E of [I-D.ietf-core-oscore-groupcomm]), by - specifying the corresponding value from the "Sequence Number - Synchronization Method" Registry defined in Section 8.6 of + o The 'group_policies' parameter SHOULD be present, and SHOULD + include the elements "Sequence Number Synchronization Method" and + "Key Update Check Interval" defined in Section 4.1.2. of [I-D.ietf-ace-key-groupcomm]. Finally, the joining node uses the information received in the Joining Response to set up the OSCORE Security Context, as described in Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the joining node can exchange group messages secured with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. If the application requires backward security, the Group Manager MUST generate updated security parameters and group keying material, and - provide it to all the current group members (see Section 13). + provide it to the current group members upon the new node's joining + (see Section 13). As a consequence, the joining node is not able to + access secure communication in the group occurred prior its joining. 5. Public Keys of Joining Nodes Source authentication of OSCORE messages exchanged within the group is ensured by means of digital counter signatures (see Sections 2 and 3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members must be able to retrieve each other's public key from a trusted key repository, in order to verify source authenticity of incoming group messages. @@ -859,49 +699,75 @@ 6. Retrieval of Updated Keying Material At some point, a group member considers the OSCORE Security Context invalid and to be renewed. This happens, for instance, after a number of unsuccessful security processing of incoming messages from other group members, or when the Security Context expires as specified by the 'exp' parameter of the Joining Response. When this happens, the group member retrieves updated security - parameters and group keying material, by sending a Key Distribution - Request message to the Group Manager, as per Section 4.3 of - [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET - request to the endpoint /group-oscore/NAME at the Group Manager, - where NAME is the name of the OSCORE group. The Key Distribution - Request is formatted as defined in Section 4.1.2.2 of - [I-D.ietf-ace-key-groupcomm]. + parameters and group keying material. This can occur in the two + different ways described below. + +6.1. Retrieval of Group Keying Material + + If the group member wants to retrieve only the latest group keying + material, it sends a Key Distribution Request to the Group Manager. + + In particular, it sends a CoAP GET request to the endpoint /group- + oscore/GROUPNAME at the Group Manager. The Group Manager processes the Key Distribution Request according to Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution Response is formatted as defined in Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. Upon receiving the Key Distribution Response, the group member retrieves the updated security parameters and group keying material, - and use them to set up the new OSCORE Security Context as described - in Section 2 of [I-D.ietf-core-oscore-groupcomm]. + and, if they differ from the current ones, use them to set up the new + OSCORE Security Context as described in Section 2 of + [I-D.ietf-core-oscore-groupcomm]. + +6.2. Retrieval of Group Keying Material and Sender ID + + If the group member wants to retrieve the latest group keying + material as well as the Sender ID that it has in the OSCORE group, it + sends a Key Distribution Request to the Group Manager. + + In particular, it sends a CoAP GET request to the endpoint /group- + oscore/GROUPNAME/NODENAME at the Group Manager. + + The Group Manager processes the Key Distribution Request according to + Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. The Key + Distribution Response is formatted as defined in Section 4.1.6.2 of + [I-D.ietf-ace-key-groupcomm]. Note that the current Sender ID of the + group member is not specified as a separate parameter, but rather + included as 'clientId' in the 'key' parameter. + + Upon receiving the Key Distribution Response, the group member + retrieves the updated security parameters, group keying material and + Sender ID, and, if they differ from the current ones, use them to set + up the new OSCORE Security Context as described in Section 2 of + [I-D.ietf-core-oscore-groupcomm]. 7. Retrieval of New Keying Material As discussed in Section 2.2 of [I-D.ietf-core-oscore-groupcomm], a group member may at some point experience a wrap-around of its own Sender Sequence Number in the group. When this happens, the group member MUST send a Key Renewal Request message to the Group Manager, as per Section 4.4 of - [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET - request to the endpoint /group-oscore/NAME/node at the Group Manager, - where NAME is the name of the OSCORE group. + [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT + request to the endpoint /group-oscore/GROUPNAME/NODENAME at the Group + Manager. Upon receiving the Key Renewal Request, the Group Manager processes it as defined in Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm], and performs one of the following actions. 1. The Group Manager replies to the group member with a 4.06 (Not Acceptable) error response, and rekeys the whole OSCORE group as discussed in Section 13. 2. The Group Manager generates a new Sender ID for that group member @@ -911,129 +777,128 @@ 'clientId' defined in Section 15.5 of this document, specifying the new Sender ID of the group member encoded as a CBOR byte string. 8. Retrieval of Public Keys of Group Members A group member may need to retrieve the public keys of other group members. To this end, the group member sends a Public Key Request message to the Group Manager, as per Section 4.5 of [I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to - the endpoint /group-oscore/NAME/pub-key at the Group Manager, where - NAME is the name of the OSCORE group. + the endpoint /group-oscore/GROUPNAME/pub-key at the Group Manager. - If the Public Key Request uses the method POST, the Public Key + If the Public Key Request uses the method FETCH, the Public Key Request is formatted as defined in Section 4.1.3.1 of [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 'get_pub_keys' parameter is a CBOR byte string, which encodes the Sender ID of the group member for which the associated public key is requested. Upon receiving the Public Key Request, the Group Manager processes it as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], - depending on the request method being POST or GET, respectively. If - the Public Key Request uses the method POST, the Group Manager - silently ignores identifiers included in the 'get_pub_keys' parameter - of the request that are not associated to any current group member. + depending on the request method being FETCH or GET, respectively. + Additionally, if the Public Key Request uses the method FETCH, the + Group Manager silently ignores identifiers included in the + 'get_pub_keys' parameter of the request that are not associated to + any current group member. The success Public Key Response is formatted as defined in - Section 4.1.3.1 of [I-D.ietf-ace-key-groupcomm]. + Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], depending + on the request method being FETCH or GET, respectively. 9. Retrieval of Group Policies A group member may request the current policies used in the OSCORE group. To this end, the group member sends a Policies Request, as per Section 4.6 of [I-D.ietf-ace-key-groupcomm]. In particular, it - sends a CoAP GET request to the endpoint /group-oscore/NAME/policies - at the Group Manager, where NAME is the name of the OSCORE group. + sends a CoAP GET request to the endpoint /group-oscore/GROUPNAME/ + policies at the Group Manager, where GROUPNAME is the name of the + OSCORE group. Upon receiving the Policies Request, the Group Manager processes it as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success Policies Response is formatted as defined in Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. 10. Retrieval of Keying Material Version A group member may request the current version of the keying material used in the OSCORE group. To this end, the group member sends a Version Request, as per Section 4.7 of [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET request to the endpoint /group- - oscore/NAME/ctx-num at the Group Manager, where NAME is the name of - the OSCORE group. + oscore/GROUPNAME/ctx-num at the Group Manager, where GROUPNAME is the + name of the OSCORE group. Upon receiving the Version Request, the Group Manager processes it as per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success Version Response is formatted as defined in Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. 11. Request to Leave the Group A group member may request to leave the OSCORE group. To this end, the group member sends a Group Leaving Request, as per Section 4.8 of - [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP POST - request to the endpoint /group-oscore/NAME/node at the Group Manager, - where NAME is the name of the OSCORE group to leave. - - The Leaving Request is formatted as defined in Section 4.1.6.1 of - [I-D.ietf-ace-key-groupcomm], and MUST have an empty CBOR Map as - payload. + [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP DELETE + request to the endpoint /group-oscore/GROUPNAME/NODENAME at the Group + Manager. - Upon receiving the Leaving Request, the Group Manager processes it as - per Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm]. + Upon receiving the Group Leaving Request, the Group Manager processes + it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm]. 12. Removal of a Group Member Other than after a spontaneous request to the Group Manager as described in Section 11, a node may be forcibly removed from the OSCORE group, e.g. due to expired or revoked authorization. In either case, if the leaving node is not configured exclusively as monitor, the Group Manager performs the following actions. o The Group Manager frees the OSCORE Sender ID value of the leaving node, which becomes available for possible upcoming joining nodes. o The Group Manager cancels the association between, on one hand, the public key of the leaving node and, on the other hand, the Group Identifier (Gid) associated to the OSCORE group together with the freed OSCORE Sender ID value. The Group Manager deletes the public key of the leaving node, if that public key has no - remaining association with any pair (Group ID, Sender ID). + remaining association with any pair (Gid, Sender ID). If the application requires forward security, the Group Manager MUST generate updated security parameters and group keying material, and provide it to the remaining group members (see Section 13). As a consequence, the leaving node is not able to acquire the new security parameters and group keying material distributed after its leaving. Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] apply here as well, considering the Group Manager acting as KDC. 13. Group Rekeying Process In order to rekey the OSCORE group, the Group Manager distributes a - new Group ID of the group and a new OSCORE Master Secret for that - group. When doing so, the Group Manager MUST increment the version - number of the group keying material. Also, the Group Manager MUST - preserve the same unchanged Sender IDs for all group members. This - avoids affecting the retrieval of public keys from the Group Manager - as well as the verification of message countersignatures. + new Group Identifier (Gid), i.e. a new OSCORE ID Context, and a new + OSCORE Master Secret for that group. When doing so, the Group + Manager MUST increment the version number of the group keying + material. Also, the Group Manager MUST preserve the same unchanged + Sender IDs for all group members. This avoids affecting the + retrieval of public keys from the Group Manager as well as the + verification of message countersignatures. The Group Manager MUST support at least the following group rekeying scheme. Future application profiles may define alternative message formats and distribution schemes. The Group Manager uses the same format of the Joining Response - message in Section 4.3. In particular: + message in Section 4.4. In particular: - o Only the parameters 'kty', 'key', 'num', 'profile' and 'exp' are - present. + o Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile' + and 'exp' are present. o The 'ms' parameter of the 'key' parameter specifies the new OSCORE Master Secret value. o The 'contextId' parameter of the 'key' parameter specifies the new Group ID. The Group Manager separately sends a group rekeying message to each group member to be rekeyed. Each rekeying message MUST be secured with the pairwise secure communication channel between the Group @@ -1044,26 +909,26 @@ the Group Manager. In particular, if a group member and the Group Manager use OSCORE [RFC8613] to secure their pairwise communications, the group member MUST create a Replay Window in its own Recipient Context upon establishing the OSCORE Security Context with the Group Manager, e.g. by means of the OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. Group members and the Group Manager SHOULD additionally support alternative rekeying approaches that do not require group members to act (also) as servers. A number of such approaches are defined in - Section 4 of [I-D.ietf-ace-key-groupcomm]. In particular, a group + Section 4.3 of [I-D.ietf-ace-key-groupcomm]. In particular, a group member may subscribe for updates to the group-membership resource of - the group, at the endpoint /group-oscore/NAME of the Group Manager, - where NAME is the name of the OSCORE group. This can rely on CoAP - Observe [RFC7641] or on a full-fledged Pub-Sub model - [I-D.ietf-core-coap-pubsub] with the Group Manager acting as Broker. + the group, at the endpoint /group-oscore/GROUPNAME/NODENAME of the + Group Manager. This can rely on CoAP Observe [RFC7641] or on a full- + fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group + Manager acting as Broker. 14. Security Considerations The method described in this document leverages the following management aspects related to OSCORE groups and discussed in the sections of [I-D.ietf-core-oscore-groupcomm] referred below. o Management of group keying material (see Section 2.1 of [I-D.ietf-core-oscore-groupcomm]). The Group Manager is responsible for the renewal and re-distribution of the keying @@ -1072,21 +937,21 @@ the group upon changes in its membership. In particular, renewing the group keying material is required upon a new node's joining or a current node's leaving, in case backward security and forward security have to be preserved, respectively. o Provisioning and retrieval of public keys (see Section 2 of [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key repository of public keys of group members, and provides them upon request. - o Synchronization of sequence numbers (see Section 5 of + o Synchronization of sequence numbers (see Section 5.1 of [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder node that has just joined an OSCORE group can synchronize with the sequence number of requesters in the same group. Before sending the Joining Response, the Group Manager MUST verify that the joining node actually owns the associated private key. To this end, the Group Manager can rely on the proof-of-possession challenge-response defined in Section 4. Alternatively, the joining node can use its own public key as asymmetric proof-of-possession key to establish a secure channel with the Group Manager, e.g. as in @@ -1115,31 +980,31 @@ Note to RFC Editor: Please replace all occurrences of "[[This specification]]" with the RFC number of this specification and delete this paragraph. This document has the following actions for IANA. 15.1. ACE Groupcomm Key Registry IANA is asked to register the following entry in the "ACE Groupcomm - Key" Registry defined in Section 8.3 of [I-D.ietf-ace-key-groupcomm]. + Key" Registry defined in Section 8.4 of [I-D.ietf-ace-key-groupcomm]. o Name: Group_OSCORE_Security_Context object o Key Type Value: TBD o Profile: "coap_group_oscore_app", defined in Section 15.3 of this specification. o Description: A Group_OSCORE_Security_Context object encoded as - described in Section 4.3 of this specification. + described in Section 4.4 of this specification. o Reference: [[This specification]] 15.2. OSCORE Security Context Parameters Registry IANA is asked to register the following entries in the "OSCORE Security Context Parameters" Registry defined in Section 9.2 of [I-D.ietf-ace-oscore-profile]. o Name: cs_alg @@ -1187,37 +1052,37 @@ o Registry: ACE Public Key Encoding o Description: Encoding of Public Keys to be used with the OSCORE Counter Signature Algorithm o Reference: [[This specification]] 15.3. ACE Groupcomm Profile Registry IANA is asked to register the following entry in the "ACE Groupcomm - Profile" Registry defined in Section 8.4 of + Profile" Registry defined in Section 8.5 of [I-D.ietf-ace-key-groupcomm]. o Name: coap_group_oscore_app o Description: Application profile to provision keying material for participating in group communication protected with Group OSCORE as per [I-D.ietf-core-oscore-groupcomm]. o CBOR Value: TBD o Reference: [[This specification]] 15.4. Sequence Number Synchronization Method Registry IANA is asked to register the following entries in the "Sequence - Number Synchronization Method" Registry defined in Section 8.6 of + Number Synchronization Method" Registry defined in Section 8.7 of [I-D.ietf-ace-key-groupcomm]. o Name: Best effort o Value: 1 o Description: No action is taken. o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1). @@ -1236,21 +1100,21 @@ o Value: 3 o Description: Challenge response using the Echo Option for CoAP from [I-D.ietf-core-echo-request-tag]. o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3). 15.5. ACE Groupcomm Parameters Registry IANA is asked to register the following entry in the "ACE Groupcomm - Parameters" Registry defined in Section 8.2 of + Parameters" Registry defined in Section 8.3 of [I-D.ietf-ace-key-groupcomm]. o Name: clientId o CBOR Key: TBD o CBOR Type: Byte string o Reference: [[This document]] (Section 7). @@ -1259,209 +1123,247 @@ 16.1. Normative References [I-D.ietf-ace-cwt-proof-of-possession] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- possession-11 (work in progress), October 2019. [I-D.ietf-ace-key-groupcomm] Palombini, F. and M. Tiloca, "Key Provisioning for Group - Communication using ACE", draft-ietf-ace-key-groupcomm-03 - (work in progress), November 2019. + Communication using ACE", draft-ietf-ace-key-groupcomm-04 + (work in progress), January 2020. [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 - Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25 - (work in progress), October 2019. + Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-30 + (work in progress), January 2020. [I-D.ietf-ace-oscore-profile] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", draft-ietf-ace- oscore-profile-08 (work in progress), July 2019. [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", - draft-ietf-core-oscore-groupcomm-05 (work in progress), - July 2019. + draft-ietf-core-oscore-groupcomm-06 (work in progress), + November 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, DOI 10.17487/RFC3986, January 2005, - . + [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand + Key Derivation Function (HKDF)", RFC 5869, + DOI 10.17487/RFC5869, May 2010, + . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . 16.2. Informative References [I-D.dijk-core-groupcomm-bis] Dijk, E., Wang, C., and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", draft- - dijk-core-groupcomm-bis-01 (work in progress), July 2019. + dijk-core-groupcomm-bis-02 (work in progress), November + 2019. [I-D.ietf-ace-dtls-authorize] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", draft-ietf-ace-dtls- - authorize-08 (work in progress), April 2019. + authorize-09 (work in progress), December 2019. + + [I-D.ietf-ace-mqtt-tls-profile] + Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile + of ACE", draft-ietf-ace-mqtt-tls-profile-03 (work in + progress), December 2019. [I-D.ietf-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol (CoAP)", draft-ietf-core-coap-pubsub-09 (work in progress), September 2019. [I-D.ietf-core-echo-request-tag] Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Request-Tag, and Token Processing", draft-ietf-core-echo- request-tag-08 (work in progress), November 2019. [I-D.tiloca-core-oscore-discovery] Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE Groups with the CoRE Resource Directory", draft-tiloca- - core-oscore-discovery-03 (work in progress), July 2019. + core-oscore-discovery-04 (work in progress), November + 2019. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . - [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for - the Constrained Application Protocol (CoAP)", RFC 7390, - DOI 10.17487/RFC7390, October 2014, - . - [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . Appendix A. Profile Requirements This appendix lists the specifications on this application profile of ACE, based on the requiremens defined in Appendix A of [I-D.ietf-ace-key-groupcomm]. o REQ1 - Specify the encoding and value of the identifier of group of 'scope': see Section 3.1. o REQ2 - Specify the encoding and value of the identifier of roles of 'scope': see Section 3.1. - o REQ3 (Optional) - Specify the acceptable values for 'sign_alg': + o REQ3 - if used, specify the acceptable values for 'sign_alg': values from Tables 5 and 6 of [RFC8152]. - o REQ4 (Optional) - Specify the acceptable values for + o REQ4 - If used, specify the acceptable values for 'sign_parameters': values from the "Counter Signature Parameters" Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]). - o REQ5 (Optional) - Specify the acceptable values for + o REQ5 - If used, specify the acceptable values for 'sign_key_parameters': values from the "Counter Signature Key Parameters" Registry (see Section 9.2 of [I-D.ietf-core-oscore-groupcomm]). - o REQ6 (Optional) - Specify the acceptable values for 'pub_key_enc': - 1 ("COSE_Key") from the 'Confirmation Key' column of the "CWT + o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1 + ("COSE_Key") from the 'Confirmation Key' column of the "CWT Confirmation Method" Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. Future specifications may define additional values for this parameter. - o REQ7 - Format of the 'key' value: see Section 4.3. + o REQ7 - Format of the 'key' value: see Section 4.4. - o REQ8 - Acceptable values of 'kty': Group_OSCORE_Security_Context - object (see Section 4.3). + o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Security_Context + object (see Section 4.4). o REQ9: Specify the format of the identifiers of group members: see - Section 4.3 and Section 8. - - o REQ10 (Optional) - Specify the format and content of - 'group_policies' entries: three values are defined and registered, - as content of the entry "Sequence Number Synchronization Method" - (see Section 15.4). - - o REQ11 - Communication protocol that the members of the group must - use: CoAP, possibly over IP multicast. + Section 4.4 and Section 8. - o REQ12 - Security protocols that the group members must use to - protect their communication: Group OSCORE. + o REQ10 - Specify the communication protocol that the members of the + group must use: CoAP, possibly over IP multicast. - o REQ13 - Profile identifier: coap_group_oscore_app + o REQ11 - Specify the security protocols that the group members must + use to protect their communication: Group OSCORE. - o REQ14 (Optional) - Specify the encoding of public keys, of - 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. + o REQ12 - Specify and register the application profile identifier: + coap_group_oscore_app (see Section 15.3). - o REQ15 - Specify policies at the KDC to handle member ids that are + o REQ13 - Specify policies at the KDC to handle member ids that are not included in 'get_pub_keys': see Section 8. - o REQ16 - Specify the format and content of 'group_policies': see - Section 4.3. + o REQ14 - If used, specify the format and content of + 'group_policies' and its entries: see Section 4.4, and the three + values defined and registered, as content of the entry "Sequence + Number Synchronization Method" (see Section 15.4). - o REQ17 - Specify the format of newly-generated individual keying + o REQ15 - Specify the format of newly-generated individual keying material for group members, or of the information to derive it, and corresponding CBOR label: see Section 7. - o REQ18 - Specify how the communication is secured between the + o REQ16 - Specify how the communication is secured between the Client and KDC: by means of any transport profile of ACE [I-D.ietf-ace-oauth-authz] between Client and Group Manager that complies with the requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. + o REQ17: Specify how the nonce N_S is generated, if the token is not + being posted (e.g. if it is used directly to validate TLS + instead): see Section 4.2.1. + + o REQ18: Specify if 'mgt_key_material' used, and if yes specify its + format and content: not used in this version of the profile. + o OPT1 (Optional) - Specify the encoding of public keys, of 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. o OPT2 (Optional) - Specify the negotiation of parameter values for signature algorithm and signature keys, if 'sign_info' and 'pub_key_enc' are not used: possible early discovery by using the approach based on the CoRE Resource Directory described in [I-D.tiloca-core-oscore-discovery]. - o OPT3 (Optional) - Specify the format and content of - 'mgt_key_material': no. + o OPT3 (Optional) - Specify the encoding of 'pub_keys_repos' if the + default is not used: no. o OPT4 (Optional) - Specify policies that instruct clients to retain unsuccessfully decrypted messages and for how long, so that they can be decrypted after getting updated keying material: no. + o OPT5 (Optional) - Specify the behavior of the handler in case of + failure to retrieve a public key for the specific node: send a + 4.00 Bad Request response to a Joining Request (see Section 4.3). + + o OPT6 (Optional) - Specify possible or required payload formats for + specific error cases: send a 4.00 Bad Request response to a + Joining Request (see Section 4.3). + Appendix B. Document Updates RFC EDITOR: PLEASE REMOVE THIS SECTION. -B.1. Version -02 to -03 +B.1. Version -03 to -04 + + o New abstract. + + o Moved general content to draft-ietf-ace-key-groupcomm + + o Terminology: node name; node resource. + + o Creation and pointing at node resource. + + o Updated Group Manager API (REST methods and offered services). + + o Size of challenges 'cnonce' and 'rsnonce'. + + o Value of 'rsnonce' for reused or non-traditionally-posted tokens. + + o Removed reference to RFC 7390. + + o New requirements from draft-ietf-ace-key-groupcomm + + o Editorial improvements. + +B.2. Version -02 to -03 o New sections, aligned with the interface of ace-key-groupcomm . o Exchange of information on the countersignature algorithm and related parameters, during the Token POST (Section 4.1). o Nonce 'rsnonce' from the Group Manager to the Client (Section 4.1). o Client PoP signature in the Key Distribution Request upon joining @@ -1470,21 +1372,21 @@ o Local actions on the Group Manager, upon a new node's joining (Section 4.2). o Local actions on the Group Manager, upon a node's leaving (Section 12). o IANA registration in ACE Groupcomm Parameters Registry. o More fulfilled profile requirements (Appendix A). -B.2. Version -01 to -02 +B.3. Version -01 to -02 o Editorial fixes. o Changed: "listener" to "responder"; "pure listener" to "monitor". o Changed profile name to "coap_group_oscore_app", to reflect it is an application profile. o Added the 'type' parameter for all requests to a Join Resource. @@ -1508,21 +1410,21 @@ o Extended security considerations: proof-of-possession of signature keys; collision of OSCORE Group Identifiers (Section 8). o Registered three entries in the IANA Registry "Sequence Number Synchronization Method Registry" (Section 9). o Registered one public key encoding in the "ACE Public Key Encoding" IANA Registry (Section 9). -B.3. Version -00 to -01 +B.4. Version -00 to -01 o Changed name of 'req_aud' to 'audience' in the Authorization Request (Section 3.1). o Added negotiation of countersignature algorithm/parameters between Client and Group Manager (Section 4). o Updated format of the Key Distribution Response as a whole (Section 4.3).