< draft-ietf-ace-key-groupcomm-oscore-01.txt   draft-ietf-ace-key-groupcomm-oscore-02.txt >
ACE Working Group M. Tiloca ACE Working Group M. Tiloca
Internet-Draft RISE AB Internet-Draft RISE AB
Intended status: Standards Track J. Park Intended status: Standards Track J. Park
Expires: September 9, 2019 Universitaet Duisburg-Essen Expires: January 6, 2020 Universitaet Duisburg-Essen
F. Palombini F. Palombini
Ericsson AB Ericsson AB
March 08, 2019 July 05, 2019
Key Management for OSCORE Groups in ACE Key Management for OSCORE Groups in ACE
draft-ietf-ace-key-groupcomm-oscore-01 draft-ietf-ace-key-groupcomm-oscore-02
Abstract Abstract
This document describes a method to request and provision keying This document describes a method to request and provision keying
material in group communication scenarios where communications are material in group communication scenarios where the group
based on CoAP and secured with Object Security for Constrained communication is based on CoAP and secured with Object Security for
RESTful Environments (OSCORE). The proposed method delegates the Constrained RESTful Environments (OSCORE). The proposed method
authentication and authorization of new client nodes that join an delegates the authentication and authorization of new client nodes
OSCORE group through a Group Manager server. This approach builds on that join an OSCORE group through a Group Manager server. This
the ACE framework for Authentication and Authorization, and leverages approach builds on the ACE framework for Authentication and
protocol-specific profiles of ACE to achieve communication security, Authorization, and leverages protocol-specific transport profiles of
proof-of-possession and server authentication. ACE to achieve communication security, proof-of-possession and server
authentication.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2019. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Relation to Other Documents . . . . . . . . . . . . . . . 5 1.2. Relation to Other Documents . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Overview of the Join Process . . . . . . . . . . . . . . 7 2.1. Overview of the Join Process . . . . . . . . . . . . . . 7
2.2. Overview of the Group Rekeying Process . . . . . . . . . 8 2.2. Overview of the Group Rekeying Process . . . . . . . . . 8
3. Joining Node to Authorization Server . . . . . . . . . . . . 8 3. Joining Node to Authorization Server . . . . . . . . . . . . 9
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 8 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 9
3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 3.2. Authorization Response . . . . . . . . . . . . . . . . . 10
4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 10 4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 11
4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. 'key info' Parameter . . . . . . . . . . . . . . . . 11 4.2. Join Request . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Join Request . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Join Response . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Join Response . . . . . . . . . . . . . . . . . . . . . . 12 5. Leaving of a Group Member . . . . . . . . . . . . . . . . . . 17
5. Leaving of a Group Member . . . . . . . . . . . . . . . . . . 14 6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 18
6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 15 7. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 20
7. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 22
9.1. ACE Authorization Server Request Creation Hints Registry 17 9.2. OSCORE Security Context Parameters Registry . . . . . . . 23
9.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 17 9.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 24
9.3. OSCORE Security Context Parameters Registry . . . . . . . 18 9.4. Sequence Number Synchronization Method Registry . . . . . 24
9.4. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 18 9.5. ACE Public Key Encoding Registry . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Document Updates . . . . . . . . . . . . . . . . . . 20 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 27
A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 21 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 B.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 B.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
[I-D.ietf-core-object-security] is a method for application-layer [I-D.ietf-core-object-security] is a method for application-layer
protection of the Constrained Application Protocol (CoAP) [RFC7252], protection of the Constrained Application Protocol (CoAP) [RFC7252],
using CBOR Object Signing and Encryption (COSE) [RFC8152] and using CBOR Object Signing and Encryption (COSE) [RFC8152] and
enabling end-to-end security of CoAP payload and options. enabling end-to-end security of CoAP payload and options.
As described in [I-D.ietf-core-oscore-groupcomm], OSCORE may be used As described in [I-D.ietf-core-oscore-groupcomm], OSCORE may be used
to protect CoAP group communication over IP multicast [RFC7390]. to protect CoAP group communication over IP multicast
This relies on a Group Manager, which is responsible for managing an [RFC7390][I-D.dijk-core-groupcomm-bis]. This relies on a Group
OSCORE group, where members exchange CoAP messages secured with Manager, which is responsible for managing an OSCORE group, where
OSCORE. The Group Manager can be responsible for multiple groups, members exchange CoAP messages secured with OSCORE. The Group
coordinates the join process of new group members, and is entrusted Manager can be responsible for multiple groups, coordinates the join
with the distribution and renewal of group keying material. process of new group members, and is entrusted with the distribution
and renewal of group keying material.
This specification builds on the ACE framework for Authentication and This specification builds on the ACE framework for Authentication and
Authorization [I-D.ietf-ace-oauth-authz] and defines a method to: Authorization [I-D.ietf-ace-oauth-authz] and defines a method to:
o Authorize a node to join an OSCORE group, and provide it with the o Authorize a node to join an OSCORE group, and provide it with the
group keying material to communicate with other group members. group keying material to communicate with other group members.
o Provide updated keying material to group members upon request. o Provide updated keying material to group members upon request.
o Renew the group keying material and distribute it to the OSCORE o Renew the group keying material and distribute it to the OSCORE
skipping to change at page 3, line 36 skipping to change at page 3, line 45
Access Token, which is bound to a proof-of-possession key and Access Token, which is bound to a proof-of-possession key and
authorizes the client to access a specific join resource at the Group authorizes the client to access a specific join resource at the Group
Manager. Manager.
Messages exchanged among the participants follow the formats defined Messages exchanged among the participants follow the formats defined
in [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying in [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying
material in group communication scenarios. material in group communication scenarios.
In order to achieve communication security, proof-of-possession and In order to achieve communication security, proof-of-possession and
server authentication, the client and the Group Manager leverage server authentication, the client and the Group Manager leverage
protocol-specific profiles of ACE. These include also possible protocol-specific transport profiles of ACE. These include also
forthcoming profiles that comply with the requirements in Appendix C possible forthcoming transport profiles that comply with the
of [I-D.ietf-ace-oauth-authz]. requirements in Appendix C of [I-D.ietf-ace-oauth-authz].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
described in the ACE framework for authentication and authorization described in the ACE framework for authentication and authorization
[I-D.ietf-ace-oauth-authz]. The terminology for entities in the [I-D.ietf-ace-oauth-authz]. The terminology for entities in the
considered architecture is defined in OAuth 2.0 [RFC6749]. In considered architecture is defined in OAuth 2.0 [RFC6749]. In
particular, this includes Client (C), Resource Server (RS), and particular, this includes Client (C), Resource Server (RS), and
Authorization Server (AS). Authorization Server (AS).
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
related to the CoAP protocol described in [RFC7252][RFC7390]. Note related to the CoAP protocol described in
that, unless otherwise indicated, the term "endpoint" is used here [RFC7252][RFC7390][I-D.dijk-core-groupcomm-bis]. Note that, unless
following its OAuth definition, aimed at denoting resources such as otherwise indicated, the term "endpoint" is used here following its
/token and /introspect at the AS and /authz-info at the RS. This OAuth definition, aimed at denoting resources such as /token and
document does not use the CoAP definition of "endpoint", which is "An /introspect at the AS and /authz-info at the RS. This document does
entity participating in the CoAP protocol". not use the CoAP definition of "endpoint", which is "An entity
participating in the CoAP protocol".
Readers are expected to be familiar with the terms and concepts for Readers are expected to be familiar with the terms and concepts for
protection and processing of CoAP messages through OSCORE protection and processing of CoAP messages through OSCORE
[I-D.ietf-core-object-security] also in group communication scenarios [I-D.ietf-core-object-security] also in group communication scenarios
[I-D.ietf-core-oscore-groupcomm]. These include the concept of Group [I-D.ietf-core-oscore-groupcomm]. These include the concept of Group
Manager, as the entity responsible for a set of groups where Manager, as the entity responsible for a set of groups where
communications are secured with OSCORE. In this specification, the communications are secured with OSCORE. In this specification, the
Group Manager acts as Resource Server. Group Manager acts as Resource Server.
This document refers also to the following terminology. This document refers also to the following terminology.
o Joining node: a network node intending to join an OSCORE group, o Joining node: a network node intending to join an OSCORE group,
where communication is based on CoAP [RFC7390] and secured with where communication is based on CoAP
OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. [RFC7390][I-D.dijk-core-groupcomm-bis] and secured with OSCORE as
described in [I-D.ietf-core-oscore-groupcomm].
o Join process: the process through which a joining node becomes a o Join process: the process through which a joining node becomes a
member of an OSCORE group. The join process is enforced and member of an OSCORE group. The join process is enforced and
assisted by the Group Manager responsible for that group. assisted by the Group Manager responsible for that group.
o Join resource: a resource hosted by the Group Manager, associated o Join resource: a resource hosted by the Group Manager, associated
to an OSCORE group under that Group Manager. A join resource is to an OSCORE group under that Group Manager. A join resource is
identifiable with the Group Identifier (Gid) of the respective identifiable with the Group Identifier (Gid) of the respective
group. A joining node accesses a join resource to start the join group. A joining node accesses a join resource to start the join
process and become a member of that group. process and become a member of that group. The URI of a join
resource is fixed.
o Join endpoint: an endpoint at the Group Manager associated to a o Join endpoint: an endpoint at the Group Manager associated to a
join resource. join resource.
o Requester: member of an OSCORE group that sends request messages o Requester: member of an OSCORE group that sends request messages
to other members of the group. to other members of the group.
o Listener: member of an OSCORE group that receives request messages o Responder: member of an OSCORE group that receives request
from other members of the group. A listener may reply back, by messages from other members of the group. A responder may reply
sending a response message to the requester which has sent the back, by sending a response message to the requester which has
request message. sent the request message.
o Pure listener: member of a group that is configured as listener o Monitor: member of a group that is configured as responder and
and never replies back to requesters after receiving request never replies back to requesters after receiving request messages.
messages. This corresponds to the term "silent server" used in This corresponds to the term "silent server" used in
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
o Group rekeying process: the process through which the Group o Group rekeying process: the process through which the Group
Manager renews the security parameters and group keying material, Manager renews the security parameters and group keying material,
and (re-)distributes them to the OSCORE group members. and (re-)distributes them to the OSCORE group members.
1.2. Relation to Other Documents 1.2. Relation to Other Documents
Figure 1 overviews the main documents related to this specification. Figure 1 overviews the main documents related to this specification.
Arrows and asterisk-arrows denote normative references and Arrows and asterisk-arrows denote normative references and
skipping to change at page 5, line 42 skipping to change at page 6, line 30
v v v * * v v v v v * * v v
CoRE CoRE OSCORE -------------> OSCORE CoRE CoRE OSCORE -------------> OSCORE
Pubsub Groupcomm <*** Groupcomm <************* [[WG]] Pubsub Groupcomm <*** Groupcomm <************* [[WG]]
[[WG]] [[RFC7390]] [[WG]] [[WG]] [[RFC7390]] [[WG]]
Figure 1: Related Documents Figure 1: Related Documents
2. Protocol Overview 2. Protocol Overview
Group communication for CoAP over IP multicast has been enabled in Group communication for CoAP over IP multicast has been enabled in
[RFC7390] and can be secured with Object Security for Constrained [RFC7390][I-D.dijk-core-groupcomm-bis] and can be secured with Object
RESTful Environments (OSCORE) [I-D.ietf-core-object-security] as Security for Constrained RESTful Environments (OSCORE)
described in [I-D.ietf-core-oscore-groupcomm]. A network node joins [I-D.ietf-core-object-security] as described in
an OSCORE group by interacting with the responsible Group Manager. [I-D.ietf-core-oscore-groupcomm]. A network node joins an OSCORE
Once registered in the group, the new node can securely exchange group by interacting with the responsible Group Manager. Once
messages with other group members. registered in the group, the new node can securely exchange messages
with other group members.
This specification describes how to use the ACE framework for This specification describes how to use the ACE framework for
authentication and authorization [I-D.ietf-ace-oauth-authz] to: authentication and authorization [I-D.ietf-ace-oauth-authz] to:
o Enable a node to join an OSCORE group through the Group Manager o Enable a node to join an OSCORE group through the Group Manager
and receive the security parameters and keying material to and receive the security parameters and keying material to
communicate with the other members of the gorup. communicate with the other members of the gorup.
o Enable members of OSCORE groups to retrieve updated group keying o Enable members of OSCORE groups to retrieve updated group keying
material from the Group Manager. material from the Group Manager.
skipping to change at page 6, line 44 skipping to change at page 7, line 33
Group Managers can be associated to the same AS. The AS MAY Group Managers can be associated to the same AS. The AS MAY
release Access Tokens for other purposes than joining OSCORE release Access Tokens for other purposes than joining OSCORE
groups under registered Group Managers. For example, the AS may groups under registered Group Managers. For example, the AS may
also release Access Tokens for accessing resources hosted by also release Access Tokens for accessing resources hosted by
members of OSCORE groups. members of OSCORE groups.
All communications between the involved entities rely on the CoAP All communications between the involved entities rely on the CoAP
protocol and MUST be secured. protocol and MUST be secured.
In particular, communications between the joining node and the Group In particular, communications between the joining node and the Group
Manager leverage protocol-specific profiles of ACE to achieve Manager leverage protocol-specific transport profiles of ACE to
communication security, proof-of-possession and server achieve communication security, proof-of-possession and server
authentication. To this end, the AS must signal the specific profile authentication. To this end, the AS must signal the specific
to use, consistently with requirements and assumptions defined in the transport profile to use, consistently with requirements and
ACE framework [I-D.ietf-ace-oauth-authz]. assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz].
With reference to the AS, communications between the joining node and With reference to the AS, communications between the joining node and
the AS (/token endpoint) as well as between the Group Manager and the the AS (/token endpoint) as well as between the Group Manager and the
AS (/introspect endpoint) can be secured by different means, for AS (/introspect endpoint) can be secured by different means, for
instance using DTLS [RFC6347] or OSCORE instance using DTLS [RFC6347] or OSCORE
[I-D.ietf-core-object-security]. Further details on how the AS [I-D.ietf-core-object-security]. Further details on how the AS
secures communications (with the joining node and the Group Manager) secures communications (with the joining node and the Group Manager)
depend on the specifically used profile of ACE, and are out of the depend on the specifically used transport profile of ACE, and are out
scope of this specification. of the scope of this specification.
2.1. Overview of the Join Process 2.1. Overview of the Join Process
A node performs the following steps in order to join an OSCORE group. A node performs the following steps in order to join an OSCORE group.
Messages exchanged among the participants follow the formats defined Messages exchanged among the participants follow the formats defined
in [I-D.ietf-ace-key-groupcomm], and are further specified in in [I-D.ietf-ace-key-groupcomm], and are further specified in
Section 3 and Section 4 of this document. The Group Manager acts as Section 3 and Section 4 of this document. The Group Manager acts as
the Key Distribution Center (KDC) defined in the Key Distribution Center (KDC) defined in
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
skipping to change at page 9, line 14 skipping to change at page 9, line 50
* in the first element, either the Group Identifier (Gid) of the * in the first element, either the Group Identifier (Gid) of the
group to join under the Group Manager, or a value from which group to join under the Group Manager, or a value from which
the Group Manager can derive the Gid of the group to join. It the Group Manager can derive the Gid of the group to join. It
is up to the application to define how the Group Manager is up to the application to define how the Group Manager
possibly performs the derivation of the full Gid. Appendix C of possibly performs the derivation of the full Gid. Appendix C of
[I-D.ietf-core-oscore-groupcomm] provides an example of [I-D.ietf-core-oscore-groupcomm] provides an example of
structured Gid, composed of a fixed part, namely Group Prefix, structured Gid, composed of a fixed part, namely Group Prefix,
and a variable part, namely Group Epoch. and a variable part, namely Group Epoch.
* in the second element, the role(s) that the joining node * in the second element, the role (encoded as a text string) or
intends to have in the group it intends to join. Possible CBOR array of roles that the joining node intends to have in
values are: "requester"; "listener"; and "pure listener". the group it intends to join. Accepted values of roles are:
Possible combinations are: ["requester" , "listener"];
["requester" , "pure listener"]. "requester", "responder", and "monitor". Possible combinations
are: ["requester" , "responder"]; ["requester" , "monitor"].
o The 'audience' parameter MUST be present and is set to the o The 'audience' parameter MUST be present and is set to the
identifier of the Group Manager. identifier of the Group Manager.
3.2. Authorization Response 3.2. Authorization Response
The AS is responsible for authorizing the joining node to join The AS is responsible for authorizing the joining node to join
specific OSCORE groups, according to join policies enforced on behalf specific OSCORE groups, according to join policies enforced on behalf
of the respective Group Manager. of the respective Group Manager.
skipping to change at page 9, line 44 skipping to change at page 10, line 32
Authorization Response message defined in Section 3.2 of Authorization Response message defined in Section 3.2 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
The 'exp' parameter MUST be present. Other means for the AS to The 'exp' parameter MUST be present. Other means for the AS to
specify the lifetime of Access Tokens are out of the scope of this specify the lifetime of Access Tokens are out of the scope of this
specification. specification.
The AS must include the 'scope' parameter in the response when the The AS must include the 'scope' parameter in the response when the
value included in the Access Token differs from the one specified by value included in the Access Token differs from the one specified by
the joining node in the request. In such a case, the second element the joining node in the request. In such a case, the second element
of 'scope' MUST be present and includes the role(s) that the joining of 'scope' MUST be present and includes the role or CBOR array of
node is actually authorized to take in the group, encoded as roles that the joining node is actually authorized to take in the
specified in Section 3.1 of this document. group, encoded as specified in Section 3.1 of this document.
Also, the 'profile' parameter indicates the specific profile of ACE Also, the 'profile' parameter indicates the specific transport
to use for securing communications between the joining node and the profile of ACE to use for securing communications between the joining
Group Manager (see Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]). node and the Group Manager (see Section 5.6.4.3 of
[I-D.ietf-ace-oauth-authz]).
In particular, if symmetric keys are used, the AS generates a proof- In particular, if symmetric keys are used, the AS generates a proof-
of-possession key, binds it to the Access Token, and provides it to of-possession key, binds it to the Access Token, and provides it to
the joining node in the 'cnf' parameter of the Access Token response. the joining node in the 'cnf' parameter of the Access Token response.
Instead, if asymmetric keys are used, the joining node provides its Instead, if asymmetric keys are used, the joining node provides its
own public key to the AS in the 'req_cnf' parameter of the Access own public key to the AS in the 'req_cnf' parameter of the Access
Token request. Then, the AS uses it as proof-of-possession key bound Token request. Then, the AS uses it as proof-of-possession key bound
to the Access Token, and provides the joining node with the Group to the Access Token, and provides the joining node with the Group
Manager's public key in the 'rs_cnf' parameter of the Access Token Manager's public key in the 'rs_cnf' parameter of the Access Token
response. response.
skipping to change at page 10, line 27 skipping to change at page 11, line 17
The following subsections describe the interactions between the The following subsections describe the interactions between the
joining node and the Group Manager, i.e. the Access Token post and joining node and the Group Manager, i.e. the Access Token post and
the Request-Response exchange to join the OSCORE group. the Request-Response exchange to join the OSCORE group.
4.1. Token Post 4.1. Token Post
The joining node posts the Access Token to the /authz-info endpoint The joining node posts the Access Token to the /authz-info endpoint
at the Group Manager, according to the Token post defined in at the Group Manager, according to the Token post defined in
Section 3.3 of [I-D.ietf-ace-key-groupcomm]. Section 3.3 of [I-D.ietf-ace-key-groupcomm].
If the joining node is not aware of the countersignature algorithm At this point in time, the joining node might not have all the
and related parameters used in the OSCORE group, it may want to get necessary information concerning the public keys in the OSCORE group,
that information from the Group Manager. In such a case, the CoAP as well as concerning the algorithm and related parameters for
POST request uses the Content-Format "application/ace+cbor" defined computing countersignatures in the OSCORE group. In such a case, the
in Section 8.14 of [I-D.ietf-ace-oauth-authz], and includes also the joining node MAY use the 'sign_info' and 'pub_key_enc' parameters
parameter 'key info' defined in Section 4.1.1 and registered in defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm] to ask for
Section 9.1, encoding the CBOR simple value Null. Alternatively, the such information.
joining node may retrieve that information by other means, e.g. by
using the approach described in [I-D.tiloca-core-oscore-discovery]. Alternatively, the joining node may retrieve this information by
other means, e.g. by using the approach described in
[I-D.tiloca-core-oscore-discovery].
If the Access Token is valid, the Group Manager responds to the POST If the Access Token is valid, the Group Manager responds to the POST
request with a 2.01 (Created) response, according to what is request with a 2.01 (Created) response, according to what is
specified in the signalled profile of ACE. specified in the signalled transport profile of ACE. The Group
Manager MUST use the Content-Format "application/ace+cbor" defined in
Section 8.14 of [I-D.ietf-ace-oauth-authz].
The payload of the 2.01 (Created) response MAY be a CBOR map The payload of the 2.01 (Created) response is a CBOR map, which MUST
including a 'key info' parameter, which MUST be present if the POST include the 'cnonce' parameter defined in section 5.1.2 of
request included the 'key info' parameter with value Null. If [I-D.ietf-ace-oauth-authz], and MAY include the 'sign_info' parameter
present, the 'key info' parameter of the 2.01 (Created) response is a as well as the 'pub_key_enc' parameter.
CBOR array formatted as follows:
o The first element is an integer or a text string, indicating the The 'cnonce' parameter includes a nonce N generated by the Group
counter signature algorithm used in the OSCORE group. This Manager. The joining node may use this nonce in order to prove the
parameter takes values from Tables 5 and 6 of [RFC8152]. possession of its own private key, upon joining the group (see
Section 4.2).
o The second element indicates the parameters of the counter If present in the response:
signature algorithm. Its structure depends on the value of the
first element, and is defined in the Counter Signature Parameters o 'sign_alg', i.e. the first element of the 'sign_info' parameter,
takes value from Tables 5 and 6 of [RFC8152].
o 'sign_parameters', i.e. the second element of the 'sign_info'
parameter, takes values from the "Counter Signature Parameters"
Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]). Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]).
This parameter MUST be omitted if there are no parameters for that
algorithm value.
The CDDL notation of the 'key info' parameter is given below. Its structure depends on the value of 'sign_alg'. If no
parameters of the counter signature algorithm are specified,
'sign_parameters' MUST be encoding the CBOR simple value Null.
key_info = [ o 'sign_key_parameters', i.e. the third element of the 'sign_info'
sign_alg : int / tstr, parameter, takes values from the "Counter Signature Key
? sign_parameters : any Parameters" Registry (see Section 9.2 of
] [I-D.ietf-core-oscore-groupcomm]). Its structure depends on the
value of 'sign_alg'. If no parameters of the key used with the
counter signature algorithm are specified, 'sign_key_parameters'
MUST be encoding the CBOR simple value Null.
Finally, the joining node establishes a secure channel with the Group o 'pub_key_enc' takes value from Figure 2, as a public key encoding
Manager, according to what is specified in the Access Token response in the "ACE Public Key Encoding" Registry (see Section 11.2 of
and the signalled profile of ACE. [I-D.ietf-ace-key-groupcomm]).
4.1.1. 'key info' Parameter +----------+-------+--------------------------------+-------------+
| Name | Value | Description | Reference |
+----------+-------+--------------------------------+-------------+
| COSE_Key | 1 | Public key encoded as COSE Key | {{RFC8152}} |
+----------+-------+--------------------------------+-------------+
The 'key info' parameter is an OPTIONAL parameter of the AS Request Figure 2: ACE Public Key Encoding Values
Creation Hints message defined in Section 5.1.2. of
[I-D.ietf-ace-oauth-authz]. This parameter contains information Note that the CBOR map specified as payload of the 2.01 (Created)
about the key to be used in the security association between the response may include further parameters, e.g. according to the
Client and the RS. Its format is application specific. signalled transport profile of ACE.
Finally, the joining node establishes a secure channel with the Group
Manager, according to what is specified in the Access Token response
and the signalled transport profile of ACE.
4.2. Join Request 4.2. Join Request
Once a secure communication channel with the Group Manager has been Once a secure communication channel with the Group Manager has been
established, the joining node requests to join the OSCORE group, by established, the joining node requests to join the OSCORE group, by
accessing the related join resource at the Group Manager. accessing the related join resource at the Group Manager.
In particular, the joining node sends to the Group Manager a In particular, the joining node sends to the Group Manager a
confirmable CoAP request, using the method POST and targeting the confirmable CoAP request, using the method POST and targeting the
join endpoint associated to that group. This join request follows join endpoint associated to that group. This Join Request follows
the format and processing of the Key Distribution Request message the format and processing of the Key Distribution Request message
defined in Section 4.1 of [I-D.ietf-ace-key-groupcomm]. In defined in Section 4.1 of [I-D.ietf-ace-key-groupcomm]. In
particular: particular:
o The 'type' parameter is set to 1 ("key distribution").
o The 'get_pub_keys' parameter is present only if the joining node o The 'get_pub_keys' parameter is present only if the joining node
wants to retrieve the public keys of the group members from the wants to retrieve the public keys of the group members from the
Group Manager during the join process (see Section 6). Otherwise, Group Manager during the join process (see Section 6). Otherwise,
this parameter MUST NOT be present. this parameter MUST NOT be present.
o The 'client_cred' parameter, if present, includes the public key o The 'client_cred' parameter, if present, includes the public key
of the joining node. In case the joining node knows the of the joining node. In case the joining node knows the encoding
of public keys in the OSCORE group, as well as the
countersignature algorithm and possible associated parameters used countersignature algorithm and possible associated parameters used
in the OSCORE group, the included public key MUST be in a in the OSCORE group, the included public key MUST be in a
consistent format. This parameter MAY be omitted if: i) the consistent format. This parameter MAY be omitted if: i) the
joining node is asking to access the group exclusively as pure joining node is asking to access the group exclusively as monitor;
listener; or ii) the Group Manager already acquired this or ii) the Group Manager already acquired this information, for
information, for instance during a previous join process. In any instance during a past join process. In any other case, this
other case, this parameter MUST be present. parameter MUST be present.
Furthermore, the CBOR map specified as payload of the Join Request
MAY also include the following additional parameter, which MUST be
present if the 'client_cred' parameter is present.
o The 'client_cred_verify' parameter, which is encoded as a CBOR
byte string and contains a signature computed by the joining node,
in order to prove possession of its own private key. The
signature is computed over the nonce N received in the 2.01
(Created) response to the Token POST (see Section 4.1). In
particular, the joining node MUST use the COSE_CounterSignature0
object [RFC8152], with the Sig_structure containing the nonce N as
payload; and an empty external_aad. The joining node computes the
signature by using the same private key and countersignature
algorithm it intends to use for signing messages in the OSCORE
group.
4.3. Join Response 4.3. Join Response
The Group Manager processes the request according to The Group Manager processes the Join Request according to
[I-D.ietf-ace-oauth-authz] and Section 4.2 of [I-D.ietf-ace-oauth-authz] and Section 4.2 of
[I-D.ietf-ace-key-groupcomm]. If this yields a positive outcome, the [I-D.ietf-ace-key-groupcomm]. Also, the Group Manager MUST return a
Group Manager performs the following check. In case the Join Request 4.00 (Bad Request) response in case the Join Request includes the
included the 'client_cred' parameter, the Group Manager checks that 'client_cred' parameter but does not include the 'client_cred_verify'
the public key of the joining node is consistent with the counter parameter.
signature algorithm and possible associated parameters used in the
OSCORE group.
If the public key of the joining node does not have an accepted If the request processing yields a positive outcome, the Group
format, the Group Manager MUST reply to the joining node with a 2.01 Manager performs the further following checks.
(Created) response. The payload of this response is a CBOR map,
which includes a 'key info' parameter formatted as in the Token POST
response in Section 4.1. Upon receiving this response, the joining
node SHOULD send a new Join Request to the Group Manager, with the
'client_cred' parameter including its own public key in a format
consistent with the countersignature algorithm and possible
associated parameters indicated by the Group Manager.
Otherwise, the Group Manager updates the group membership by o In case the Join Request includes the 'client_cred' parameter, the
registering the joining node as a new member of the OSCORE group. Group Manager checks that the public key of the joining node has
an accepted format. That is, the public key has to be encoded as
expected in the OSCORE group, and has to be consistent with the
counter signature algorithm and possible associated parameters
used in the OSCORE group. The join process fails if the public
key of the joining node does not have an accepted format.
o In case the Join Request does not include the 'client_cred'
parameter, the Group Manager checks whether it is storing a public
key for the joining node, which is consistent with the encoding,
counter signature algorithm and possible associated parameters
used in the OSCORE group. The join process fails if the Group
Manager either: i) does not store a public key with an accepted
format for the joining node; or ii) stores multiple public keys
with an accepted format for the joining node.
o In case the Join Request includes the 'client_cred_verify'
parameter, the Group Manager verifies the signature contained in
the parameter. To this end, it considers: i) as signed value, the
nonce N previously provided in the 2.01 (Created) response to the
Token POST (see Section 4.1); ii) the countersignature algorithm
used in the OSCORE group; and iii) the public key of the joining
node, either retrieved from the 'client_cred' parameter, or as
stored from a past join process. The join process fails if the
Group Manager does not successfully verify the signature.
If the join process has failed, the Group Manager MUST reply to the
joining node with a 4.00 (Bad Request) response. The payload of this
response is a CBOR map, which includes a 'sign_info' parameter and a
'pub_key_enc' parameter, formatted as in the Token POST response in
Section 4.1.
Upon receiving this response, the joining node SHOULD send a new Join
Request to the Group Manager, which contains:
o The 'client_cred' parameter, including a public key in a format
consistent with the encoding, countersignature algorithm and
possible associated parameters indicated by the Group Manager.
o The 'client_cred_verify' parameter, including a signature computed
as described in Section 4.2, by using the public key indicated in
the current 'client_cred' parameter, with the countersignature
algorithm and possible associated parameters indicated by the
Group Manager.
Otherwise, in case of success, the Group Manager updates the group
membership by registering the joining node as a new member of the
OSCORE group.
Then, the Group Manager replies to the joining node providing the Then, the Group Manager replies to the joining node providing the
updated security parameters and keying meterial necessary to updated security parameters and keying meterial necessary to
participate in the group communication. This join response follows participate in the group communication. This Join Response follows
the format and processing of the Key Distribution success Response the format and processing of the Key Distribution success Response
message defined in Section 4.2 of [I-D.ietf-ace-key-groupcomm]. In message defined in Section 4.2 of [I-D.ietf-ace-key-groupcomm]. In
particular: particular:
o The 'kty' parameter identifies a key of type o The 'kty' parameter identifies a key of type
"Group_OSCORE_Security_Context object", defined in Section 9.2 of "Group_OSCORE_Security_Context object", defined in Section 9.1 of
this specification. this specification.
o The 'key' parameter includes what the joining node needs in order o The 'key' parameter includes what the joining node needs in order
to set up the OSCORE Security Context as per Section 2 of to set up the OSCORE Security Context as per Section 2 of
[I-D.ietf-core-oscore-groupcomm]. This parameter includes a [I-D.ietf-core-oscore-groupcomm]. This parameter has as value a
Group_OSCORE_Security_Context object, which is defined in this Group_OSCORE_Security_Context object, which is defined in this
specification and extends the OSCORE_Security_Context object specification and extends the OSCORE_Security_Context object
encoded in CBOR as defined in Section 3.2.1 of encoded in CBOR as defined in Section 3.2.1 of
[I-D.ietf-ace-oscore-profile]. In particular, it contains the [I-D.ietf-ace-oscore-profile]. In particular, it contains the
additional parameters 'cs_alg' and 'cs_params' defined in additional parameters 'cs_alg', 'cs_params', 'cs_key_params' and
Section 9.3 of this specification. More specifically, the 'key' 'cs_key_enc' defined in Section 9.2 of this specification. More
parameter is composed as follows. specifically, the 'key' parameter is composed as follows.
* The 'ms' parameter MUST be present and includes the OSCORE * The 'ms' parameter MUST be present and includes the OSCORE
Master Secret value. Master Secret value.
* The 'clientId' parameter, if present, has as value the OSCORE * The 'clientId' parameter, if present, has as value the OSCORE
Sender ID assigned to the joining node by the Group Manager. Sender ID assigned to the joining node by the Group Manager.
This parameter is not present if the node joins the group This parameter is not present if the node joins the group
exclusively as pure listener, according to what specified in exclusively as monitor, according to what specified in the
the Access Token (see Section 3.2). In any other case, this Access Token (see Section 3.2). In any other case, this
parameter MUST be present. parameter MUST be present.
* The 'hkdf' parameter, if present, has as value the KDF * The 'hkdf' parameter, if present, has as value the KDF
algorithm used in the group. algorithm used in the group.
* The 'alg' parameter, if present, has as value the AEAD * The 'alg' parameter, if present, has as value the AEAD
algorithm used in the group. algorithm used in the group.
* The 'salt' parameter, if present, has as value the OSCORE * The 'salt' parameter, if present, has as value the OSCORE
Master Salt. Master Salt.
skipping to change at page 13, line 38 skipping to change at page 16, line 7
* The 'rpl' parameter, if present, specifies the OSCORE Replay * The 'rpl' parameter, if present, specifies the OSCORE Replay
Window Size and Type value. Window Size and Type value.
* The 'cs_alg' parameter MUST be present and specifies the * The 'cs_alg' parameter MUST be present and specifies the
algorithm used to countersign messages in the group. This algorithm used to countersign messages in the group. This
parameter takes values from Tables 5 and 6 of [RFC8152]. parameter takes values from Tables 5 and 6 of [RFC8152].
* The 'cs_params' parameter MAY be present and specifies the * The 'cs_params' parameter MAY be present and specifies the
additional parameters for the counter signature algorithm. additional parameters for the counter signature algorithm.
This parameter is encoded as specified in Section 2 of This parameter is a CBOR map whose content depends on the
counter signature algorithm, as specified in Section 2 and
Section 9.1 of [I-D.ietf-core-oscore-groupcomm].
* The 'cs_key_params' parameter MAY be present and specifies the
additional parameters for the key used with the counter
signature algorithm. This parameter is a CBOR map whose
content depends on the counter signature algorithm, as
specified in Section 2 and Section 9.2 of
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
* The 'cs_key_enc' parameter MAY be present and specifies the
encoding of the public keys of the group members. This
parameter is a CBOR integer, whose value is taken from
Figure 2, as a public key encoding in the "ACE Public Key
Encoding" Registry (see Section 11.2 of
[I-D.ietf-ace-key-groupcomm]). If this parameter is not
present, COSE_Key (1) MUST be assumed as default value.
o The 'profile' parameter MUST be present and has value o The 'profile' parameter MUST be present and has value
"coap_group_oscore", which is defined in Section 9.4 of this coap_group_oscore_app (TBD), which is defined in Section 9.3 of
specification. this specification.
o The 'exp' parameter MUST be present and specifies the expiration o The 'exp' parameter MUST be present and specifies the expiration
time in seconds after which the OSCORE Security Context derived time in seconds after which the OSCORE Security Context derived
from the 'key' parameter is not valid anymore. from the 'key' parameter is not valid anymore.
o The 'pub_keys' parameter is present only if the 'get_pub_keys' o The 'pub_keys' parameter is present only if the 'get_pub_keys'
parameter was present in the join request. If present, this parameter was present in the Join Request. If present, this
parameter includes the public keys of the group members that are parameter includes the public keys of the group members that are
relevant to the joining node. That is, it includes: i) the public relevant to the joining node. That is, it includes: i) the public
keys of the non-pure listeners currently in the group, in case the keys of the responders currently in the group, in case the joining
joining node is configured (also) as requester; and ii) the public node is configured (also) as requester; and ii) the public keys of
keys of the requesters currently in the group, in case the joining the requesters currently in the group, in case the joining node is
node is configured (also) as listener or pure listener. configured (also) as responder or monitor.
o The 'group_policies' parameter SHOULD be present and includes a o The 'group_policies' parameter SHOULD be present and includes a
list of parameters indicating particular policies enforced in the list of parameters indicating particular policies enforced in the
group. For instance, it can indicate the method to achieve group. For instance, its field "Sequence Number Synchronization
synchronization of sequence numbers among group members (see Method" can indicate the method to achieve synchronization of
Appendix E of [I-D.ietf-core-oscore-groupcomm]). sequence numbers among group members (see Appendix E of
[I-D.ietf-core-oscore-groupcomm]), as indicated by the
corresponding value from the "Sequence Number Synchronization
Method" Registry defined in Section 11.8 of
[I-D.ietf-ace-key-groupcomm].
Finally, the joining node uses the information received in the join Finally, the joining node uses the information received in the Join
response to set up the OSCORE Security Context, as described in Response to set up the OSCORE Security Context, as described in
Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the
joining node can exchange group messages secured with OSCORE as joining node can exchange group messages secured with OSCORE as
described in [I-D.ietf-core-oscore-groupcomm]. described in [I-D.ietf-core-oscore-groupcomm].
If the application requires backward security, the Group Manager If the application requires backward security, the Group Manager
SHALL generate updated security parameters and group keying material, SHALL generate updated security parameters and group keying material,
and provide it to all the current group members (see Section 7). and provide it to all the current group members (see Section 7).
When the OSCORE Security Context expires, as specified by the 'exp' When the OSCORE Security Context expires, as specified by the 'exp'
parameter of the join response, the node considers it invalid and to parameter of the Join Response, the node considers it invalid and to
be renewed. Then, the node retrieves updated security parameters and be renewed. Then, the node retrieves updated security parameters and
keying material, by exchanging shortened Join Request and Join keying material, by exchanging with the Group Manager a shortened
Response messages with the Group Manager, according to the approach Join Request sent to the same Join Resource with the 'type' parameter
defined in Section 6 of [I-D.ietf-ace-key-groupcomm]. Finally, the set to 3 ("update key") and a shortened Join Response message,
node uses the updated security parameters and keying material to set according to the approach defined in Section 6 of
up the new OSCORE Security Context as described in Section 2 of [I-D.ietf-ace-key-groupcomm]. Finally, the node uses the updated
security parameters and keying material to set up the new OSCORE
Security Context as described in Section 2 of
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
Furthermore, as discussed in Section 2.2 of
[I-D.ietf-core-oscore-groupcomm], the node may at some point
experience a wrap-around of its own Sender Sequence Number in the
group. When this happens, the node MUST send to the Group Manager a
shortened Join Request message to the same Join Resource, with the
'type' parameter set to 4 ("new"). Upon receiving this request
message, the Group Manager either rekeys the whole OSCORE group as
discussed in Section 7, or generates a new Sender ID for that node
and replies with a shortened Join Response message where:
o Only the parameters 'type', 'kty', 'key', 'profile' and 'exp' are
present.
o The 'clientId' parameter of the 'key' parameter specifies the new
Sender ID of the node.
5. Leaving of a Group Member 5. Leaving of a Group Member
A node may be removed from the OSCORE group, due to expired or A node may be removed from the OSCORE group, due to expired or
revoked authorization, or after its own request to the Group Manager. revoked authorization, or after its own request to the Group Manager.
If the application requires forward security, the Group Manager SHALL If the application requires forward security, the Group Manager SHALL
generate updated security parameters and group keying material, and generate updated security parameters and group keying material, and
provide it to the remaining group members (see Section 7). The provide it to the remaining group members (see Section 7). The
leaving node must not be able to acquire the new security parameters leaving node must not be able to acquire the new security parameters
and group keying material distributed after its leaving. and group keying material distributed after its leaving.
Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm]
apply here as well, considering the Group Manager acting as KDC. In apply here as well, considering the Group Manager acting as KDC. In
particular, a node requests to leave the OSCORE group as described in particular, a node requests to leave the OSCORE group as described in
Section 5.2 of [I-D.ietf-ace-key-groupcomm]. Section 5.2 of [I-D.ietf-ace-key-groupcomm], i.e. by sending to the
Group Manager a request to the same Join Resource with the 'type'
parameter set to 2 ("leave").
6. Public Keys of Joining Nodes 6. Public Keys of Joining Nodes
Source authentication of OSCORE messages exchanged within the group Source authentication of OSCORE messages exchanged within the group
is ensured by means of digital counter signatures (see Sections 2 and is ensured by means of digital counter signatures (see Sections 2 and
3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members 3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members
must be able to retrieve each other's public key from a trusted key must be able to retrieve each other's public key from a trusted key
repository, in order to verify source authenticity of incoming group repository, in order to verify source authenticity of incoming group
messages. messages.
As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group
Manager acts as trusted repository of the public keys of the group Manager acts as trusted repository of the public keys of the group
members, and provides those public keys to group members if requested members, and provides those public keys to group members if requested
to. Upon joining an OSCORE group, a joining node is thus expected to to. Upon joining an OSCORE group, a joining node is thus expected to
provide its own public key to the Group Manager. provide its own public key to the Group Manager.
In particular, four cases can occur when a new node joins a group. In particular, one of the following four cases can occur when a new
node joins an OSCORE group.
o The joining node is going to join the group exclusively as pure o The joining node is going to join the group exclusively as
listener. That is, it is not going to send messages to the group, monitor. That is, it is not going to send messages to the group,
and hence to produce signatures with its own private key. In this and hence to produce signatures with its own private key. In this
case, the joining node is not required to provide its own public case, the joining node is not required to provide its own public
key to the Group Manager upon joining the group. key to the Group Manager, which thus does not have to perform any
check related to the public key encoding, or to a countersignature
algorithm and possible associated parameters for that joining
node.
o The Group Manager already acquired the public key of the joining o The Group Manager already acquired the public key of the joining
node during a previous join process. In this case, the joining node during a past join process. In this case, the joining node
node may not provide again its own public key to the Group MAY not provide again its own public key to the Group Manager, in
Manager, in order to limit the size of the join request. order to limit the size of the Join Request. The joining node
MUST provide its own public key again if it has provided the Group
Manager with multiple public keys during past join processes,
intended for different OSCORE groups. If the joining node
provides its own public key, the Group Manager performs
consistency checks as in Section 4.3 and, in case of success,
considers it as the public key associated to the joining node in
the OSCORE group.
o The joining node and the Group Manager use an asymmetric proof-of- o The joining node and the Group Manager use an asymmetric proof-of-
possession key to establish a secure communication channel. In possession key to establish a secure communication channel. Then,
this case, the Group Manager stores the proof-of-possession key two cases can occur.
conveyed in the Access Token as the public key of the joining
node. 1. The proof-of-possession key is consistent with the encoding as
well as with the counter signature algorithm and possible
associated parameters used in the OSCORE group. Then, the
Group Manager considers the proof-of-possession key as the
public key associated to the joining node in the OSCORE group.
If the joining node is aware that the proof-of-possession key
is also valid for the OSCORE group, it MAY not provide it
again as its own public key to the Group Manager. The joining
node MUST provide its own public key again if it has provided
the Group Manager with multiple public keys during past join
processes, intended for different OSCORE groups. If the
joining node provides its own public key in the 'client_cred'
parameter of the Join Request (see Section 4.2), the Group
Manager performs consistency checks as in Section 4.3 and, in
case of success, considers it as the public key associated to
the joining node in the OSCORE group.
2. The proof-of-possession key is not consistent with the
encoding or with the counter signature algorithm and possible
associated parameters used in the OSCORE group. In this case,
the joining node MUST provide a different consistent public
key to the Group Manager in the 'client_cred' parameter of the
Join Request (see Section 4.2). Then, the Group Manager
performs consistency checks on this latest provided public key
as in Section 4.3 and, in case of success, considers it as the
public key associated to the joining node in the OSCORE group.
o The joining node and the Group Manager use a symmetric proof-of- o The joining node and the Group Manager use a symmetric proof-of-
possession key to establish a secure communication channel. In possession key to establish a secure communication channel. In
this case, upon performing a join process with that Group Manager this case, upon performing a join process with that Group Manager
for the first time, the joining node specifies its own public key for the first time, the joining node specifies its own public key
in the 'client_cred' parameter of the join request targeting the in the 'client_cred' parameter of the Join Request targeting the
join endpoint (see Section 4.2). join endpoint (see Section 4.2).
Furthermore, as described in Section 4.2, the joining node may have Furthermore, as described in Section 4.2, the joining node may have
explicitly requested the Group Manager to retrieve the public keys of explicitly requested the Group Manager to retrieve the public keys of
the current group members, i.e. through the 'get_pub_keys' parameter the current group members, i.e. by including the 'get_pub_keys'
in the join request. In this case, the Group Manager includes also parameter in the Join Request. In this case, the Group Manager
such public keys in the 'pub_keys' parameter of the join response includes also such public keys in the 'pub_keys' parameter of the
(see Section 4.3). Join Response (see Section 4.3).
Later on as a group member, the node may need to retrieve the public Later on as a group member, the node may need to retrieve the public
keys of other group members. The node can do that by exchanging keys of other group members. The node can do that by exchanging with
shortened Join Request and Join Response messages with the Group the Group Manager a shortened Join Request sent to the same Join
Manager, according to the approach defined in Section 7 of Resource with the 'type' parameter set to 5 ("pub keys") and a
[I-D.ietf-ace-key-groupcomm]. shortened Join Response, according to the approach defined in
Section 7 of [I-D.ietf-ace-key-groupcomm].
7. Group Rekeying Process 7. Group Rekeying Process
In order to rekey the OSCORE group, the Group Manager distributes a In order to rekey the OSCORE group, the Group Manager distributes a
new Group ID of the group and a new OSCORE Master Secret for that new Group ID of the group and a new OSCORE Master Secret for that
group. To this end, the Group Manager MUST support at least the group. When doing so, the Group Manager MAY take a best effort to
following group rekeying scheme. Future application profiles may preserve the same unchanged Sender IDs for all group members. This
define alternative message formats and distribution schemes. avoids affecting the retrieval of public keys from the Group Manager
as well as the verification of message countersignatures.
The Group Manager MUST support at least the following group rekeying
scheme. Future application profiles may define alternative message
formats and distribution schemes.
The Group Manager uses the same format of the Join Response message The Group Manager uses the same format of the Join Response message
in Section 4.3. In particular: in Section 4.3. In particular:
o Only the parameters 'kty', 'key', 'profile' and 'exp' are present. o Only the parameters 'type', 'kty', 'key', 'profile' and 'exp' are
present.
o The 'ms' parameter of the 'key' parameter specifies the new OSCORE o The 'ms' parameter of the 'key' parameter specifies the new OSCORE
Master Secret value. Master Secret value.
o The 'contextId' parameter of the 'key' parameter specifies the new o The 'contextId' parameter of the 'key' parameter specifies the new
Group ID. Group ID.
The Group Manager separately sends a group rekeying message to each The Group Manager separately sends a group rekeying message to each
group member to be rekeyed. Each rekeying message MUST be secured group member to be rekeyed. Each rekeying message MUST be secured
with the pairwise secure communication channel between the Group with the pairwise secure communication channel between the Group
Manager and the group member used during the join process. Manager and the group member used during the join process.
This approach requires group members to act (also) as servers, in
order to correctly handle unsolicited group rekeying messages from
the Group Manager. In particular, if a group member and the Group
Manager use OSCORE [I-D.ietf-core-object-security] to secure their
pairwise communications, the group member MUST create a Replay Window
in its own Recipient Context upon establishing the OSCORE Security
Context with the Group Manager, e.g. by means of the OSCORE profile
of ACE [I-D.ietf-ace-oscore-profile].
Group members and the Group Manager SHOULD additionally support
alternative rekeying approaches that do not require group members to
act (also) as servers. A number of such approaches are defined in
Section 6 of [I-D.ietf-ace-key-groupcomm], and are based on the
following rationale:
o A group member queries the Group Manager for updated group keying
material, by sending a dedicated request to the same Join Resource
targeted when joining the group. Like for the case discussed in
Section 4.3 where the OSCORE Security Context expires, the group
member exchanges with the Group Manager a shortened Join Request
sent to the same Join Resource with the 'type' parameter set to 3
("update key") and a shortened Join Response message, according to
the approach defined in Section 6 of [I-D.ietf-ace-key-groupcomm].
o A group member subscribes for updates to the join resource and its
associated group keying material on the Group Manager. This can
rely on CoAP Observe [RFC7641] or on a full-fledged Pub-Sub model
[I-D.ietf-core-coap-pubsub] with the Group Manager acting as
Broker.
Either case, the Group Manager provides the (updated) group keying
material as specified above in this section.
8. Security Considerations 8. Security Considerations
The method described in this document leverages the following The method described in this document leverages the following
management aspects related to OSCORE groups and discussed in the management aspects related to OSCORE groups and discussed in the
sections of [I-D.ietf-core-oscore-groupcomm] referred below. sections of [I-D.ietf-core-oscore-groupcomm] referred below.
o Management of group keying material (see Section 2.1 of o Management of group keying material (see Section 2.1 of
[I-D.ietf-core-oscore-groupcomm]). The Group Manager is [I-D.ietf-core-oscore-groupcomm]). The Group Manager is
responsible for the renewal and re-distribution of the keying responsible for the renewal and re-distribution of the keying
material in the groups of its competence (rekeying). According to material in the groups of its competence (rekeying). According to
skipping to change at page 17, line 8 skipping to change at page 21, line 45
the keying material is required upon a new node's joining or a the keying material is required upon a new node's joining or a
current node's leaving, in case backward security and forward current node's leaving, in case backward security and forward
security have to be preserved, respectively. security have to be preserved, respectively.
o Provisioning and retrieval of public keys (see Section 2 of o Provisioning and retrieval of public keys (see Section 2 of
[I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key
repository of public keys of group members, and provides them upon repository of public keys of group members, and provides them upon
request. request.
o Synchronization of sequence numbers (see Section 5 of o Synchronization of sequence numbers (see Section 5 of
[I-D.ietf-core-oscore-groupcomm]). This concerns how a listener [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder
node that has just joined an OSCORE group can synchronize with the node that has just joined an OSCORE group can synchronize with the
sequence number of requesters in the same group. sequence number of requesters in the same group.
Before sending the join response, the Group Manager should verify Before sending the Join Response, the Group Manager MUST verify that
that the joining node actually owns the associated private key, for the joining node actually owns the associated private key. To this
instance by performing a proof-of-possession challenge-response, end, the Group Manager can rely on the proof-of-possession challenge-
whose details are out of the scope of this specification. response defined in Section 4. Alternatively, the joining node can
use its own public key as asymmetric proof-of-possession key to
establish a secure channel with the Group Manager, e.g. as in
Section 3.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires
such proof-of-possession key to be consistent with the encoding as
well as with the countersignature algorithm and possible associated
parameters used in the OSCORE group.
A node may have joined multiple OSCORE groups under different non-
synchronized Group Managers. Therefore, it can happen that those
OSCORE groups have the same Group Identifier (Gid). It follows that,
upon receiving a Group OSCORE message addressed to one of those
groups, the node would have multiple Security Contexts matching with
the Gid in the incoming message. It is up to the application to
decide how to handle such collisions of Group Identifiers, e.g. by
trying to process the incoming message using one Security Context at
the time until the right one is found.
Further security considerations are inherited from Further security considerations are inherited from
[I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication
and Authorization [I-D.ietf-ace-oauth-authz], and the specific and Authorization [I-D.ietf-ace-oauth-authz], and the specific
profile of ACE signalled by the AS, such as transport profile of ACE signalled by the AS, such as
[I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile].
9. IANA Considerations 9. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "[[This Note to RFC Editor: Please replace all occurrences of "[[This
specification]]" with the RFC number of this specification and delete specification]]" with the RFC number of this specification and delete
this paragraph. this paragraph.
This document has the following actions for IANA. This document has the following actions for IANA.
9.1. ACE Authorization Server Request Creation Hints Registry 9.1. ACE Groupcomm Key Registry
IANA is asked to register the following entry in the "ACE
Authorization Server Request Creation Hints" Registry defined in
Section 8.1 of [I-D.ietf-ace-oauth-authz].
o Name: key info
o CBOR Key: TBD (range -256 to 255)
o Value Type: any
o Reference: [[This specification]]
9.2. ACE Groupcomm Key Registry
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Key" Registry defined in Section 9.1 of [I-D.ietf-ace-key-groupcomm]. Key" Registry defined in Section 11.5 of
[I-D.ietf-ace-key-groupcomm].
o Name: Group_OSCORE_Security_Context object o Name: Group_OSCORE_Security_Context object
o Key Type Value: TBD o Key Type Value: TBD
o Profile: "coap_group_oscore", defined in Section 9.4 of this o Profile: "coap_group_oscore_app", defined in Section 9.3 of this
specification. specification.
o Description: A Group_OSCORE_Security_Context object encoded as o Description: A Group_OSCORE_Security_Context object encoded as
described in Section 4.3 of this specification. described in Section 4.3 of this specification.
o Reference: [[This specification]] o Reference: [[This specification]]
9.3. OSCORE Security Context Parameters Registry 9.2. OSCORE Security Context Parameters Registry
IANA is asked to register the following entries in the "OSCORE IANA is asked to register the following entries in the "OSCORE
Security Context Parameters" Registry defined in Section 9.2 of Security Context Parameters" Registry defined in Section 9.2 of
[I-D.ietf-ace-oscore-profile]. [I-D.ietf-ace-oscore-profile].
o Name: cs_alg o Name: cs_alg
o CBOR Label: TBD o CBOR Label: TBD
o CBOR Type: tstr / int o CBOR Type: tstr / int
skipping to change at page 18, line 36 skipping to change at page 23, line 27
o Registry: COSE Algorithm Values (ECDSA, EdDSA) o Registry: COSE Algorithm Values (ECDSA, EdDSA)
o Description: OSCORE Counter Signature Algorithm Value o Description: OSCORE Counter Signature Algorithm Value
o Reference: [[This specification]] o Reference: [[This specification]]
o Name: cs_params o Name: cs_params
o CBOR Label: TBD o CBOR Label: TBD
o CBOR Type: bstr o CBOR Type: map
o Registry: Counter Signatures Parameters o Registry: Counter Signatures Parameters
o Description: OSCORE Counter Signature Algorithm Additional o Description: OSCORE Counter Signature Algorithm Additional
Parameters Parameters
o Reference: [[This specification]] o Reference: [[This specification]]
9.4. ACE Groupcomm Profile Registry o Name: cs_key_params
o CBOR Label: TBD
o CBOR Type: map
o Registry: Counter Signatures Key Parameters
o Description: OSCORE Counter Signature Key Additional Parameters
o Reference: [[This specification]]
o Name: cs_key_enc
o CBOR Label: TBD
o CBOR Type: integer
o Registry: ACE Public Key Encoding
o Description: Encoding of Public Keys to be used with the OSCORE
Counter Signature Algorithm
o Reference: [[This specification]]
9.3. ACE Groupcomm Profile Registry
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Profile" Registry defined in Section 9.2 of Profile" Registry defined in Section 11.6 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o Name: coap_group_oscore o Name: coap_group_oscore_app
o Description: Profile to provision keying material for
o Description: Application profile to provision keying material for
participating in group communication protected with Group OSCORE participating in group communication protected with Group OSCORE
as per [I-D.ietf-core-oscore-groupcomm]. as per [I-D.ietf-core-oscore-groupcomm].
o CBOR Value: TBD o CBOR Value: TBD
o Reference: [[This specification]] o Reference: [[This specification]]
9.4. Sequence Number Synchronization Method Registry
IANA is asked to register the following entries in the "Sequence
Number Synchronization Method" Registry defined in Section 11.8 of
[I-D.ietf-ace-key-groupcomm].
o Name: Best effort
o Value: 1
o Description: No action is taken.
o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1).
o Name: Baseline
o Value: 2
o Description: The first received request sets the baseline
reference point, and is discarded with no delivery to the
application.
o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2).
o Name: Echo challenge-response
o Value: 3
o Description: Challenge response using the Echo Option for CoAP
from [I-D.ietf-core-echo-request-tag].
o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3).
9.5. ACE Public Key Encoding Registry
This specification registers the value defined in Figure 2 in the
"ACE Public Key Encoding" IANA Registry.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-key-groupcomm] [I-D.ietf-ace-key-groupcomm]
Palombini, F. and M. Tiloca, "Key Provisioning for Group Palombini, F. and M. Tiloca, "Key Provisioning for Group
Communication using ACE", draft-ietf-ace-key-groupcomm-00 Communication using ACE", draft-ietf-ace-key-groupcomm-02
(work in progress), December 2018. (work in progress), July 2019.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24
(work in progress), March 2019. (work in progress), March 2019.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE profile of the Authentication and Authorization "OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace- for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-07 (work in progress), February 2019. oscore-profile-07 (work in progress), February 2019.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP",
draft-ietf-core-oscore-groupcomm-03 (work in progress), draft-ietf-core-oscore-groupcomm-05 (work in progress),
October 2018. July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
[I-D.dijk-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft-
dijk-core-groupcomm-bis-00 (work in progress), March 2019.
[I-D.ietf-ace-dtls-authorize] [I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS) L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls- Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-06 (work in progress), February 2019. authorize-08 (work in progress), April 2019.
[I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-08 (work in
progress), March 2019.
[I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", draft-ietf-core-echo-
request-tag-05 (work in progress), May 2019.
[I-D.tiloca-core-oscore-discovery] [I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE
Groups with the CoRE Resource Directory", draft-tiloca- Groups with the CoRE Resource Directory", draft-tiloca-
core-oscore-discovery-01 (work in progress), January 2019. core-oscore-discovery-02 (work in progress), March 2019.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390, the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014, DOI 10.17487/RFC7390, October 2014,
<https://www.rfc-editor.org/info/rfc7390>. <https://www.rfc-editor.org/info/rfc7390>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC7641] Hartke, K., "Observing Resources in the Constrained
RFC 8152, DOI 10.17487/RFC8152, July 2017, Application Protocol (CoAP)", RFC 7641,
<https://www.rfc-editor.org/info/rfc8152>. DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
Appendix A. Document Updates Appendix A. Profile Requirements
This appendix lists the specifications on this application profile of
ACE, based on the requiremens defined in Appendix A of
[I-D.ietf-ace-key-groupcomm].
o Communication protocol that the members of the group must use:
CoAP, possibly over IP multicast.
o Security protocols that the group members must use to protect
their communication: Group OSCORE.
o Specify the encoding and value of the identifier of group and role
of 'scope': see Section 3.1.
o Profile identifier: coap_group_oscore_app
o Acceptable values of 'kty': Group_OSCORE_Security_Context object
o Specify the format and content of 'group_policies' entries: three
values are defined and registered, as content of the entry
"Sequence Number Synchronization Method" (see Section 9.4).
o (Optional) specify the format and content of 'mgt_key_material':
no.
o (Optional) specify the transport profile of ACE
[I-D.ietf-ace-oauth-authz] to use between Client and Group
Manager: any transport profile of ACE that complies with the
requirements in Appendix C of [I-D.ietf-ace-oauth-authz].
o (Optional) specify the encoding of public keys, of 'client_cred',
and of 'pub_keys' if COSE_Keys are not used: no.
o (Optional) specify the acceptable values for parameters related to
signature algorithm and signature keys: 'sign_alg' takes value
from Tables 5 and 6 of [RFC8152]; 'sign_parameters' takes values
from the "Counter Signature Parameters" Registry (see Section 9.1
of [I-D.ietf-core-oscore-groupcomm]); 'sign_key_parameters' takes
values from the "Counter Signature Key Parameters" Registry (see
Section 9.2 of [I-D.ietf-core-oscore-groupcomm]); 'pub_key_enc'
takes value from Figure 2 in Section 4.1.
o (Optional) specify the negotiation of parameter values for
signature algorithm and signature keys, if 'sign_info' and
'pub_key_enc' are not used: pre-knowledge by using the approach
based on the CoRE Resource Directory described in
[I-D.tiloca-core-oscore-discovery].
Appendix B. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
A.1. Version -00 to -01 B.1. Version -01 to -02
o Editorial fixes.
o Changed: "listener" to "responder"; "pure listener" to "monitor".
o Changed profile name to "coap_group_oscore_app", to reflect it is
an application profile.
o Added the 'type' parameter for all requests to a Join Resource.
o Added parameters to indicate the encoding of public keys.
o Challenge-response for proof-of-possession of signature keys
(Section 4).
o Renamed 'key_info' parameter to 'sign_info'; updated its format;
extended to include also parameters of the countersignature key
(Section 4.1).
o Code 4.00 (Bad request), in responses to joining nodes providing
an invalid public key (Section 4.3).
o Clarifications on provisioning and checking of public keys
(Sections 4 and 6).
o Extended discussion on group rekeying and possible different
approaches (Section 7).
o Extended security considerations: proof-of-possession of signature
keys; collision of OSCORE Group Identifiers (Section 8).
o Registered three entries in the IANA Registry "Sequence Number
Synchronization Method Registry" (Section 9).
o Registered one public key encoding in the "ACE Public Key
Encoding" IANA Registry (Section 9).
B.2. Version -00 to -01
o 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). Request (Section 3.1).
o Added negotiation of countersignature algorithm/parameters between o Added negotiation of countersignature algorithm/parameters between
Client and Group Manager (Section 4). Client and Group Manager (Section 4).
o Updated format of the Key Distribution Response as a whole o Updated format of the Key Distribution Response as a whole
(Section 4.3). (Section 4.3).
 End of changes. 90 change blocks. 
242 lines changed or deleted 618 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/