--- 1/draft-ietf-ace-key-groupcomm-06.txt 2020-06-18 02:13:36.612498907 -0700 +++ 2/draft-ietf-ace-key-groupcomm-07.txt 2020-06-18 02:13:36.724501756 -0700 @@ -1,19 +1,19 @@ ACE Working Group F. Palombini Internet-Draft Ericsson AB Intended status: Standards Track M. Tiloca -Expires: 12 November 2020 RISE AB - 11 May 2020 +Expires: December 20, 2020 RISE AB + June 18, 2020 Key Provisioning for Group Communication using ACE - draft-ietf-ace-key-groupcomm-06 + draft-ietf-ace-key-groupcomm-07 Abstract This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,94 +22,95 @@ 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 12 November 2020. + This Internet-Draft will expire on December 20, 2020. Copyright Notice 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. + 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 . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 7 + 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 - 4. Keying Material Provisioning and Group Membership - Management . . . . . . . . . . . . . . . . . . . . . . . 14 + 4. Keying Material Provisioning and Group Membership Management 14 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 15 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 30 - 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 32 - 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 34 + 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 31 + 4.4. Retrieval of New Keying Material . . . . . . . . . . . . 33 4.5. Retrieval of Public Keys and Roles for Group Members . . 34 - 4.6. Update of Public Key . . . . . . . . . . . . . . . . . . 35 - 4.7. Retrieval of Group Policies . . . . . . . . . . . . . . . 36 - 4.8. Retrieval of Keying Material Version . . . . . . . . . . 37 - 4.9. Group Leaving Request . . . . . . . . . . . . . . . . . . 37 - 5. Removal of a Node from the Group . . . . . . . . . . . . . . 37 - 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 38 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 + 4.6. Update of Public Key . . . . . . . . . . . . . . . . . . 34 + 4.7. Retrieval of Group Policies . . . . . . . . . . . . . . . 35 + 4.8. Retrieval of Keying Material Version . . . . . . . . . . 36 + 4.9. Group Leaving Request . . . . . . . . . . . . . . . . . . 36 + 5. Removal of a Node from the Group . . . . . . . . . . . . . . 36 + 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 37 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 40 - 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 41 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 - 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 42 - 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 43 - 8.3. ACE Authorization Server Request Creation Hints - Registry . . . . . . . . . . . . . . . . . . . . . . . . 43 - 8.4. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 44 - 8.5. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 44 - 8.6. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 45 - 8.7. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 46 - 8.8. Sequence Number Synchronization Method Registry . . . . . 46 - 8.9. Interface Description (if=) Link Target Attribute Values - Registry . . . . . . . . . . . . . . . . . . . . . . . . 47 - 8.10. Expert Review Instructions . . . . . . . . . . . . . . . 47 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 48 + 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 40 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 + 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 41 + 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 42 + 8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 42 + 8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 42 + 8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 43 + 8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 43 + 8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 44 + 8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 45 + 8.9. Sequence Number Synchronization Method Registry . . . . . 46 + 8.10. Interface Description (if=) Link Target Attribute Values + Registry . . . . . . . . . . . . . . . . . . . . . . . . 46 + 8.11. Expert Review Instructions . . . . . . . . . . . . . . . 46 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 47 9.2. Informative References . . . . . . . . . . . . . . . . . 49 + 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Appendix A. Requirements on Application Profiles . . . . . . . . 51 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 53 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 53 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 54 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 54 - B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 55 - B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 56 + B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 54 + B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 55 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 1. Introduction This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to define the message exchanges used to request, distribute and renew the keying material in a group communication scenario, e.g. based on - multicast [I-D.dijk-core-groupcomm-bis] or on publishing-subscribing + multicast [I-D.ietf-core-groupcomm-bis] or on publishing-subscribing [I-D.ietf-core-coap-pubsub]. The ACE framework is based on CBOR [RFC7049], so CBOR is the format used in this specification. However, using JSON [RFC8259] instead of CBOR is possible, using the conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. Profiles that use group communication can build on this document, by defining a number of details such as the exact group communication protocol and security protocols used. The specific list of details a profile needs to define is shown in Appendix A. @@ -124,35 +125,36 @@ 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 [I-D.ietf-ace-oauth-authz] and [RFC8152], such as - Authorization Server (AS) and Resource Server (RS). + described in [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru + ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS) + and Resource Server (RS). This document additionally uses the following terminology: - * Transport profile, to indicate a profile of ACE as per + o Transport profile, to indicate a profile of ACE as per Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport profile specifies the communication protocol and communication security protocol between an ACE Client and Resource Server, as well as proof-of-possession methods, if it supports proof-of- possession access tokens, etc. Tranport profiles of ACE include, for instance, [I-D.ietf-ace-oscore-profile], [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. - * Application profile, that defines how applications enforce and use + o Application profile, that defines how applications enforce and use supporting security services they require. These services may include, for instance, provisioning, revocation and (re-)distribution of keying material. An application profile may define specific procedures and message formats. 2. Overview +------------+ +-----------+ | AS | | KDC | | | .-------->| | @@ -164,59 +166,59 @@ | Client |<-' | Dispatcher | ||+-----------+ | |<-------->| (RS) |<------->|| Group | +------------+ +------------+ +| members | +-----------+ Figure 1: Key Distribution Participants The following participants (see Figure 1) take part in the authorization and key distribution. - * Client (C): node that wants to join the group communication. It + o Client (C): node that wants to join the group communication. It can request write and/or read rights. - * Authorization Server (AS): same as AS in the ACE Framework; it + o Authorization Server (AS): same as AS in the ACE Framework; it enforces access policies, and knows if a node is allowed to join a given group with write and/or read rights. - * Key Distribution Center (KDC): maintains the keying material to + o Key Distribution Center (KDC): maintains the keying material to protect group communications, and provides it to Clients authorized to join a given group. During the first part of the exchange (Section 3), it takes the role of the RS in the ACE Framework. During the second part (Section 4), which is not based on the ACE Framework, it distributes the keying material. In addition, it provides the latest keying material to group members when requested or, if required by the application, when membership changes. - * Dispatcher: entity through which the Clients communicate with the + o Dispatcher: entity through which the Clients communicate with the group and which distributes messages to the group members. Examples of dispatchers are: the Broker node in a pub-sub setting; a relayer node for group communication that delivers group messages as multiple unicast messages to all group members; an implicit entity as in a multicast communication setting, where messages are transmitted to a multicast IP address and delivered on the transport channel. This document specifies a mechanism for: - * Authorizing a new node to join the group (Section 3), and + o Authorizing a new node to join the group (Section 3), and providing it with the group keying material to communicate with the other group members (Section 4). - * A node to leave the group of for the KDC to remove a current - member of the group (Section 5). + o Leaving or removing a current group member from the group + (Section 5). - * Retrieving keying material as a current group member (Section 4.3 - and Section 4.4). + o Retrieval of keying material by a group member (Section 4.3 and + Section 4.4). - * Renewing and re-distributing the group keying material (rekeying) + o Renewing and re-distributing the group keying material (rekeying) upon a membership change in the group (Section 4.9 and Section 5). Figure 2 provides a high level overview of the message flow for a node joining a group communication setting, which can be expanded as follows. 1. The joining node requests an Access Token from the AS, in order to access a specific group-membership resource on the KDC and hence join the associated group. The joining node will start or continue using a secure communication association with the KDC, @@ -263,35 +265,32 @@ | | | |<===== Secure group communication =======|===========>| | | | Figure 2: Message Flow Upon New Node's Joining The exchange of Authorization Request and Authorization Response between Client and AS MUST be secured, as specified by the transport profile of ACE used between Client and KDC. - The exchange of Joining Request and Joining Response between Client - and KDC MUST be secured, as a result of the transport profile of ACE - used between Client and KDC. - - All further communications between the Client and the KDC MUST be - secured, for instance with the same security mechanism used for the - Key Distribution exchange. + The Joining Request and Joining Response, and all further + communications between the Client and the KDC MUST be sent over the + secure channel established as a result of the transport profile of + ACE used between Client and KDC. All communications between a Client and the other group members MUST be secured using the keying material provided in Section 4. 3. Authorization to Join a Group This section describes in detail the format of messages exchanged by - the participants when a node requests access to a group. This + the participants when a node requests access to a given group. This exchange is based on ACE [I-D.ietf-ace-oauth-authz]. As defined in [I-D.ietf-ace-oauth-authz], the Client requests from the AS an authorization to join the group through the KDC (see Section 3.1). If the request is approved and authorization is granted, the AS provides the Client with a proof-of-possession access token and parameters to securely communicate with the KDC (see Section 3.2). Communications between the Client and the AS MUST be secured, as @@ -311,126 +310,129 @@ | | | |<--- Authorization Response: 2.01 (Created) ---| | | | | |----- POST Token: POST /authz-info --------------->| | | Figure 3: Message Flow of Join Authorization 3.1. Authorization Request - The Authorization Request sent from the Client to the AS is as - defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY - contain the following parameters, which, if included, MUST have the - corresponding values: + The Authorization Request sent from the Client to the AS is defined + in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the + following parameters, which, if included, MUST have the corresponding + values: - * 'scope', containing the identifier of the specific group(s), or + o 'scope', containing the identifier of the specific group(s), or topic(s) in the case of pub-sub, that the Client wishes to access, and optionally the role(s) that the Client wishes to take. This value is a CBOR byte string, encoding a CBOR array of one or more entries. An entry has as value a CBOR array, which contains: - - As first element, the identifier of the specific group or + * As first element, the identifier of the specific group or topic. - - Optionally, as second element, the role (or CBOR array of + * Optionally, as second element, the role (or CBOR array of roles) that the Client wishes to take in the group. This element is optional since roles may have been pre-assigned to the Client, as associated to its verifiable identity credentials. Alternatively, the application may have defined a single, well-known role for the target resource(s) and - audience(s). + audience(s). Note that, if applicable in the application use + cases, the application profile can define a format for the role + as the one defined in [I-D.bormann-core-ace-aif]. - In each entry, the encoding of the group or topic identifier - (REQ1) and of the role identifiers (REQ2) is application specific, - and part of the requirements for the application profile. + In each entry, the encoding of the group or topic identifier (REQ1 + in Appendix A) and of the role identifiers (REQ2) is application + specific, and part of the requirements for the application + profile. In particular, the application profile may specify CBOR values to use for abbreviating role identifiers (OPT7). - The CDDL definition of scope, using as example group identifier - encoded as byte string and role identifier as text string, is - given in Figure 4. + The CDDL definition [RFC8610] of scope, using as example group + identifier encoded as byte string and role identifier as text + string, is given in Figure 4. - * 'audience', with an identifier of a KDC. + o 'audience', with an identifier of a KDC. - * 'req_cnf', as defined in Section 3.1 of + o 'req_cnf', as defined in Section 3.1 of [I-D.ietf-ace-oauth-params], optionally containing the public key or a reference to the public key of the Client, if it wishes to communicate that to the AS. - * Other additional parameters as defined in + o Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], if necessary. As in [I-D.ietf-ace-oauth-authz], these parameters are included in the payload, which is formatted as a CBOR map. The Content-Format "application/ace+cbor" defined in Section 8.14 of [I-D.ietf-ace-oauth-authz] is used. gid = bstr role = tstr scope_entry = [ gid , ? ( role / [ 2*role ] ) ] scope = << [ + scope_entry ] >> - Figure 4: CDLL definition of scope, using as example group - identifier encoded as bstr and role as tstr + Figure 4: CDLL definition of scope, using as example group identifier + encoded as bstr and role as tstr 3.2. Authorization Response - The Authorization Response sent from the AS to the Client is as - defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST - contain the following parameters: + The Authorization Response sent from the AS to the Client is defined + in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST contain the + following parameters: - * 'access_token', containing the proof-of-possession access token. + o 'access_token', containing the proof-of-possession access token. - * 'cnf' if symmetric keys are used, not present if asymmetric keys + o 'cnf' if symmetric keys are used, not present if asymmetric keys are used. This parameter is defined in Section 3.2 of [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- possession key that the Client is supposed to use with the KDC. - * 'rs_cnf' if asymmetric keys are used, not present if symmetric - keys are used. This parameter is as defined in Section 3.2 of + o 'rs_cnf' if asymmetric keys are used, not present if symmetric + keys are used. This parameter is defined in Section 3.2 of [I-D.ietf-ace-oauth-params] and contains information about the public key of the KDC. - * 'expires_in', contains the lifetime in seconds of the access + o 'expires_in', contains the lifetime in seconds of the access token. This parameter MAY be omitted if the application defines how the expiration time is communicated to the Client via other means, or if it establishes a default value. Additionally, the Authorization Response MAY contain the following parameters, which, if included, MUST have the corresponding values: - * 'scope' containing the granted scope, if different from the scope + o 'scope' containing the granted scope, if different from the scope requested by the client. This parameter has the same format and encoding of 'scope' in the Authorization Request, defined in Section 3.1. - * Other additional parameters as defined in + o Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], if necessary. The proof-of-possession access token (in 'access_token' above) MUST contain the following parameters: - * a confirmation claim (see for example 'cnf' defined in Section 3.1 + o a confirmation claim (see for example 'cnf' defined in Section 3.1 of [RFC8747] for CWT); - * an expiration time claim (see for example 'exp' defined in + o an expiration time claim (see for example 'exp' defined in Section 3.1.4 of [RFC8392] for CWT); - * a scope claim (see for example 'scope' registered in Section 8.13 + o a scope claim (see for example 'scope' registered in Section 8.13 of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same encoding as 'scope' parameter above. Additionally, this claim has the same value of the 'scope' parameter if the parameter is present in the message, or it takes the value of 'scope' in the Authorization Request otherwise. The access token MAY additionally contain other claims that the transport profile of ACE requires, or other optional parameters. As in [I-D.ietf-ace-oauth-authz], these parameters are included in @@ -456,23 +458,23 @@ Optionally, the Client might want to request necessary information concerning the public keys in the group, as well as concerning the algorithm and related parameters for computing signatures in the group. In such a case, the joining node MAY ask for that information to the KDC in this same request. To this end, it sends the CoAP POST request to the /authz-info endpoint using the Content-Format "application/ace+cbor". The payload of the message MUST be formatted as a CBOR map, including the access token and the following parameters: - * 'sign_info' defined in Section 3.3.1. + o 'sign_info' defined in Section 3.3.1. - * 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple + o 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple value Null, to require information on the exact encoding of public keys used in the group. Alternatively, the joining node may retrieve this information by other means. After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group. In particular, the KDC replies to the Client with a 2.01 (Created) response, using Content-Format "application/ace+cbor" defined in @@ -515,128 +517,125 @@ Note that 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. Applications of this specification MAY define alternative specific negotiations of parameter values for signature algorithm and signature keys, if 'sign_info' and 'pub_key_enc' are not used (OPT2). 3.3.1. 'sign_info' Parameter - The 'sign_info' parameter is an OPTIONAL parameter of the AS Request - Creation Hints message defined in Section 5.1.2. of + The 'sign_info' parameter is an OPTIONAL parameter of the Token Post + response message defined in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. This parameter contains information and parameters about the signature algorithm and the public keys to be used between the Client and the RS. Its exact content is application specific. In this specification and in application profiles building on it, this parameter is used to ask and retrieve from the KDC information about the signature algorithm and related parameters used in the group. When used in the request, the 'sign_info' encodes the CBOR simple value Null, to require information and parameters on the signature algorithm and on the public keys used. - The CDDL notation of the 'sign_info' parameter formatted as in the - request is given below. + The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as + in the request is given below. sign_info_req = nil The 'sign_info' parameter of the 2.01 (Created) response is a CBOR array of one ore more elements. The number of elements is lower or at most equal to the number of groups the client has been authorized to join. Each element contains information about signing parameters and keys for one or more group or topic and is formatted as follows. - * The first element 'id' is an identifier of the group or an array + o The first element 'id' is an identifier of the group or an array of identifiers for the groups for which this information applies. - * The second element 'sign_alg' is an integer or a text string if - the POST request included the 'sing_info' parameter with value + o The second element 'sign_alg' is an integer or a text string if + the POST request included the 'sign_info' parameter with value Null, and indicates the signature algorithm used in the group identified by 'gid'. It is REQUIRED of the application profiles to define specific values that this parameter can take (REQ3), selected from the set of signing algorithms of the COSE Algorithms - registry defined in [RFC8152]. If the POST request did not - include the 'sing_info' parameter, this element is encoded as the - CBOR simple value Null. - - * The third element 'sign_parameters' indicates the parameters of - the signature algorithm. Its structure depends on the value of - 'sign_alg'. It is REQUIRED of the application profiles to define - specific values for this parameter (REQ4). If no parameters of - the signature algorithm are specified, 'sign_parameters' MUST be - encoded as the CBOR simple value Null. If the POST request did - not include the 'sing_info' parameter, this element is encoded as - the CBOR simple value Null. - - * The fourth element 'sign_key_parameters' indicates the parameters - of the key used with the signature algorithm. Its structure - depends on the value of 'sign_alg'. It is REQUIRED of the - application profiles to define specific values for this parameter - (REQ5). If no parameters of the key used with the signature - algorithm are specified, 'sign_key_parameters' MUST be encoded as - the CBOR simple value Null. If the POST request did not include + registry [COSE.Algorithms]. If the POST request did not include the 'sing_info' parameter, this element is encoded as the CBOR simple value Null. - * The fifth element 'pub_key_enc' parameter is optional and MUST + o The third element 'sign_parameters' is a CBOR array indicating the + parameters of the signature algorithm. Its content depends on the + value of 'sign_alg'. It is REQUIRED of the application profiles + to define the possible values and structure for the elements of + this parameter (REQ4). If the POST request did not include the + 'sign_info' parameter, this element is encoded as the CBOR simple + value Null. + + o The fourth element 'sign_key_parameters' is a CBOR array + indicating the parameters of the key used with the signature + algorithm. Its content depends on the value of 'sign_alg'. It is + REQUIRED of the application profiles to define the possible values + and structure for the elements of this parameter (REQ5). If the + POST request did not include the 'sing_info' parameter, this + element is encoded as the CBOR simple value Null. + + o The fifth element 'pub_key_enc' parameter is optional and MUST only be present if the POST request included the 'pub_key_enc' parameter with value Null. If present, it is either a CBOR integer indicating the encoding of public keys used in the group identified by 'gid', or has value Null indicating that the KDC does not act as repository of public keys for group members. Its acceptable values are taken from the "CWT Confirmation Method" - Registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. It is - REQUIRED of the application profiles to define specific values to - use for this parameter (REQ6). + Registry defined in [RFC8747]. It is REQUIRED of the application + profiles to define specific values to use for this parameter + (REQ6). - The CDDL notation of the 'sign_info' parameter formatted as in the - response is given below, with gid formatted as a bstr (note that gid - can be encoded differently, see REQ1). + The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as + in the response is given below, with gid formatted as a bstr (note + that gid can be encoded differently, see REQ1). sign_info_res = [ + sign_info_entry ] sign_info_entry = [ id : gid / [ + gid ], sign_alg : int / tstr / nil, - sign_parameters : any / nil, - sign_key_parameters : any / nil, + sign_parameters : [ any ] / nil, + sign_key_parameters : [ any ] / nil, ? pub_key_enc_res = int / nil ] gid = bstr 3.3.2. 'pub_key_enc' Parameter - The 'pub_key_enc' parameter is an OPTIONAL parameter of the AS - Request Creation Hints message defined in Section 5.1.2. of + The 'pub_key_enc' parameter is an OPTIONAL parameter of the Token + Post response message defined in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. This parameter contains information about the exact encoding of public keys to be used between the Client and the RS. Its exact content is application specific. In this specification and in application profiles building on it, this parameter is used to ask the KDC information about the encoding of public keys used in the group. - The CDDL notation of the 'pub_key_enc' parameter formatted as in the - request is given below. + The CDDL notation [RFC8610] of the 'pub_key_enc' parameter formatted + as in the request is given below. pub_key_enc_req = nil 3.3.3. 'kdcchallenge' Parameter - The 'kdcchallenge' parameter is an OPTIONAL parameter of the AS - Request Creation Hints message defined in Section 5.1.2. of + The 'kdcchallenge' parameter is an OPTIONAL parameter of the Token + Post response message defined in Section 5.1.2. of [I-D.ietf-ace-oauth-authz]. This parameter contains a challenge generated by the KDC and provided to the Client. The Client may use this challenge to prove possession of its own private key in the Joining Request ((see the 'client_cred_verify' parameter in Section 4). 4. Keying Material Provisioning and Group Membership Management This section defines the interface available at the KDC. Moreover, this section specifies how the clients can use this interface to join @@ -647,82 +646,84 @@ Section 4.2). Then, the KDC verifies the access token and that the Client is authorized to join that group. If so, it provides the Client with the keying material to securely communicate with the other members of the group. Whenever used, the Content-Format in messages containing a payload is set to application/ace- groupcomm+cbor, as defined in Section 8.2. When the Client is already a group member, the Client can use the interface at the KDC to perform the following actions: - * The Client can (re-)get the current keying material, for cases + o The Client can (re-)get the current keying material, for cases such as expiration, loss or suspected mismatch, due to e.g. reboot or missed group rekeying. This is described in Section 4.3. - * The Client can retrieve a new individual key, or new input + o The Client can retrieve a new individual key, or new input material to derive it. This is described in Section 4.4. - * The Client can (re-)get the public keys of other group members, + o The Client can (re-)get the public keys of other group members, e.g. if it is aware of new nodes joining the group after itself. This is described in Section 4.5. - * The Client can (re-)get the policies currently enforced in the + o The Client can (re-)get the policies currently enforced in the group. This is described in Section 4.7. - * The Client can (re-)get the version number of the keying material + o The Client can (re-)get the version number of the keying material currently used in the group. This is described in Section 4.8. - * The Client can request to leave the group. This is further + o The Client can request to leave the group. This is further discussed in Section 4.9. Upon receiving a request from a Client, the KDC MUST check that it is storing a valid access token from that Client for the group - identifier assiciated to the endpoint. If that is not the case, i.e. + identifier associated to the endpoint. If that is not the case, i.e. the KDC does not store a valid access token or this is not valid for that Client for the group identifier at hand, the KDC MUST respond to the Client with a 4.01 (Unauthorized) error message. 4.1. Interface at the KDC The KDC is configured with the following resources. Note that the root url-path "ace-group" given here are default names: implementations are not required to use these names, and can define their own instead. The Interface Description (if=) Link Target - Attribute value ace-group is registered (Section 8.9) and can be used - to describe this inferface. + Attribute value ace-group is registered (Section 8.10) and can be + used to describe this interface. - * /ace-group : this resource is fixed and indicates that this - specification is used. Other applications that run on a KDC - implementing this specification MUST NOT use this same resource. + o /ace-group : this resource is fixed and indicates that this + specification is used. If other applications run on a KDC + implementing this specification and use this same resource, these + applications will collide, and a mechanism will be needed to + differentiate the endpoints. - * /ace-group/GROUPNAME : one sub-resource to /ace-group is + o /ace-group/GROUPNAME : one sub-resource to /ace-group is implemented for each group the KDC manages. These resources are identified by the group identifiers of the groups the KDC manages (in this example, the group identifier has value "GROUPNAME"). These resources support GET and POST method. - * /ace-group/GROUPNAME/pub-key : this sub-resource is fixed and + o /ace-group/GROUPNAME/pub-key : this sub-resource is fixed and supports GET and FETCH methods. - * /ace-group/GROUPNAME/policies: this sub-resource is fixed and + o /ace-group/GROUPNAME/policies: this sub-resource is fixed and supports the GET method. - * /ace-group/GROUPNAME/ctx-num: this sub-resource is fixed and + o /ace-group/GROUPNAME/ctx-num: this sub-resource is fixed and supports the GET method. - * /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace- + o /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace- group/GROUPNAME is implemented for each node in the group the KDC manages. These resources are identified by the node name (in this example, the node name has value "NODENAME"). These resources support GET, PUT and DELETE methods. - * /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to + o /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node in the group the KDC manages. These resources are identified by the node name (in this example, the node name has value "NODENAME"). These resources support the POST method. The details for the handlers of each resource are given in the following sections. These endpoints are used to perform the operations introduced in Section 4. 4.1.1. ace-group @@ -736,81 +737,81 @@ 4.1.2.1. POST Handler The POST handler adds the public key of the client to the list of the group members' public keys and returns the symmetric group keying material for the group identified by "GROUPNAME". The handler expects a request with payload formatted as a CBOR map which MAY contain the following fields, which, if included, MUST have the corresponding values: - * 'scope', with value the specific resource that the Client is - authorized to access, i.e. group or topic identifier, and role(s). - This value is a CBOR byte string encoding one scope entry, as - defined in Section 3.1. + o 'scope', with value the specific resource at the KDC that the + Client is authorized to access, i.e. group or topic identifier, + and role(s). This value is a CBOR byte string encoding one scope + entry, as defined in Section 3.1. - * 'get_pub_keys', if the Client wishes to receive the public keys of + o 'get_pub_keys', if the Client wishes to receive the public keys of the other nodes in the group from the KDC. The value is an empty CBOR array. This parameter may be present if the KDC stores the public keys of the nodes in the group and distributes them to the Client; it is useless to have here if the set of public keys of the members of the group is known in another way, e.g. it was provided by the AS. - * 'client_cred', with value the public key or certificate of the + o 'client_cred', with value the public key or certificate of the Client, encoded as a CBOR byte string. This field contains the public key of the Client. This field is used if the KDC is managing (collecting from/distributing to the Client) the public keys of the group members, and if the Client's role in the group will require for it to send messages to the group. The default encoding for public keys is COSE Keys. Alternative specific encodings of this parameter MAY be defined in applications of this - specification (OPT1). + specification (OPT1 in Appendix A). - * 'cnonce', with the same encoding as defined for the "cnonce" + o 'cnonce', with the same encoding as defined for the "cnonce" parameter of Ace, in Section 5.1.2 of [I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C generated by the Client. This parameter MUST be present if the 'client_cred' parameter is present. - * 'client_cred_verify', encoded as a CBOR byte string. This + o 'client_cred_verify', encoded as a CBOR byte string. This parameter MUST be present if the 'client_cred' parameter is present and no public key associated to the client's token can be retrieved for that group. This parameter contains a signature computed by the Client over the scope concatenated with N_S concatenated with N_C, where: - - scope is the byte string specified in the 'scope parameter + * scope is the byte string specified in the 'scope parameter above'. - - N_S is the challenge received from the KDC in the + * N_S is the challenge received from the KDC in the 'kdcchallenge' parameter of the 2.01 (Created) response to the token POST request (see Section 3.3). - - N_C is the nonce generated by the Client and specified in the + * N_C is the nonce generated by the Client and specified in the 'cnonce' parameter above. If the token is not being posted (e.g. if it is used directly to validate TLS instead), it is REQUIRED of the specific profile to define how the challenge N_S is generated (REQ17). The Client computes the signature by using its own private key, whose corresponding public key is either directly specified in the 'client_cred' parameter or included in the certificate specified in the 'client_cred' parameter. - * 'pub_keys_repos', can be present if a certificate is present in + o 'pub_keys_repos', can be present if a certificate is present in the 'client_cred' field, with value the URI of the certificate of the Client. This parameter is encoded as a CBOR text string. Alternative specific encodings of this parameter MAY be defined in applications of this specification (OPT3). - * 'control_path', with value a full URI, encoded as a CBOR text + o 'control_path', with value a full URI, encoded as a CBOR text string. If 'control_path' is supported by the Client, the Client acts as a CoAP server and hosts a resource at this specific URI. The KDC MAY use this URI to send CoAP requests to the Client (acting as CoAP server in this exchange), for example for individual provisioning of new keying material when performing a group rekeying (see Section 4.3), or to inform the Client of its removal from the group Section 5. If the KDC does not implement mechanisms using this resource, it can just ignore this parameter. Other additional functionalities of this resource MAY be defined in application profiles of this specifications (OPT9). In @@ -837,156 +838,156 @@ group members. Application profiles MAY define optional or mandatory payload formats for specific error cases (OPT6). If the KDC stores the group members' public keys, the handler checks if one public key is already associated to the access token received (see Section 4.2 for an example) and to the group identified by "GROUPNAME". If that is not the case, it retrieves it from the 'client_cred' field and associates it to the access token received, after verifications succed. In particular, the KDC verifies: - * that such public key has an acceptable format for the group + o that such public key has an acceptable format for the group identified by "GROUPNAME", i.e. it is encoded as expected and is compatible with the signature algorithm and possible associated parameters. If that cannot be verified, it is RECOMMENDED that the handler stops the process and responds with a 4.00 (Bad Request) error message. Applications profiles MAY define alternatives (OPT5). - * that the signature contained in "client_cred_verify" passes + o that the signature contained in "client_cred_verify" passes verification. If that cannot be verified, the handler MUST respond with a 4.00 (Bad Request) error message, and if the token was posted (see REQ17) including the 'kdcchallenge' associated to this Client (see Section 3.3) if it can be retrieved, or otherwise newly generated, in a CBOR map in the payload. This error response MUST also have Content-Format "application/ace+cbor". If one public key is already associated to the access token and to that group, but the 'client_cred' is populated with a different public key, the handler MUST delete the previous one and replace it with this one, after verifying the points above. If the token was posted but the KDC cannot retrieve the 'kdcchallenge' associated to this Client (see Section 3.3), the KDC MUST respond with a 4.00 Bad Request error response, including a newly generated 'kdcchallenge' in a CBOR map in the payload. This error response MUST also have Content-Format "application/ace+cbor". If all verifications succeed, the handler: - * Adds the node to the list of current members of the group. + o Adds the node to the list of current members of the group. - * Assigns a name NODENAME to the node, and creates a sub-resource to + o Assigns a name NODENAME to the node, and creates a sub-resource to /ace-group/GROUPNAME/ at the KDC (e.g. "/ace- group/GROUPNAME/nodes/NODENAME"). - * Associates the identifier "NODENAME" with the access token and the + o Associates the identifier "NODENAME" with the access token and the secure session for that node. - * If the KDC manages public keys for group members: + o If the KDC manages public keys for group members: - - Adds the retrieved public key of the node to the list of public + * Adds the retrieved public key of the node to the list of public keys stored for the group identified by "GROUPNAME" - - Associates the node's public key with its access token and the + * Associates the node's public key with its access token and the group identified by "GROUPNAME", if such association did not already exist. - * Returns a 2.01 (Created) message containing the symmetric group + o Returns a 2.01 (Created) message containing the symmetric group keying material, the group policies and all the public keys of the current members of the group, if the KDC manages those and the Client requested them. The response message also contains the URI path to the sub-resource created for that node in a Location-Path CoAP option. The payload of the response is formatted as a CBOR map which MUST contain the following fields and values: - * 'gkty', identifying the key type of the 'key' parameter. The set + o 'gkty', identifying the key type of the 'key' parameter. The set of values can be found in the "Key Type" column of the "ACE Groupcomm Key" Registry. Implementations MUST verify that the key type matches the application profile being used, if present, as registered in the "ACE Groupcomm Key" registry. - * 'key', containing the keying material for the group communication, + o 'key', containing the keying material for the group communication, or information required to derive it. - * 'num', containing the version number of the keying material for + o 'num', containing the version number of the keying material for the group communication, formatted as an integer. The initial version MUST be set to 0 at the KDC. This is a strictly monotonic increasing field. The exact format of the 'key' value MUST be defined in applications of this specification (REQ7), as well as accepted values of 'gkty' by the application (REQ8). Additionally, documents specifying the key format MUST register it in the "ACE Groupcomm Key" registry defined - in Section 8.5, including its name, type and application profile to + in Section 8.6, including its name, type and application profile to be used with. +----------+----------------+---------+-------------------------+ | Name | Key Type Value | Profile | Description | +----------+----------------+---------+-------------------------+ | Reserved | 0 | | This value is reserved | +----------+----------------+---------+-------------------------+ Figure 5: Key Type Values Optionally, the response MAY contain the following parameters, which, if included, MUST have the corresponding values: - * 'ace-groupcomm-profile', with value a CBOR integer that MUST be + o 'ace-groupcomm-profile', with value a CBOR integer that MUST be used to uniquely identify the application profile for group communication. Applications of this specification MUST register an application profile identifier and the related value for this parameter in the "ACE Groupcomm Profile" Registry (REQ12). - * 'exp', with value the expiration time of the keying material for + o 'exp', with value the expiration time of the keying material for the group communication, encoded as a CBOR unsigned integer. This field contains a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what specified for NumericDate in Section 2 of [RFC7519]. Group members MUST stop using the keying material to protect outgoing messages and retrieve new keying material at the time indicated in this field. - * 'exp_delta', with value the time interval (starting at 'exp') + o 'exp_delta', with value the time interval (starting at 'exp') during which the keying material for the group communication can still be used for verifying incoming messages, encoded as a CBOR unsigned integer. This field contains a numeric value representing the number of seconds from 'exp' until the specified UTC date/time after which group members MUST stop using the keying material to verify incoming messages. - * 'pub_keys', may only be present if 'get_pub_keys' was present in + o 'pub_keys', may only be present if 'get_pub_keys' was present in the request. This parameter is a CBOR byte string, which encodes the public keys of all the group members paired with the respective member identifiers. The default encoding for public keys is COSE Keys, so the default encoding for 'pub_keys' is a - CBOR byte string wrapping a COSE_KeySet (see [RFC8152]), which - contains the public keys of all the members of the group. In - particular, each COSE Key in the COSE_KeySet includes the - identifier of the corresponding group member as value of its 'kid' - key parameter. Alternative specific encodings of this parameter - MAY be defined in applications of this specification (OPT1). The - specific format of the identifiers of group members MUST be - specified in the application profile (REQ9). + CBOR byte string wrapping a COSE_KeySet (see + [I-D.ietf-cose-rfc8152bis-struct]), which contains the public keys + of all the members of the group. In particular, each COSE Key in + the COSE_KeySet includes the identifier of the corresponding group + member as value of its 'kid' key parameter. Alternative specific + encodings of this parameter MAY be defined in applications of this + specification (OPT1). The specific format of the identifiers of + group members MUST be specified in the application profile (REQ9). - * 'peer_roles', MUST be present if 'pub_keys' is present. This + o 'peer_roles', MUST be present if 'pub_keys' is present. This parameter is a CBOR array of n elements, with n the number of members in the group (and number of public keys included in the 'pub_keys' parameter). The i-th element of the array specifies the role (or CBOR array of roles) that the group member associated to the i-th public key in 'pub_keys' has in the group. In particular, each array element is encoded as the role element of a scope entry, as defined in Section 3.1. - * 'group_policies', with value a CBOR map, whose entries specify how + o 'group_policies', with value a CBOR map, whose entries specify how the group handles specific management aspects. These include, for instance, approaches to achieve synchronization of sequence numbers among group members. The elements of this field are registered in the "ACE Groupcomm Policy" Registry. This specification defines the two elements "Sequence Number Synchronization Method" and "Key Update Check Interval", which are summarized in Figure 6. Application profiles that build on this document MUST specify the exact content format of included map entries (REQ14). @@ -1008,21 +1009,21 @@ | | | | | | | Key Update | TBD2 | int | Polling interval | [[this | | Check | | | in seconds, to | document]] | | Interval | | | check for new | | | | | | keying material at | | | | | | the KDC | | +--------------+-------+----------|--------------------|------------+ Figure 6: ACE Groupcomm Policies - * 'mgt_key_material', encoded as a CBOR byte string and containing + o 'mgt_key_material', encoded as a CBOR byte string and containing the administrative keying material to participate in the group rekeying performed by the KDC. The application profile MUST define if this field is used, and if used then MUST specify the exact format and content which depend on the specific rekeying scheme used in the group. If the usage of 'mgt_key_material' is indicated and its format defined for a specific key management scheme, that format must explicitly indicate the key management scheme itself. If a new rekeying scheme is defined to be used for an existing 'mgt_key_material' in an existing profile, then that profile will have to be updated accordingly, especially with @@ -1073,34 +1074,34 @@ 4.1.3.1. FETCH Handler The FETCH handler receives identifiers of group members for the group identified by "GROUPNAME" and returns the public keys of such group members. The handler expects a request with payload formatted as a CBOR map. The payload of this request is a CBOR Map that MUST contain the following fields: - * 'get_pub_keys', whose value is a non-empty CBOR array containing + o 'get_pub_keys', whose value is a non-empty CBOR array containing two CBOR arrays: - - The first array contains zero or more roles (or combination of + * The first array contains zero or more roles (or combination of roles) of group members for the group identified by "GROUPNAME". - - The second array contains zero or more identifiers of group + * The second array contains zero or more identifiers of group members for the group identified by "GROUPNAME". - The CDDL definition of 'get_pub_keys' is given in Figure 7 using as - example encoding: node identifier encoded as byte string, role - identifier as text string, and combination of roles encoded as a CBOR - array of roles. Note that the empty array is not valid for this + The CDDL definition [RFC8610] of 'get_pub_keys' is given in Figure 7 + using as example encoding: node identifier encoded as byte string, + role identifier as text string, and combination of roles encoded as a + CBOR array of roles. Note that the empty array is not valid for this handler, but is valid for the value of "get_pub_keys" received by the handler of POST to ace-group/GROUPNAME (see Section 4.1.2.1). id = bstr role = tstr comb_role = [ 2*role ] get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ] / [ ] @@ -1135,23 +1136,23 @@ payload formatted as a CBOR byte string of zero length. The specific format of public keys as well as of identifiers of group members is specified by the application profile (OPT1, REQ9). The handler MAY enforce one of the following policies, in order to handle possible identifiers that are included in the 'get_pub_keys' parameter of the request but are not associated to any current group member. Such a policy MUST be specified by the application profile (REQ13) - * The KDC silently ignores those identifiers. + o The KDC silently ignores those identifiers. - * The KDC retains public keys of group members for a given amount of + o The KDC retains public keys of group members for a given amount of time after their leaving, before discarding them. As long as such public keys are retained, the KDC provides them to a requesting Client. Note that this resource handlers only verify that the node is authorized by the AS to access this resource. Nodes that are not members of the group but are authorized to do signature verifications on the group messages may be allowed to access this resource, if the application needs it. @@ -1258,21 +1259,21 @@ of the group. If verification fails, the KDC MUST respond with a 4.00 (Bad Request) error message. If verification succeeds, the handler returns a 2.05 (Content) message containing newly-generated individual keying material for the Client, or information enabling the Client to derive it. The payload of the response is formatted as a CBOR map. The specific format of newly-generated individual keying material for group members, or of the information to derive it, and corresponding CBOR label, MUST be specified in the application profile (REQ15) and registered in - Section 8.4. + Section 8.5. 4.1.6.2. GET Handler The handler expects a GET request. The handler verifies that the group identifier of the /ace-group/ GROUPNAME path is a subset of the 'scope' stored in the access token associated to this client, identified by "NODENAME". If verification fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. @@ -1285,21 +1286,21 @@ 4.00 (Bad Request) error message. If verification succeeds, the handler returns a 2.05 (Content) message containing both the group keying material and the individual keying material for the Client, or information enabling the Client to derive it. The payload of the response is formatted as a CBOR map. The format for the group keying material is the same as defined in the response of Section 4.1.2.2. The specific format of individual keying material for group members, or of the information to derive it, and corresponding CBOR label, MUST be specified in the - application profile (REQ15) and registered in Section 8.4. + application profile (REQ15) and registered in Section 8.5. 4.1.6.3. DELETE Handler The DELETE handler removes the node identified by "NODENAME" from the group identified by "GROUPNAME". The handler expects a request with method DELETE (and empty payload). The handler only accept a request from the node that matches the "NODENAME" used in Uri-Path, and that is part of the "GROUPNAME" @@ -1396,30 +1398,30 @@ Figure 8: Message Flow of First Exchange for Group Joining If not previously established, the Client and the KDC MUST first establish a pairwise secure communication channel (REQ16). This can be achieved, for instance, by using a transport profile of ACE. The Joining exchange MUST occur over that secure channel. The Client and the KDC MAY use that same secure channel to protect further pairwise communications that must be secured. The secure communication protocol is REQUIRED to establish the secure - channel by using the proof-of-possession key bound to the access - token. As a result, the 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. + channel between Client and KDC by using the proof-of-possession key + bound to the access token. As a result, the 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. To join the group, the Client sends a CoAP POST request to the /ace- group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group identifier of the group to join, formatted as specified in - Section 4.1.2.1. This group identifier is the same as the scope + Section 4.1.2.1. This group identifier is the same as in the scope entry corresponding to that group, specified in the 'scope' parameter of the Authorization Request/Response, or it can be retrieved from it. Note that, in case of successful joining, the Client will receive the URI to retrieve individual or group keying material and to leave the group in the Location-Path option of the response. If the node is joining a group for the first time, and the KDC maintains the public keys of the group members, the Client is REQUIRED to send its own public key and proof of possession ("client_cred" and "client_cred_verify" in Section 4.1.2.1). The @@ -1442,29 +1444,29 @@ different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, Section 4.1.4.1). After distributing the new group keying material, the KDC MUST increment the version number of the keying material. 4.3. Retrieval of Updated Keying Material When any of the following happens, a node MUST stop using the owned group keying material to protect outgoing messages, and SHOULD stop using it to decrypt and verify incoming messages. - * Upon expiration of the keying material, according to what + o Upon expiration of the keying material, according to what indicated by the KDC with the 'exp' (and possibly the 'exp_delta') parameter in a Joining Response, or to a pre-configured value. - * Upon receiving a notification of revoked/renewed keying material + o Upon receiving a notification of revoked/renewed keying material from the KDC, possibly as part of an update of the keying material (rekeying) triggered by the KDC. - * Upon receiving messages from other group members without being + o Upon receiving messages from other group members without being able to retrieve the keying material to correctly decrypt them. This may be due to rekeying messages previously sent by the KDC, that the Client was not able to receive or decrypt. In either case, if it wants to continue participating in the group communication, the node has to request the latest keying material from the KDC. To this end, the Client sends a CoAP GET request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, formatted as specified in Section 4.1.6.2. @@ -1494,42 +1496,43 @@ | GET ace-group/GROUPNAME/nodes/NODENAME | | | |<-------- Key Distribution Response: 2.05 (Content) ---------| | | Figure 9: Message Flow of Key Distribution Request-Response Alternatively, the re-distribution of keying material can be initiated by the KDC, which e.g.: - * Can make the ace-group/GROUPNAME/nodes/NODENAME resource - Observable, and send notifications to Clients when the keying - material is updated. + o Can make the ace-group/GROUPNAME/nodes/NODENAME resource + Observable [RFC7641], and send notifications to Clients when the + keying material is updated. - * Can send the payload of the Key Distribution Response in one or + o Can send the payload of the Key Distribution Response in one or multiple multicast POST requests to the members of the group, using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. - * Can send unicast POST requests to each Client over a secure + o Can send unicast POST requests to each Client over a secure channel, with the same payload as the Key Distribution Response. When sending such requests, the KDC can target the URI path possibly provided by the intended recipient upon joining the group, as specified in the 'control_path' parameter of the Joining Request (see Section 4.1.2.1). - * Can act as a publisher in a pub-sub scenario, and update the + o Can act as a publisher in a pub-sub scenario, and update the keying material by publishing on a specific topic on a broker, which all the members of the group are subscribed to. Note that these methods of KDC-initiated key distribution have different security properties and require different security - associations. + associations. Moreover, congestion control mechanism need to be + implemented where Observe is used, see Section 4.5.1 of [RFC7641]. 4.4. Retrieval of New Keying Material Beside possible expiration and depending on what part of the keying material is no longer eligible to be used, the client may need to communicate to the KDC its need for that part to be renewed. For example, if the Client uses an individual key to protect outgoing traffic and has to renew it, the node may request a new one, or new input material to derive it, without renewing the whole group keying material. @@ -1578,32 +1581,32 @@ Figure 11 and Figure 12 give an overview of the exchanges described above. Client KDC | | |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->| | | |<--------- Public Key Response: 2.05 (Content) ---------| | | - Figure 11: Message Flow of Public Key Exchange to Request All - Members Public Keys + Figure 11: Message Flow of Public Key Exchange to Request All Members + Public Keys Client KDC | | |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->| | | |<--------- Public Key Response: 2.05 (Created) ----------| | | - Figure 12: Message Flow of Public Key Exchange to Request - Specific Members Public Keys + Figure 12: Message Flow of Public Key Exchange to Request Specific + Members Public Keys 4.6. Update of Public Key In case the KDC maintains the public keys of group members, a node in the group can contact the KDC to upload a new public key to use in the group, and replace the currently stored one. To this end, the Client performs a Public Key Update Request/Response exchange with the KDC, i.e. it sends a CoAP POST request to the /ace- group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where @@ -1736,83 +1739,92 @@ Joining Request. 6. ACE Groupcomm Parameters This specification defines a number of fields used during the second part of the message exchange, after the ACE Token POST exchange. The table below summarizes them, and specifies the CBOR key to use instead of the full descriptive name. Note that the media type ace- groupcomm+cbor MUST be used when these fields are transported. - +-----------------------+------+---------------+------------------+ + +-----------------------+------+-----------------+------------------+ | Name | CBOR | CBOR Type | Reference | | | Key | | | - +=======================+======+===============+==================+ + +-----------------------+------+-----------------+------------------+ | scope | TBD | byte string | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | get_pub_keys | TBD | array | Section 4.1.2.1, | | | | | Section 4.1.3.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | client_cred | TBD | byte string | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | cnonce | TBD | byte string | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | client_cred_verify | TBD | byte string | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | pub_keys_repos | TBD | text string | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | control_path | TBD | text string | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | gkty | TBD | int / text | Section 4.1.2.1 | | | | string | | - +-----------------------+------+---------------+------------------+ + | | | | | | key | TBD | see "ACE | Section 4.1.2.1 | - | | | Groupcomm | | - | | | Key" Registry | | - +-----------------------+------+---------------+------------------+ + | | | Groupcomm Key" | | + | | | Registry | | + | | | | | | num | TBD | int | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | ace-groupcomm-profile | TBD | int | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | exp | TBD | int | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | exp_delta | TBD | int | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | pub_keys | TBD | byte string | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | peer_roles | TBD | array | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | group_policies | TBD | map | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ + | | | | | | mgt_key_material | TBD | byte string | Section 4.1.2.1 | - +-----------------------+------+---------------+------------------+ - - Table 1 + +-----------------------+------+-----------------+------------------+ 7. Security Considerations When a Client receives a message from a sender for the first time, it needs to have a mechanism in place to avoid replay, e.g. Appendix B.2 of [RFC8613]. In case the Client rebooted and lost the security state used to protect previous communication with that sender, such a mechanism is useful for the recipient to be on the safe side. If the group has renewed its group keying material, the time window between the end of the rekeying process and the next loss of security state is safe for recipients, as replayed older messages protected with previous keying material will not be accepted. The KDC must renew the group keying material upon its expiration. The KDC should renew the keying material upon group membership change, and should provide it to the current group members through the rekeying scheme used in the group. + The KDC should renew the group keying material after rebooting, even + in the case where all keying material is stored in persistent + storage. However, if the KDC relies on Observe responses to notify + the group of renewed keying material, after rebooting the KDC will + have lost all the Observations up to that point, and the previous + keying material will be used to protect messages in the group anyway. + The KDC will rely on each node requesting updates of the group keying + material to establish the new keying material in the nodes, or, if + implemented, it can push the update to the nodes in the group using + the 'control_path' resource. + The KDC may enforce a rekeying policy that takes into account the overall time required to rekey the group, as well as the expected rate of changes in the group membership. That is, the KDC may not rekey the group at every membership change, for instance if members' joining and leaving occur frequently and performing a group rekeying takes too long. Instead, the KDC may rekey the group after a minimum number of group members have joined or left within a given time interval, or during predictable network inactivity periods. @@ -1822,20 +1834,25 @@ could be able to access the keying material used before their joining, and thus could access past group communications. Also, until the KDC performs a group rekeying, the newly leaving nodes would still be able to access upcoming group communications that are protected with the keying material that has not yet been updated. The KDC needs to have a mechanism in place to detect DoS attacks from nodes constantly initiating rekeys (for example by updating their public key), such as removing these nodes from the group. + The KDC also needs to have a congestion control mechanism in place to + avoid network congestion when the KDC renews the group keying + material; CoAP and Observe give guidancee on such mechanisms, see + Section 4.7 of [RFC7252] and Section 4.5.1 of [RFC7641]. + 7.1. Update of Keying Material A group member can receive a message shortly after the group has been rekeyed, and new keying material has been distributed by the KDC. In the following two cases, this may result in misaligned keying material between the group members. In the first case, the sender protects a message using the old keying material. However, the recipient receives the message after having received the new keying material, hence not being able to correctly @@ -1913,376 +1930,396 @@ authorization servers, clients and resource servers that support the ACE groupcomm framework as specified in [this document]. Additional information: Magic number(s): n/a File extension(s): .ace-groupcomm Macintosh file type code(s): n/a - Person & email address to contact for further information: - iesg@ietf.org (mailto:iesg@ietf.org) + iesg@ietf.org [1] Intended usage: COMMON Restrictions on usage: None - Author: Francesca Palombini francesca.palombini@ericsson.com - (mailto:francesca.palombini@ericsson.com) + + Author: Francesca Palombini francesca.palombini@ericsson.com [2] Change controller: IESG 8.2. CoAP Content-Formats Registry This specification registers the following entry to the "CoAP Content-Formats" registry, within the "CoRE Parameters" registry: Media Type: application/ace-groupcomm+cbor Encoding: - ID: TBD Reference: [this document] -8.3. ACE Authorization Server Request Creation Hints Registry +8.3. OAuth Parameters Registry - IANA is asked to register the following entries in the "ACE - Authorization Server Request Creation Hints" Registry defined in - Section 8.1 of [I-D.ietf-ace-oauth-authz]. + The following registrations are done for the OAuth ParametersRegistry + following the procedure specified in section 11.2 of [RFC6749]: - * Name: sign_info + o Parameter name: sign_info o Parameter usage location: token + request, token response o Change Controller: IESG o Specification + Document(s): [[This specification]] - * CBOR Key: TBD (range -256 to 255) + o Parameter name: pub_key_enc o Parameter usage location: token + request, token response o Change Controller: IESG o Specification + Document(s): [[This specification]] - * Value Type: any + o Parameter name: kdcchallenge o Parameter usage location: token + response o Change Controller: IESG o Specification Document(s): + [[This specification]] - * Reference: [[This specification]] +8.4. OAuth Parameters CBOR Mappings Registry - * Name: pub_key_enc + The following registrations are done for the OAuth Parameters CBOR + Mappings Registry following the procedure specified in section 8.9 of + [I-D.ietf-ace-oauth-authz]: + * Name: sign_info * CBOR Key: TBD (range -256 to 255) + * Value Type: any + * Reference: \[\[This specification\]\] + * Name: pub_key_enc + * CBOR Key: TBD (range -256 to 255) * Value Type: integer - - * Reference: [[This specification]] + * Reference: \[\[This specification\]\] * Name: kdcchallenge - * CBOR Key: TBD (range -256 to 255) - * Value Type: byte string + * Reference: \[\[This specification\]\] - * Reference: [[This specification]] - -8.4. ACE Groupcomm Parameters Registry +8.5. ACE Groupcomm Parameters Registry This specification establishes the "ACE Groupcomm Parameters" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines - are provided in Section 8.10. + are provided in Section 8.11. The columns of this Registry are: - * Name: This is a descriptive name that enables easier reference to + o Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. - * CBOR Key: This is the value used as CBOR key of the item. These + o CBOR Key: This is the value used as CBOR key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a string. - * CBOR Type: This contains the CBOR type of the item, or a pointer + o CBOR Type: This contains the CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item. - * Reference: This contains a pointer to the public specification for + o Reference: This contains a pointer to the public specification for the item. This Registry has been initially populated by the values in Section 6. The Reference column for all of these entries refers to sections of this document. -8.5. ACE Groupcomm Key Registry +8.6. ACE Groupcomm Key Registry This specification establishes the "ACE Groupcomm Key" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines are - provided in Section 8.10. + provided in Section 8.11. The columns of this Registry are: - * Name: This is a descriptive name that enables easier reference to + o Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. - * Key Type Value: This is the value used to identify the keying + o Key Type Value: This is the value used to identify the keying material. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. - * Profile: This field may contain one or more descriptive strings of + o Profile: This field may contain one or more descriptive strings of application profiles to be used with this item. The values should be taken from the Name column of the "ACE Groupcomm Profile" Registry. - * Description: This field contains a brief description of the keying + o Description: This field contains a brief description of the keying material. - * References: This contains a pointer to the public specification + o References: This contains a pointer to the public specification for the format of the keying material, if one exists. This Registry has been initially populated by the values in Figure 5. The specification column for all of these entries will be this document. -8.6. ACE Groupcomm Profile Registry +8.7. ACE Groupcomm Profile Registry This specification establishes the "ACE Groupcomm Profile" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines - are provided in Section 8.10. It should be noted that, in addition + are provided in Section 8.11. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of this Registry are: - * Name: The name of the application profile, to be used as value of + o Name: The name of the application profile, to be used as value of the profile attribute. - * Description: Text giving an overview of the application profile + o Description: Text giving an overview of the application profile and the context it is developed for. - * CBOR Value: CBOR abbreviation for the name of this application + o CBOR Value: CBOR abbreviation for the name of this application profile. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use. - * Reference: This contains a pointer to the public specification of + o Reference: This contains a pointer to the public specification of the abbreviation for this application profile, if one exists. -8.7. ACE Groupcomm Policy Registry +8.8. ACE Groupcomm Policy Registry This specification establishes the "ACE Groupcomm Policy" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert review guidelines - are provided in Section 8.10. It should be noted that, in addition + are provided in Section 8.11. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of this Registry are: - * Name: The name of the group communication policy. + o Name: The name of the group communication policy. - * CBOR label: The value to be used to identify this group + o CBOR label: The value to be used to identify this group communication policy. Key map labels MUST be unique. The label can be a positive integer, a negative integer or a string. Integer values between 0 and 255 and strings of length 1 are designated as Standards Track Document required. Integer values from 256 to 65535 and strings of length 2 are designated as Specification Required. Integer values of greater than 65535 and strings of length greater than 2 are designated as expert review. Integer values less than -65536 are marked as private use. - * CBOR type: the CBOR type used to encode the value of this group + o CBOR type: the CBOR type used to encode the value of this group communication policy. - * Description: This field contains a brief description for this + o Description: This field contains a brief description for this group communication policy. - * Reference: This field contains a pointer to the public + o Reference: This field contains a pointer to the public specification providing the format of the group communication policy, if one exists. This registry will be initially populated by the values in Figure 6. -8.8. Sequence Number Synchronization Method Registry +8.9. Sequence Number Synchronization Method Registry This specification establishes the "Sequence Number Synchronization Method" IANA Registry. The Registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Expert - review guidelines are provided in Section 8.10. It should be noted + review guidelines are provided in Section 8.11. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of this Registry are: - * Name: The name of the sequence number synchronization method. + o Name: The name of the sequence number synchronization method. - * Value: The value to be used to identify this sequence number + o Value: The value to be used to identify this sequence number synchronization method. - * Description: This field contains a brief description for this + o Description: This field contains a brief description for this sequence number synchronization method. - * Reference: This field contains a pointer to the public + o Reference: This field contains a pointer to the public specification describing the sequence number synchronization method. -8.9. Interface Description (if=) Link Target Attribute Values Registry +8.10. Interface Description (if=) Link Target Attribute Values Registry This specification registers the following entry to the "Interface Description (if=) Link Target Attribute Values Registry" registry, within the "CoRE Parameters" registry: - * Attribute Value: ace-group + o Attribute Value: ace-group - * Description: The 'ace group' interface is used to provision keying + o Description: The 'ace group' interface is used to provision keying material and related informations and policies to members of a group using the Ace framework. - * Reference: [This Document] + o Reference: [This Document] -8.10. Expert Review Instructions +8.11. Expert Review Instructions The IANA Registries established in this document are defined as expert review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude. Expert reviewers should take into consideration the following points: - * Point squatting should be discouraged. Reviewers are encouraged + o Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments, code points in other ranges should not be assigned for testing. - * Specifications are required for the standards track range of point + o Specifications are required for the standards track range of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible. Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. - * Experts should take into account the expected usage of fields when + o Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for standards track documents does not mean that a standards track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size. 9. References 9.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)", Work in Progress, Internet-Draft, - draft-ietf-ace-cwt-proof-of-possession-11, 31 October - 2019, . + [COSE.Algorithms] + IANA, "COSE Algorithms", + . + + [COSE.Key.Types] + IANA, "COSE Key Types", + . [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)", Work in Progress, Internet-Draft, - draft-ietf-ace-oauth-authz-33, 6 February 2020, - . + Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 + (work in progress), February 2020. [I-D.ietf-ace-oauth-params] Seitz, L., "Additional OAuth Parameters for Authorization - in Constrained Environments (ACE)", Work in Progress, - Internet-Draft, draft-ietf-ace-oauth-params-13, 28 April - 2020, . + in Constrained Environments (ACE)", draft-ietf-ace-oauth- + params-13 (work in progress), April 2020. [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., and J. Park, - "Group OSCORE - Secure Group Communication for CoAP", Work - in Progress, Internet-Draft, draft-ietf-core-oscore- - groupcomm-08, 6 April 2020, . + "Group OSCORE - Secure Group Communication for CoAP", + draft-ietf-core-oscore-groupcomm-08 (work in progress), + April 2020. + + [I-D.ietf-cose-rfc8152bis-algs] + Schaad, J., "CBOR Object Signing and Encryption (COSE): + Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-09 + (work in progress), June 2020. + + [I-D.ietf-cose-rfc8152bis-struct] + Schaad, J., "CBOR Object Signing and Encryption (COSE): + Structures and Process", draft-ietf-cose-rfc8152bis- + struct-10 (work in progress), June 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", + RFC 6749, DOI 10.17487/RFC6749, October 2012, + . + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . + [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained + Application Protocol (CoAP)", RFC 7252, + DOI 10.17487/RFC7252, June 2014, + . + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . - [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, . + [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. + Tschofenig, "Proof-of-Possession Key Semantics for CBOR + Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March + 2020, . + 9.2. Informative References - [I-D.dijk-core-groupcomm-bis] - Dijk, E., Wang, C., and M. Tiloca, "Group Communication - for the Constrained Application Protocol (CoAP)", Work in - Progress, Internet-Draft, draft-dijk-core-groupcomm-bis- - 03, 9 March 2020, . + [I-D.bormann-core-ace-aif] + Bormann, C., "An Authorization Information Format (AIF) + for ACE", draft-bormann-core-ace-aif-07 (work in + progress), February 2020. [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)", Work in Progress, - Internet-Draft, draft-ietf-ace-dtls-authorize-09, 18 - December 2019, . + Constrained Environments (ACE)", draft-ietf-ace-dtls- + authorize-10 (work in progress), May 2020. [I-D.ietf-ace-mqtt-tls-profile] Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile - of ACE", Work in Progress, Internet-Draft, draft-ietf-ace- - mqtt-tls-profile-04, 9 March 2020, . + of ACE", draft-ietf-ace-mqtt-tls-profile-05 (work in + progress), May 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", Work in Progress, - Internet-Draft, draft-ietf-ace-oscore-profile-10, 9 March - 2020, . + for Constrained Environments Framework", draft-ietf-ace- + oscore-profile-10 (work in progress), March 2020. [I-D.ietf-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol - (CoAP)", Work in Progress, Internet-Draft, draft-ietf- - core-coap-pubsub-09, 30 September 2019, - . + (CoAP)", draft-ietf-core-coap-pubsub-09 (work in + progress), September 2019. + + [I-D.ietf-core-groupcomm-bis] + Dijk, E., Wang, C., and M. Tiloca, "Group Communication + for the Constrained Application Protocol (CoAP)", draft- + ietf-core-groupcomm-bis-00 (work in progress), March 2020. [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, DOI 10.17487/RFC2093, July 1997, . [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, DOI 10.17487/RFC2094, July 1997, . @@ -2293,292 +2330,304 @@ . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . + [RFC7641] Hartke, K., "Observing Resources in the Constrained + Application Protocol (CoAP)", RFC 7641, + DOI 10.17487/RFC7641, September 2015, + . + [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . + [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data + Definition Language (CDDL): A Notational Convention to + Express Concise Binary Object Representation (CBOR) and + JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, + June 2019, . + [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, . - [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. - Tschofenig, "Proof-of-Possession Key Semantics for CBOR - Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March - 2020, . +9.3. URIs + + [1] mailto:iesg@ietf.org + + [2] mailto:francesca.palombini@ericsson.com Appendix A. Requirements on Application Profiles This section lists the requirements on application profiles of this specification,for the convenience of application profile designers. - * REQ1: Specify the encoding and value of the identifier of group or + o REQ1: Specify the encoding and value of the identifier of group or topic, for scope entries of 'scope' (see Section 3.1). - * REQ2: Specify the encoding and value of roles, for scope entries + o REQ2: Specify the encoding and value of roles, for scope entries of 'scope' (see Section 3.1). - * REQ3: If used, specify the acceptable values for 'sign_alg' (see + o REQ3: If used, specify the acceptable values for 'sign_alg' (see Section 3.3). - * REQ4: If used, specify the acceptable values for 'sign_parameters' + o REQ4: If used, specify the acceptable values for 'sign_parameters' (see Section 3.3). - * REQ5: If used, specify the acceptable values for + o REQ5: If used, specify the acceptable values for 'sign_key_parameters' (see Section 3.3). - * REQ6: If used, specify the acceptable values for 'pub_key_enc' + o REQ6: If used, specify the acceptable values for 'pub_key_enc' (see Section 3.3). - * REQ7: Specify the exact format of the 'key' value (see + o REQ7: Specify the exact format of the 'key' value (see Section 4.1.2.1). - * REQ8: Specify the acceptable values of 'gkty' (see + o REQ8: Specify the acceptable values of 'gkty' (see Section 4.1.2.1). - * REQ9: Specify the format of the identifiers of group members (see + o REQ9: Specify the format of the identifiers of group members (see Section 4.1.2.1). - * REQ10: Specify the communication protocol the members of the group + o REQ10: Specify the communication protocol the members of the group must use (e.g., multicast CoAP). - * REQ11: Specify the security protocol the group members must use to + o REQ11: Specify the security protocol the group members must use to protect their communication (e.g., group OSCORE). This must provide encryption, integrity and replay protection. - * REQ12: Specify and register the application profile identifier + o REQ12: Specify and register the application profile identifier (see Section 4.1.2.1). - * REQ13: Specify policies at the KDC to handle ids that are not + o REQ13: Specify policies at the KDC to handle ids that are not included in get_pub_keys (see Section 4.1.3.1). - * REQ14: If used, specify the format and content of 'group_policies' + o REQ14: If used, specify the format and content of 'group_policies' and its entries (see Section 4.1.2.1). - * REQ15: 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 4.1.6.2). - * REQ16: Specify how the communication is secured between Client and + o REQ16: Specify how the communication is secured between Client and KDC. Optionally, specify tranport profile of ACE [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see Section 4.2. - * REQ17: Specify how the nonce N_S is generated, if the token is not + 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). - * REQ18: Specify if 'mgt_key_material' used, and if yes specify its + o REQ18: Specify if 'mgt_key_material' used, and if yes specify its format and content (see Section 4.1.2.1). If the usage of 'mgt_key_material' is indicated and its format defined for a specific key management scheme, that format must explicitly indicate the key management scheme itself. If a new rekeying scheme is defined to be used for an existing 'mgt_key_material' in an existing profile, then that profile will have to be updated accordingly, especially with respect to the usage of 'mgt_key_material' related format and content. - * OPT1: Optionally, specify the encoding of public keys, of + o OPT1: Optionally, specify the encoding of public keys, of 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see Section 4.1.2.1). - * OPT2: Optionally, specify the negotiation of parameter values for + o OPT2: Optionally, specify the negotiation of parameter values for signature algorithm and signature keys, if 'sign_info' and 'pub_key_enc' are not used (see Section 3.3). - * OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the + o OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the default is not used (see Section 4.1.2.1). - * OPT4: Optionally, specify policies that instruct clients to retain + o OPT4: Optionally, specify policies that instruct clients to retain messages and for how long, if they are unsuccessfully decrypted (see Section 4.3). This makes it possible to decrypt such messages after getting updated keying material. - * OPT5: Optionally, specify the behavior of the handler in case of + o OPT5: Optionally, specify the behavior of the handler in case of failure to retrieve a public key for the specific node (see Section 4.1.2.1). - * OPT6: Optionally, specify possible or required payload formats for + o OPT6: Optionally, specify possible or required payload formats for specific error cases. - * OPT7: Optionally, specify CBOR values to use for abbreviating + o OPT7: Optionally, specify CBOR values to use for abbreviating identifiers of roles in the group or topic (see Section 3.1). - * OPT8: Optionally, specify policies for the KDC to perform group + o OPT8: Optionally, specify policies for the KDC to perform group rekeying after receiving a Key Renewal Request (see Section 4.4). - * OPT9: Optionally, specify the functionalities implemented at the + o OPT9: Optionally, specify the functionalities implemented at the 'control_path' resource hosted at the Client, including message exchange encoding and other details (see Section 4.1.2.1). - * OPT10: Optionally, specify how the identifier of the sender's + o OPT10: Optionally, specify how the identifier of the sender's public key is included in the group request (see Section 4.6). Appendix B. Document Updates RFC EDITOR: PLEASE REMOVE THIS SECTION. B.1. Version -04 to -05 - * Updated uppercase/lowercase URI segments for KDC resources. + o Updated uppercase/lowercase URI segments for KDC resources. - * Supporting single Access Token for multiple groups/topics. + o Supporting single Access Token for multiple groups/topics. - * Added 'control_path' parameter in the Joining Request. + o Added 'control_path' parameter in the Joining Request. - * Added 'peer_roles' parameter to support legal requesters/ + o Added 'peer_roles' parameter to support legal requesters/ responders. - * Clarification on stopping using owned keying material. + o Clarification on stopping using owned keying material. - * Clarification on different reasons for processing failures, + o Clarification on different reasons for processing failures, related policies, and requirement OPT4. - * Added a KDC sub-resource for group members to upload a new public + o Added a KDC sub-resource for group members to upload a new public key. - * Possible group rekeying following an individual Key Renewal + o Possible group rekeying following an individual Key Renewal Request. - * Clarified meaning of requirement REQ3; added requirement OPT8. + o Clarified meaning of requirement REQ3; added requirement OPT8. - * Editorial improvements. + o Editorial improvements. B.2. Version -03 to -04 - * Revised RESTful interface, as to methods and parameters. + o Revised RESTful interface, as to methods and parameters. - * Extended processing of joining request, as to check/retrieval of + o Extended processing of joining request, as to check/retrieval of public keys. - * Revised and extended profile requirements. + o Revised and extended profile requirements. - * Clarified specific usage of parameters related to signature + o Clarified specific usage of parameters related to signature algorithms/keys. - * Included general content previously in draft-ietf-ace-key- + o Included general content previously in draft-ietf-ace-key- groupcomm-oscore - * Registration of media type and content format application/ace- + o Registration of media type and content format application/ace- group+cbor - * Editorial improvements. + o Editorial improvements. B.3. Version -02 to -03 - * Exchange of information on the countersignature algorithm and + o Exchange of information on the countersignature algorithm and related parameters, during the Token POST (Section 3.3). - * Restructured KDC interface, with new possible operations + o Restructured KDC interface, with new possible operations (Section 4). - * Client PoP signature for the Joining Request upon joining + o Client PoP signature for the Joining Request upon joining (Section 4.1.2.1). - * Revised text on group member removal (Section 5). + o Revised text on group member removal (Section 5). - * Added more profile requirements (Appendix A). + o Added more profile requirements (Appendix A). B.4. Version -01 to -02 - * Editorial fixes. + o Editorial fixes. - * Distinction between transport profile and application profile + o Distinction between transport profile and application profile (Section 1.1). - * New parameters 'sign_info' and 'pub_key_enc' to negotiate + o New parameters 'sign_info' and 'pub_key_enc' to negotiate parameter values for signature algorithm and signature keys (Section 3.3). - * New parameter 'type' to distinguish different Key Distribution + o New parameter 'type' to distinguish different Key Distribution Request messages (Section 4.1). - * New parameter 'client_cred_verify' in the Key Distribution Request + o New parameter 'client_cred_verify' in the Key Distribution Request to convey a Client signature (Section 4.1). - * Encoding of 'pub_keys_repos' (Section 4.1). + o Encoding of 'pub_keys_repos' (Section 4.1). - * Encoding of 'mgt_key_material' (Section 4.1). + o Encoding of 'mgt_key_material' (Section 4.1). - * Improved description on retrieval of new or updated keying + o Improved description on retrieval of new or updated keying material (Section 6). - * Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). + o Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). - * Extended security considerations (Sections 10.1 and 10.2). + o Extended security considerations (Sections 10.1 and 10.2). - * New "ACE Public Key Encoding" IANA Registry (Section 11.2). + o New "ACE Public Key Encoding" IANA Registry (Section 11.2). - * New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), + o New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), populated with the entries in Section 8. - * New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), + o New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), populated with the values in Section 9. - * New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated + o New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated with two entries "Sequence Number Synchronization Method" and "Key Update Check Interval" (Section 4.2). - * Improved list of requirements for application profiles + o Improved list of requirements for application profiles (Appendix A). B.5. Version -00 to -01 - * Changed name of 'req_aud' to 'audience' in the Authorization + o Changed name of 'req_aud' to 'audience' in the Authorization Request (Section 3.1). - * Defined error handling on the KDC (Sections 4.2 and 6.2). + o Defined error handling on the KDC (Sections 4.2 and 6.2). - * Updated format of the Key Distribution Response as a whole + o Updated format of the Key Distribution Response as a whole (Section 4.2). - * Generalized format of 'pub_keys' in the Key Distribution Response + o Generalized format of 'pub_keys' in the Key Distribution Response (Section 4.2). - * Defined format for the message to request leaving the group + o Defined format for the message to request leaving the group (Section 5.2). - * Renewal of individual keying material and methods for group + o Renewal of individual keying material and methods for group rekeying initiated by the KDC (Section 6). - * CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). + o CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). - * Added section on parameter identifiers and their CBOR keys + o Added section on parameter identifiers and their CBOR keys (Section 8). - * Added request types for requests to a Join Response (Section 9). + o Added request types for requests to a Join Response (Section 9). - * Extended security considerations (Section 10). + o Extended security considerations (Section 10). - * New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm + o New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence Number Synchronization Method Registry" (Section 11). - * Added appendix about requirements for application profiles of ACE + o Added appendix about requirements for application profiles of ACE on group communication (Appendix A). Acknowledgments The following individuals were helpful in shaping this document: Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok. The work on this document has been partly supported by VINNOVA and @@ -2579,25 +2628,25 @@ The following individuals were helpful in shaping this document: Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact Initiative ACTIVE. Authors' Addresses + Francesca Palombini Ericsson AB Torshamnsgatan 23 - SE-16440 Stockholm Kista + Kista SE-16440 Stockholm Sweden Email: francesca.palombini@ericsson.com - Marco Tiloca RISE AB Isafjordsgatan 22 - SE-16440 Stockholm Kista + Kista SE-16440 Stockholm Sweden Email: marco.tiloca@ri.se