draft-ietf-ace-key-groupcomm-oscore-05.txt   draft-ietf-ace-key-groupcomm-oscore-06.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 10, 2020 Universitaet Duisburg-Essen Expires: November 12, 2020 Universitaet Duisburg-Essen
F. Palombini F. Palombini
Ericsson AB Ericsson AB
March 09, 2020 May 11, 2020
Key Management for OSCORE Groups in ACE Key Management for OSCORE Groups in ACE
draft-ietf-ace-key-groupcomm-oscore-05 draft-ietf-ace-key-groupcomm-oscore-06
Abstract Abstract
This specification defines an application profile of the ACE This specification defines an application profile of the ACE
framework for Authentication and Authorization, to request and framework for Authentication and Authorization, to request and
provision keying material in group communication scenarios that are provision keying material in group communication scenarios that are
based on CoAP and secured with Group Object Security for Constrained based on CoAP and secured with Group Object Security for Constrained
RESTful Environments (OSCORE). This application profile delegates RESTful Environments (OSCORE). This application profile delegates
the authentication and authorization of Clients that join an OSCORE the authentication and authorization of Clients that join an OSCORE
group through a Resource Server acting as Group Manager for that group through a Resource Server acting as Group Manager for that
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 10, 2020. This Internet-Draft will expire on November 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Overview of the Joining Process . . . . . . . . . . . . . 5 2.1. Overview of the Joining Process . . . . . . . . . . . . . 6
2.2. Overview of the Group Rekeying Process . . . . . . . . . 6 2.2. Overview of the Group Rekeying Process . . . . . . . . . 6
3. Joining Node to Authorization Server . . . . . . . . . . . . 6 3. Joining Node to Authorization Server . . . . . . . . . . . . 7
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7
3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 3.2. Authorization Response . . . . . . . . . . . . . . . . . 8
4. Interface at the Group Manager . . . . . . . . . . . . . . . 7 4. Interface at the Group Manager . . . . . . . . . . . . . . . 8
4.1. GET Handler . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. GET Handler . . . . . . . . . . . . . . . . . . . . . . . 8
5. Joining a Group . . . . . . . . . . . . . . . . . . . . . . . 8 5. Token POST and Group Joining . . . . . . . . . . . . . . . . 9
5.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Sending the Joining Request . . . . . . . . . . . . . . . 9 5.2. Sending the Joining Request . . . . . . . . . . . . . . . 10
5.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 10 5.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 11
5.3. Processing the Joining Request . . . . . . . . . . . . . 11 5.3. Processing the Joining Request . . . . . . . . . . . . . 12
5.4. Joining Response . . . . . . . . . . . . . . . . . . . . 12 5.4. Joining Response . . . . . . . . . . . . . . . . . . . . 13
6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 15 5.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode
7. Retrieval of Updated Keying Material . . . . . . . . . . . . 17 Support . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Retrieval of Group Keying Material . . . . . . . . . . . 17 6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 16
7.2. Retrieval of Group Keying Material and Sender ID . . . . 17 7. Retrieval of Updated Keying Material . . . . . . . . . . . . 18
8. Retrieval of New Keying Material . . . . . . . . . . . . . . 18 7.1. Retrieval of Group Keying Material . . . . . . . . . . . 18
9. Retrieval of Public Keys of Group Members . . . . . . . . . . 19 7.2. Retrieval of Group Keying Material and Sender ID . . . . 18
10. Update of Public Key . . . . . . . . . . . . . . . . . . . . 19 8. Retrieval of New Keying Material . . . . . . . . . . . . . . 19
11. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 20 9. Retrieval of Public Keys of Group Members . . . . . . . . . . 20
12. Retrieval of Keying Material Version . . . . . . . . . . . . 20 10. Update of Public Key . . . . . . . . . . . . . . . . . . . . 20
13. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 21 11. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 21
14. Request to Leave the Group . . . . . . . . . . . . . . . . . 21 12. Retrieval of Keying Material Version . . . . . . . . . . . . 21
15. Removal of a Group Member . . . . . . . . . . . . . . . . . . 21 13. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 22
16. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 22 14. Request to Leave the Group . . . . . . . . . . . . . . . . . 22
17. Security Considerations . . . . . . . . . . . . . . . . . . . 23 15. Removal of a Group Member . . . . . . . . . . . . . . . . . . 23
17.1. Management of OSCORE Groups . . . . . . . . . . . . . . 24 16. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 23
17.2. Size of Nonces for Signature Challenge . . . . . . . . . 25 17. Security Considerations . . . . . . . . . . . . . . . . . . . 25
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 17.1. Management of OSCORE Groups . . . . . . . . . . . . . . 25
18.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 26 17.2. Size of Nonces for Signature Challenge . . . . . . . . . 26
18.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 27 17.3. Reusage of Nonces for Signature Challenge . . . . . . . 27
18.3. OSCORE Security Context Parameters Registry . . . . . . 27 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
18.4. Sequence Number Synchronization Method Registry . . . . 28 18.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 28
18.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 29 18.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 28
18.6. TLS Exporter Label Registry . . . . . . . . . . . . . . 29 18.3. OSCORE Security Context Parameters Registry . . . . . . 28
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 18.4. Sequence Number Synchronization Method Registry . . . . 29
19.1. Normative References . . . . . . . . . . . . . . . . . . 29 18.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 30
19.2. Informative References . . . . . . . . . . . . . . . . . 31 18.6. ACE Groupcomm Policy Registry . . . . . . . . . . . . . 30
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 32 18.7. TLS Exporter Label Registry . . . . . . . . . . . . . . 31
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 34 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 34 19.1. Normative References . . . . . . . . . . . . . . . . . . 31
B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 35 19.2. Informative References . . . . . . . . . . . . . . . . . 33
B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 35 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 34
B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 36 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 36
B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 37 B.1. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 36
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 B.2. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 B.3. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 37
B.4. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 38
B.5. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 38
B.6. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
[RFC8613] is a method for application-layer protection of the [RFC8613] is a method for application-layer protection of the
Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object
Signing and Encryption (COSE) [RFC8152] and enabling end-to-end Signing and Encryption (COSE) [RFC8152] and enabling end-to-end
security of CoAP payload and options. security of CoAP payload and options.
As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is
used to protect CoAP group communication over IP multicast used to protect CoAP group communication over IP multicast
[I-D.dijk-core-groupcomm-bis]. This relies on a Group Manager, which [I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which
is responsible for managing an OSCORE group, where members exchange is responsible for managing an OSCORE group and enables the group
CoAP messages secured with Group OSCORE. The Group Manager can be members to exchange CoAP messages secured with Group OSCORE. The
responsible for multiple groups, coordinates the joining process of Group Manager can be responsible for multiple groups, coordinates the
new group members, and is entrusted with the distribution and renewal joining process of new group members, and is entrusted with the
of group keying material. distribution and renewal of group keying material.
This specification is an application profile of This specification is an application profile of
[I-D.ietf-ace-key-groupcomm], which itself builds on the ACE [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE
framework for Authentication and Authorization framework for Authentication and Authorization
[I-D.ietf-ace-oauth-authz]. Message exchanges among the participants [I-D.ietf-ace-oauth-authz]. Message exchanges among the participants
as well as message formats and processing follow what specified in as well as message formats and processing follow what specified in
[I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying
material in group communication scenarios, where Group OSCORE is used material in group communication scenarios, where Group OSCORE is used
to protect CoAP group communication over IP multicast. to protect CoAP group communication over IP multicast.
skipping to change at page 4, line 16 skipping to change at page 4, line 22
Readers are expected to be familiar with: Readers are expected to be familiar with:
o The terms and concepts described in the ACE framework for o The terms and concepts described in the ACE framework for
authentication and authorization [I-D.ietf-ace-oauth-authz]. The authentication and authorization [I-D.ietf-ace-oauth-authz]. The
terminology for entities in the considered architecture is defined terminology for entities in the considered architecture is defined
in OAuth 2.0 [RFC6749]. In particular, this includes Client (C), in OAuth 2.0 [RFC6749]. In particular, this includes Client (C),
Resource Server (RS), and Authorization Server (AS). Resource Server (RS), and Authorization Server (AS).
o The terms and concepts related to the CoAP protocol described in o The terms and concepts related to the CoAP protocol described in
[RFC7252][I-D.dijk-core-groupcomm-bis]. Unless otherwise [RFC7252][I-D.ietf-core-groupcomm-bis]. Unless otherwise
indicated, the term "endpoint" is used here following its OAuth indicated, the term "endpoint" is used here following its OAuth
definition, aimed at denoting resources such as /token and definition, aimed at denoting resources such as /token and
/introspect at the AS and /authz-info at the RS. This document /introspect at the AS and /authz-info at the RS. This document
does not use the CoAP definition of "endpoint", which is "An does not use the CoAP definition of "endpoint", which is "An
entity participating in the CoAP protocol". entity participating in the CoAP protocol".
o The terms and concept related to the message formats and o The terms and concept related to the message formats and
processing specified in [I-D.ietf-ace-key-groupcomm], for processing specified in [I-D.ietf-ace-key-groupcomm], for
provisioning and renewing keying material in group communication provisioning and renewing keying material in group communication
scenarios. scenarios.
skipping to change at page 5, line 7 skipping to change at page 5, line 12
o Responder: member of an OSCORE group that receives request o Responder: member of an OSCORE group that receives request
messages from other members of the group. A responder may reply messages from other members of the group. A responder may reply
back, by sending a response message to the requester which has back, by sending a response message to the requester which has
sent the request message. sent the request message.
o Monitor: member of an OSCORE group that is configured as responder o Monitor: member of an OSCORE group that is configured as responder
and never replies back to requesters after receiving request and never replies back to requesters after receiving request
messages. This corresponds to the term "silent server" used in messages. This corresponds to the term "silent server" used in
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
o Signature verifier: entity external to the OSCORE group and
intended to verify the countersignature of messages exchanged in
the group. An authorized signature verifier does not join the
OSCORE group as an actual member, yet it can retrieve the public
keys of the current group members from the Group Manager.
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
[I-D.dijk-core-groupcomm-bis] and can be secured with Group Object [I-D.ietf-core-groupcomm-bis] and can be secured with Group Object
Security for Constrained RESTful Environments (OSCORE) [RFC8613] as Security for Constrained RESTful Environments (OSCORE) [RFC8613] as
described in [I-D.ietf-core-oscore-groupcomm]. A network node joins described in [I-D.ietf-core-oscore-groupcomm]. A network node joins
an OSCORE group by interacting with the responsible Group Manager. an OSCORE group by interacting with the responsible Group Manager.
Once registered in the group, the new node can securely exchange Once registered in the group, the new node can securely exchange
messages with other group members. messages with other group members.
This specification describes how to use [I-D.ietf-ace-key-groupcomm] This specification describes how to use [I-D.ietf-ace-key-groupcomm]
and [I-D.ietf-ace-oauth-authz] to perform a number of authentication, and [I-D.ietf-ace-oauth-authz] to perform a number of authentication,
authorization and key distribution actions, as defined in Section 2. authorization and key distribution actions, as defined in Section 2.
of [I-D.ietf-ace-key-groupcomm], for an OSCORE group. of [I-D.ietf-ace-key-groupcomm], for an OSCORE group.
skipping to change at page 5, line 33 skipping to change at page 5, line 44
o The node wishing to joining the OSCORE group, i.e. the joining o The node wishing to joining the OSCORE group, i.e. the joining
node, is the Client. node, is the Client.
o The Group Manager is the Key Distribution Center (KDC), acting as o The Group Manager is the Key Distribution Center (KDC), acting as
a Resource Server. a Resource Server.
o The Authorization Server associated to the Group Manager is the o The Authorization Server associated to the Group Manager is the
AS. AS.
All communications between the involved entities rely on the CoAP All communications between the involved entities MUST be secured.
protocol and MUST be secured.
In particular, communications between the Client and the Group In particular, communications between the Client and the Group
Manager leverage protocol-specific transport profiles of ACE to Manager leverage protocol-specific transport profiles of ACE to
achieve communication security, proof-of-possession and server achieve communication security, proof-of-possession and server
authentication. Note that it is expected that in the commonly authentication. Note that it is expected that in the commonly
referred base-case of this specification, the transport profile to referred base-case of this specification, the transport profile to
use is pre-configured and well-known to nodes participating in use is pre-configured and well-known to nodes participating in
constrained applications. constrained applications.
2.1. Overview of the Joining Process 2.1. Overview of the Joining Process
skipping to change at page 6, line 17 skipping to change at page 6, line 26
If the application requires backward and forward security, the Group If the application requires backward and forward security, the Group
Manager MUST generate new keying material and distribute it to the Manager MUST generate new keying material and distribute it to the
group (rekeying) upon membership changes. group (rekeying) upon membership changes.
That is, the group is rekeyed when a node joins the group as a new That is, the group is rekeyed when a node joins the group as a new
member, or after a current member leaves the group. By doing so, a member, or after a current member leaves the group. By doing so, a
joining node cannot access communications in the group prior its joining node cannot access communications in the group prior its
joining, while a leaving node cannot access communications in the joining, while a leaving node cannot access communications in the
group after its leaving. group after its leaving.
The keying material distributed through a group rekeying MUST include The keying material distributed through a group rekeying MUST
a new Group Identifier (Gid) for the group and a new value for the include:
Master Secret parameter of the OSCORE Common Security Context of that
group (see Section 2 of [I-D.ietf-core-oscore-groupcomm]). Also, it o a new Group Identifier (Gid) for the group, used as ID Context
MAY include a new value for the Master Salt parameter of the OSCORE parameter of the OSCORE Common Security Context of that group (see
Common Security Context of that group. Section 2 of [I-D.ietf-core-oscore-groupcomm]). Note that the Gid
differs from the plain group name introduced in Section 1.1, which
is a plain, stable and invariant identifier, with no cryptographic
relevance and meaning.
o a new value for the Master Secret parameter of the OSCORE Common
Security Context of that group (see Section 2 of
[I-D.ietf-core-oscore-groupcomm]).
Also, the distributed keying material MAY include a new value for the
Master Salt parameter of the OSCORE Common Security Context of that
group.
Upon generating the new group keying material and before starting its Upon generating the new group keying material and before starting its
distribution, the Group Manager MUST increment the version number of distribution, the Group Manager MUST increment the version number of
the group keying material. When rekeying a group, the Group Manager the group keying material. When rekeying a group, the Group Manager
MUST preserve the current value of the Sender ID of each member in MUST preserve the current value of the Sender ID of each member in
that group. that group.
The Group Manager MUST support the Group Rekeying Process described The Group Manager MUST support the Group Rekeying Process described
in Section 16. Future application profiles may define alternative in Section 16. Future application profiles may define alternative
message formats and distribution schemes to perform group rekeying. message formats and distribution schemes to perform group rekeying.
skipping to change at page 6, line 49 skipping to change at page 7, line 24
contact that Group Manager for the first time. contact that Group Manager for the first time.
The message exchange between the joining node and the AS consists of The message exchange between the joining node and the AS consists of
the messages Authorization Request and Authorization Response defined the messages Authorization Request and Authorization Response defined
in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is in Section 3 of [I-D.ietf-ace-key-groupcomm]. Note that what is
defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions defined in [I-D.ietf-ace-key-groupcomm] applies, and only additions
or modifications to that specification are defined here. or modifications to that specification are defined here.
3.1. Authorization Request 3.1. Authorization Request
The Authorization Request message defined in Section 3.1 of The Authorization Request message is as defined in Section 3.1 of
[I-D.ietf-ace-key-groupcomm], with the following additions: [I-D.ietf-ace-key-groupcomm], with the following additions.
o The 'scope' parameter MUST be present. o If the 'scope' parameter is present:
* The group name of the OSCORE group to join under the Group * The group name of each OSCORE group to join under the Group
Manager is encoded as a CBOR text string (REQ1). Manager is encoded as a CBOR text string (REQ1).
* Accepted values for role identifiers in the OSCORE group to * Accepted values for role identifiers in the OSCORE group to
join are: "requester", "responder", and "monitor" (REQ2). join are: "requester", "responder", and "monitor" (REQ2).
Possible combinations are: ["requester" , "responder"]; Possible combinations are: ["requester" , "responder"]. An
["requester" , "monitor"]. Each role identifier MUST be additional role identifier is "verifier", denoting an external
encoded as a CBOR integer (REQ2), by using for abbreviation the signature verifier that does not join the OSCORE group. Each
values specified in Figure 1 (OPT7). role identifier MUST be encoded as a CBOR integer (REQ2), by
using for abbreviation the values specified in Figure 1 (OPT7).
+-----------+------------+ +-----------+------------+
| Name | CBOR Value | | Name | CBOR Value |
+-----------+------------+ +-----------+------------+
| requester | TBD8 | | requester | TBD8 |
| responder | TBD9 | | responder | TBD9 |
| monitor | TBD10 | | monitor | TBD10 |
| verifier | TBD11 |
+-----------+------------+ +-----------+------------+
Figure 1: CBOR Abbreviations for Role Identifiers in the Group Figure 1: CBOR Abbreviations for Role Identifiers in the Group
o The 'audience' parameter MUST be present.
3.2. Authorization Response 3.2. Authorization Response
The Authorization Response message defined in Section 3.2 of The Authorization Response message is as defined in Section 3.2 of
[I-D.ietf-ace-key-groupcomm], with the following additions: [I-D.ietf-ace-key-groupcomm], with the following additions:
o The AS MUST include the 'expires_in' parameter. Other means for o The AS MUST include the 'expires_in' parameter. Other means for
the AS to specify the lifetime of Access Tokens are out of the the AS to specify the lifetime of Access Tokens are out of the
scope of this specification. scope of this specification.
o The AS MUST include the 'scope' parameter, when the value included o The AS MUST include the 'scope' parameter, when the value included
in the Access Token differs from the one specified by the joining in the Access Token differs from the one specified by the joining
node in the request. In such a case, the second element of each node in the request. In such a case, the second element of each
scope entry MUST be present, and includes the role or CBOR array scope entry MUST be present, and includes the role or CBOR array
of roles that the joining node is actually authorized to take in of roles that the joining node is actually authorized to take in
the OSCORE group for that scope entry, encoded as specified in the OSCORE group for that scope entry, encoded as specified in
Section 3.1 of this document. Section 3.1 of this document.
4. Interface at the Group Manager 4. Interface at the Group Manager
The Group Manager provides the interface defined in Section 4.1 of The Group Manager provides the interface defined in Section 4.1 of
[I-D.ietf-ace-key-groupcomm], with the following additional resource: [I-D.ietf-ace-key-groupcomm], with the following additional resource:
o /group-manager/GROUPNAME/active: this sub-resource is fixed and o /group-oscore/GROUPNAME/active: this sub-resource is fixed and
supports the GET method, whose handler is defined in Section 4.1. supports the GET method, whose handler is defined in Section 4.1.
4.1. GET Handler 4.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /group- The handler verifies that the group identifier of the /group-
manager/GROUPNAME/active path is a subset of the 'scope' stored in oscore/GROUPNAME/active path is a subset of the 'scope' stored in the
the Access Token associated to the requesting client. If Access Token associated to the requesting client. If verification
verification fails, the Group Manager MUST respond with a 4.01 fails, the Group Manager MUST respond with a 4.01 (Unauthorized)
(Unauthorized) error message. error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing the CBOR simple value True if the group is message containing the CBOR simple value True if the group is
currently active, or the CBOR simple value False otherwise. The currently active, or the CBOR simple value False otherwise. The
group is considered active if it is set to allow new members to join, group is considered active if it is set to allow new members to join,
and if communication within the group is expected. and if communication within the group is expected.
The method to set the current group status, i.e. active or inactive, The method to set the current group status, i.e. active or inactive,
is out of the scope of this specification, and is defined for the is out of the scope of this specification, and is defined for the
administrator interface of the Group Manager specified in administrator interface of the Group Manager specified in
[I-D.tiloca-ace-oscore-gm-admin]. [I-D.tiloca-ace-oscore-gm-admin].
5. Joining a Group 5. Token POST and Group Joining
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 sending of the Access joining node and the Group Manager, i.e. the sending of the Access
Token and the Request-Response exchange to join the OSCORE group. Token and the Request-Response exchange to join the OSCORE group.
The message exchange between the joining node and the KDC consists of The message exchange between the joining node and the KDC consists of
the messages defined in Section 3.3 and 4.2 of the messages defined in Section 3.3 and 4.2 of
[I-D.ietf-ace-key-groupcomm]. Note that what is defined in [I-D.ietf-ace-key-groupcomm]. Note that what is defined in
[I-D.ietf-ace-key-groupcomm] applies, and only additions or [I-D.ietf-ace-key-groupcomm] applies, and only additions or
modifications to that specification are defined here. modifications to that specification are defined here.
A signature verifier provides the Group Manager with an Access Token,
as described in Section 5.1, just as any another joining node does.
However, unlike candidate group members, it does not join any OSCORE
group, i.e. it does not perform the joining process defined in
Section 5.2. After a successful token posting, a signature verifier
is authorized to perform only the operations specified in Section 9,
to retrieve the public keys of group members, and only for the OSCORE
groups specified in the validated Access Token. The Group Manager
MUST respond with a 4.01 (Unauthorized) error message, in case a
signature verifier attempts to access any other endpoint than /group-
oscore/GROUPNAME/pub-key at the Group Manager.
5.1. Token Post 5.1. Token Post
The Token post exchange is defined in Section 3.3 of The Token post exchange is defined in Section 3.3 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the
following applies. following applies.
o The 'rsnonce' parameter contains a dedicated nonce N_S generated o The 'kdcchallenge' parameter contains a dedicated nonce N_S
by the Group Manager. For the N_S value, it is RECOMMENDED to use generated by the Group Manager. For the N_S value, it is
a 8-byte long random nonce. The joining node may use this nonce RECOMMENDED to use a 8-byte long random nonce. The joining node
in order to prove the possession of its own private key, upon may use this nonce in order to prove the possession of its own
joining the group (see Section 5.2). private key, upon joining the group (see Section 5.2).
o If 'sign_info' is present in the response: The 'kdcchallenge' parameter MAY be omitted from the 2.01
(Created) response, if the 'scope' of the Access Token includes
only the role "monitor" or only the role "verifier", for each of
the specified groups.
TODO: have 'sign_info' as an array of arrays, if 'scope' in the o If the 'sign_info' parameter is present in the response, the
Access Token covers multiple groups/topics. following applies for each element 'sign_info_entry'.
* 'sign_alg' takes value from Tables 5 and 6 of [RFC8152]. * In the 'id' element, every group name is encoded as a CBOR text
string (REQ1).
* 'sign_alg' takes value from Tables 5 and 6 of [RFC8152], if not
encoding the CBOR simple value Null.
* 'sign_parameters' takes values from the "Counter Signature * 'sign_parameters' takes values from the "Counter Signature
Parameters" Registry (see Section 11.1 of Parameters" Registry (see Section 11.1 of
[I-D.ietf-core-oscore-groupcomm]). Its structure depends on [I-D.ietf-core-oscore-groupcomm]). Its structure depends on
the value of 'sign_alg'. If no parameters of the counter the value of 'sign_alg'. If no parameters of the counter
signature algorithm are specified, 'sign_parameters' MUST be signature algorithm are specified or if 'sign_alg' encodes the
encoding the CBOR simple value Null. CBOR simple value Null, 'sign_parameters' MUST be encoding the
CBOR simple value Null.
* 'sign_key_parameters' takes values from the "Counter Signature * 'sign_key_parameters' takes values from the "Counter Signature
Key Parameters" Registry (see Section 11.2 of Key Parameters" Registry (see Section 11.2 of
[I-D.ietf-core-oscore-groupcomm]). Its structure depends on [I-D.ietf-core-oscore-groupcomm]). Its structure depends on
the value of 'sign_alg'. If no parameters of the key used with the value of 'sign_alg'. If no parameters of the key used with
the counter signature algorithm are specified, the counter signature algorithm are specified or if 'sign_alg'
'sign_key_parameters' MUST be encoding the CBOR simple value encodes the CBOR simple value Null, 'sign_key_parameters' MUST
Null. be encoding the CBOR simple value Null.
TODO: have 'pub_key_enc' as an array of arrays, if 'scope' in the
Access Token covers multiple groups/topics.
o If 'pub_key_enc' is present in the response, it takes value 1 * If 'pub_key_enc_res' is present, it takes value 1 ("COSE_Key")
("COSE_Key") from the 'Confirmation Key' column of the "CWT from the 'Confirmation Key' column of the "CWT Confirmation
Confirmation Method" Registry defined in Method" Registry defined in [RFC8747], so indicating that
[I-D.ietf-ace-cwt-proof-of-possession], so indicating that public public keys in the OSCORE group are encoded as COSE Keys
keys in the OSCORE group are encoded as COSE Keys [RFC8152]. [RFC8152]. Future specifications may define additional values
Future specifications may define additional values for this for this parameter.
parameter.
Note that, other than through the above parameters as defined in Note that, other than through the above parameters as defined in
Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY
have previously retrieved this information by other means, e.g. by have previously retrieved this information by other means, e.g. by
using the approach described in [I-D.tiloca-core-oscore-discovery]. using the approach described in [I-D.tiloca-core-oscore-discovery].
Additionally, if allowed by the used transport profile of ACE, the Additionally, if allowed by the used transport profile of ACE, the
joining node may instead provide the Access Token to the Group joining node may instead provide the Access Token to the Group
Manager by other means, e.g. during a secure session establishment Manager by other means, e.g. during a secure session establishment
(see Section 3.3.1 of [I-D.ietf-ace-dtls-authorize]). (see Section 3.3.1 of [I-D.ietf-ace-dtls-authorize]).
skipping to change at page 10, line 14 skipping to change at page 11, line 8
Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the
following applies. following applies.
o The string "group-oscore" is used instead of "ace-group" (see o The string "group-oscore" is used instead of "ace-group" (see
Section 4.1 of [I-D.ietf-ace-key-groupcomm]) as the top level path Section 4.1 of [I-D.ietf-ace-key-groupcomm]) as the top level path
to the group-membership resource. The url-path /group-oscore/ is to the group-membership resource. The url-path /group-oscore/ is
a default name of this specifications: implementations are not a default name of this specifications: implementations are not
required to use this name, and can define their own instead. required to use this name, and can define their own instead.
o The 'scope' parameter MUST be present.
o The 'get_pub_keys' parameter is present only if the joining node 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 joining process (see Section 6). Group Manager during the joining process (see Section 6).
Otherwise, this parameter MUST NOT be present. Otherwise, this parameter MUST NOT be present.
o 'cnonce' contains a dedicated nonce N_C generated by the joining o 'cnonce' contains a dedicated nonce N_C generated by the joining
node. For the N_C value, it is RECOMMENDED to use a 8-byte long node. For the N_C value, it is RECOMMENDED to use a 8-byte long
random nonce. random nonce.
o The signature encoded in the 'client_cred_verify' parameter is o The signature encoded in the 'client_cred_verify' parameter is
computed by the joining node by using the same private key and computed by the joining node by using the same private key and
countersignature algorithm it intends to use for signing messages countersignature algorithm it intends to use for signing messages
in the OSCORE group. Moreover, N_S is as defined in in the OSCORE group. Moreover, N_S is as defined in
Section 5.2.1. Section 5.2.1.
5.2.1. Value of the N_S Challenge 5.2.1. Value of the N_S Challenge
The N_S challenge takes one of the following values. The value of the N_S challenge is determined as follows.
1. If the joining node has posted the Access Token to the /authz- 1. If the joining node has posted the Access Token to the /authz-
info endpoint of the Group Manager as in Section 5.1, N_S takes info endpoint of the Group Manager as in Section 5.1, N_S takes
the same value of the 'rsnonce' parameter in the 2.01 (Created) the same value of the most recent 'kdcchallenge' parameter
response to the Token POST. received by the joining node from the Group Manager. This can be
either the one specified in the 2.01 (Created) response to the
Token POST, or the one possibly specified in a 4.00 (Bad Request)
response to a following Joining Request (see Section 5.3).
2. If the Token posting has relied on the DTLS profile of ACE 2. If the Token posting has relied on the DTLS profile of ACE
[I-D.ietf-ace-dtls-authorize] and the joining node included the [I-D.ietf-ace-dtls-authorize] with the Access Token as content of
Access Token as content of the "psk_identity" field of the the "psk_identity" field of the ClientKeyExchange message
ClientKeyExchange message [RFC6347], N_S is an exporter value [RFC6347], N_S is an exporter value computed as defined in
computed as defined in Section 7.5 of [RFC8446]. Specifically, Section 7.5 of [RFC8446]. Specifically, N_S is exported from the
N_S is exported from the DTLS session between the joining node DTLS session between the joining node and the Group Manager,
and the Group Manager, using an empty 'context_value', 32 bytes using an empty 'context_value', 32 bytes as 'key_length', and the
as 'key_length', and the exporter label "EXPORTER-ACE-Sign- exporter label "EXPORTER-ACE-Sign-Challenge-coap-group-oscore-
Challenge-coap-group-oscore-app" defined in Section 18.6 of this app" defined in Section 18.7 of this specification.
specification.
3. If the joining node is in fact re-joining the group, without
posting again the same and still valid Access Token:
* If the joining node and the Group Manager communicates using
DTLS, N_S is an exporter value, computed as described in point
(2) above.
* If the joining node and the Group Manager communicates using
OSCORE [RFC8613], the N_S is the output PRK of a HKDF-Extract
step [RFC5869], i.e. PRK = HMAC-Hash(salt, IKM). In
particular, 'salt' takes (x1 | x2), where x1 is the ID Context
of the OSCORE Security Context between the joining node and
the Group Manager, x2 is the Sender ID of the joining node in
that Context, and | denotes byte string concatenation. Also,
'IKM' is the OSCORE Master Secret of the OSCORE Security
Context between the joining node and the Group Manager. The
HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms
defined for COSE [RFC8152]. HKDF SHA-256 is mandatory to
implement.
It is up to applications to define how N_S is computed in further It is up to applications to define how N_S is computed in further
alternative settings. alternative settings.
Section 17.3 provides security considerations on the reusage of the
N_S challenge.
5.3. Processing the Joining Request 5.3. Processing the Joining Request
The Group Manager processes the Joining Request as defined in The Group Manager processes the Joining Request as defined in
Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Additionally, the
following applies. following applies.
o In case the Joining Request does not include the 'client_cred' o In case the Joining Request does not include the 'client_cred'
parameter, the joining process fails if the Group Manager either: parameter, the joining process fails if the Group Manager either:
i) does not store a public key with an accepted format for the i) does not store a public key with an accepted format for the
joining node; or ii) stores multiple public keys with an accepted joining node; or ii) stores multiple public keys with an accepted
skipping to change at page 11, line 48 skipping to change at page 12, line 28
considers: i) as signed value, N_S concatenated with N_C, where considers: i) as signed value, N_S concatenated with N_C, where
N_S is determined as described in Section 5.2.1, while N_C is the N_S is determined as described in Section 5.2.1, while N_C is the
nonce provided in the 'cnonce' parameter of the Joining Request; nonce provided in the 'cnonce' parameter of the Joining Request;
ii) the countersignature algorithm used in the OSCORE group, and ii) the countersignature algorithm used in the OSCORE group, and
possible correponding parameters; and iii) the public key of the possible correponding parameters; and iii) the public key of the
joining node, either retrieved from the 'client_cred' parameter, joining node, either retrieved from the 'client_cred' parameter,
or already stored as acquired from previous interactions with the or already stored as acquired from previous interactions with the
joining node. joining node.
o A 4.00 Bad Request response from the Group Manager to the joining o A 4.00 Bad Request response from the Group Manager to the joining
node MUST have content format application/ace-group+cbor. The node MUST have content format application/ace+cbor. The response
response payload is a CBOR map which MUST contain the 'sign_info' payload is a CBOR map which MUST contain the 'sign_info'
and 'pub_key_enc' parameters. The CBOR map SHOULD additionally parameter, including a single element 'sign_info_entry' pertaining
contain the 'rsnonce' parameter, specifying a new dedicated 8-byte the OSCORE group that the joining node tried to join with the
nonce generated by the Group Manager (see Section 5.1). Joining Request.
o The Group Manager MUST return a 4.00 (Bad Request) response in o The Group Manager MUST return a 4.00 (Bad Request) response in
case the Joining Request includes the 'client_cred' parameter but case the Joining Request includes the 'client_cred' parameter but
does not include both the 'cnonce' and 'client_cred_verify' does not include both the 'cnonce' and 'client_cred_verify'
parameters. parameters.
o The Group Manager MUST return a 4.00 (Bad Request) response in o The Group Manager MUST return a 4.00 (Bad Request) response in
case it cannot retrieve a public key with an accepted format for case it cannot retrieve a public key with an accepted format for
the joining node, either from the 'client_cred' parameter or as the joining node, either from the 'client_cred' parameter or as
already stored. already stored.
skipping to change at page 12, line 30 skipping to change at page 13, line 10
* The 'client_cred' parameter MUST include a public key * The 'client_cred' parameter MUST include a public key
compatible with the encoding, countersignature algorithm and compatible with the encoding, countersignature algorithm and
possible associated parameters indicated by the Group Manager. possible associated parameters indicated by the Group Manager.
* The 'client_cred_verify' parameter MUST include a signature * The 'client_cred_verify' parameter MUST include a signature
computed as described in Section 5.2, by using the public key computed as described in Section 5.2, by using the public key
indicated in the current 'client_cred' parameter, with the indicated in the current 'client_cred' parameter, with the
countersignature algorithm and possible associated parameters countersignature algorithm and possible associated parameters
indicated by the Group Manager. If the error response from the indicated by the Group Manager. If the error response from the
Group Manager included the 'rsnonce' parameter, the joining Group Manager included the 'kdcchallenge' parameter, the
node MUST use its content as new N_S challenge to compute the joining node MUST use its content as new N_S challenge to
signature. compute the signature.
5.4. Joining Response 5.4. Joining Response
If the processing of the Joining Request described in Section 5.3 is If the processing of the Joining Request described in Section 5.3 is
successful, the Group Manager updates the group membership by successful, the Group Manager updates the group membership by
registering the joining node NODENAME as a new member of the OSCORE registering the joining node NODENAME as a new member of the OSCORE
group GROUPNAME, as described in Section 4.1.2.1 of group GROUPNAME, as described in Section 4.1.2.1 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
If the joining node is not exclusively configured as monitor, the If the joining node is not exclusively configured as monitor, the
skipping to change at page 13, line 51 skipping to change at page 14, line 32
* The 'salt' parameter, if present, has as value the OSCORE * The 'salt' parameter, if present, has as value the OSCORE
Master Salt. Master Salt.
* The 'contextId' parameter MUST be present and has as value the * The 'contextId' parameter MUST be present and has as value the
Group Identifier (Gid), i.e. the OSCORE ID Context of the Group Identifier (Gid), i.e. the OSCORE ID Context of the
OSCORE group. OSCORE group.
* 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 the "COSE Algorithms" Registry,
defined in Section 16.4 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 a CBOR map whose content depends on the This parameter is a CBOR map whose content depends on the
counter signature algorithm, as specified in Section 2 and counter signature algorithm, as specified in Section 2 and
Section 11.1 of [I-D.ietf-core-oscore-groupcomm]. Section 11.1 of [I-D.ietf-core-oscore-groupcomm].
* The 'cs_key_params' parameter MAY be present and specifies the * The 'cs_key_params' parameter MAY be present and specifies the
additional parameters for the key used with the counter additional parameters for the key used with the counter
signature algorithm. This parameter is a CBOR map whose signature algorithm. This parameter is a CBOR map whose
content depends on the counter signature algorithm, as content depends on the counter signature algorithm, as
specified in Section 2 and Section 11.2 of specified in Section 2 and Section 11.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 * The 'cs_key_enc' parameter MAY be present and specifies the
encoding of the public keys of the group members. This encoding of the public keys of the group members. This
parameter is a CBOR integer, whose value is 1 ("COSE_Key") parameter is a CBOR integer, whose value is 1 ("COSE_Key")
taken from the 'Confirmation Key' column of the "CWT taken from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry defined in Confirmation Method" Registry defined in [RFC8747], so
[I-D.ietf-ace-cwt-proof-of-possession], so indicating that indicating that public keys in the OSCORE group are encoded as
public keys in the OSCORE group are encoded as COSE Keys COSE Keys [RFC8152]. Future specifications may define
[RFC8152]. Future specifications may define additional values additional values for this parameter. If this parameter is not
for this parameter. If this parameter is not present, 1 present, 1 ("COSE_Key") MUST be assumed as default value.
("COSE_Key") MUST be assumed as default value.
o The 'num' parameter MUST be present. o The 'num' parameter MUST be present.
o The 'ace-groupcomm-profile' parameter MUST be present and has o The 'ace-groupcomm-profile' parameter MUST be present and has
value coap_group_oscore_app (TBD1), which is defined in value coap_group_oscore_app (TBD1), which is defined in
Section 18.1 of this specification. Section 18.1 of this specification.
o The 'exp' parameter MUST be present. o The 'exp' parameter MUST be present.
o The 'pub_keys' parameter, if present, includes the public keys of o The 'pub_keys' parameter, if present, includes the public keys of
skipping to change at page 14, line 49 skipping to change at page 15, line 30
it includes: i) the public keys of the responders currently in the it includes: i) the public keys of the responders currently in the
group, in case the joining node is configured (also) as requester; group, in case the joining node is configured (also) as requester;
and ii) the public keys of the requesters currently in the group, and ii) the public keys of the requesters currently in the group,
in case the joining node is configured (also) as responder or in case the joining node is configured (also) as responder or
monitor. If public keys are encoded as COSE_Keys, each of them monitor. If public keys are encoded as COSE_Keys, each of them
has as 'kid' the Sender ID that the corresponding owner has in the has as 'kid' the Sender ID that the corresponding owner has in the
group, thus used as group member identifier. group, thus used as group member identifier.
o The 'group_policies' parameter SHOULD be present, and SHOULD o The 'group_policies' parameter SHOULD be present, and SHOULD
include the elements "Sequence Number Synchronization Method" and include the elements "Sequence Number Synchronization Method" and
"Key Update Check Interval" defined in Section 4.1.2. of "Key Update Check Interval" defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm], as well as the element "Group OSCORE
Pairwise Mode Support" defined in Section 5.5 of this
specification.
Finally, the joining node uses the information received in the Finally, the joining node uses the information received in the
Joining Response to set up the OSCORE Security Context, as described Joining Response to set up the OSCORE Security Context, as described
in Section 2 of [I-D.ietf-core-oscore-groupcomm]. In addition, the in Section 2 of [I-D.ietf-core-oscore-groupcomm]. In addition, the
joining node maintains an association between each public key joining node maintains an association between each public key
retrieved from the 'pub_keys' parameter and the role(s) that the retrieved from the 'pub_keys' parameter and the role(s) that the
corresponding group member has in the group. corresponding group member has in the group.
From then on, the joining node can exchange group messages secured From then on, the joining node can exchange group messages secured
with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm].
skipping to change at page 15, line 30 skipping to change at page 16, line 15
o The joining node MUST NOT process an incoming response message, if o The joining node MUST NOT process an incoming response message, if
signed by a group member whose public key is not associated to the signed by a group member whose public key is not associated to the
role "Responder". role "Responder".
If the application requires backward security, the Group Manager MUST If the application requires backward security, the Group Manager MUST
generate updated security parameters and group keying material, and generate updated security parameters and group keying material, and
provide it to the current group members upon the new node's joining provide it to the current group members upon the new node's joining
(see Section 16). As a consequence, the joining node is not able to (see Section 16). As a consequence, the joining node is not able to
access secure communication in the group occurred prior its joining. access secure communication in the group occurred prior its joining.
5.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode Support
This specifications defines the group policy "Group OSCORE Pairwise
Mode Support", for which it registers an entry in the "ACE Groupcomm
Policy" IANA Registry defined in Section 8.7 of
[I-D.ietf-ace-key-groupcomm].
The corresponding element in the 'group_policies' parameter of the
Joining Response (see Section 5.4) encodes the CBOR simple value
True, if the OSCORE group supports the pairwise mode of Group OSCORE
[I-D.ietf-core-oscore-groupcomm], or the CBOR simple value False
otherwise (REQ14).
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
4 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members 4 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
skipping to change at page 16, line 6 skipping to change at page 17, line 4
In particular, one of the following four cases can occur when a new In particular, one of the following four cases can occur when a new
node joins an OSCORE group. node joins an OSCORE group.
o The joining node is going to join the group exclusively as o The joining node is going to join the group exclusively as
monitor. 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, which thus does not have to perform any key to the Group Manager, which thus does not have to perform any
check related to the public key encoding, or to a countersignature check related to the public key encoding, or to a countersignature
algorithm and possible associated parameters for that joining algorithm and possible associated parameters for that joining
node. node. In case that joining node still provides a public key in
the 'client_cred' parameter of the Joining Request (see
Section 5.2), the Group Manager silently ignores that parameter,
as well as related the parameters 'cnonce' and
'client_cred_verify'.
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 past joining process. In this case, the joining node during a past joining process. In this case, the joining
node MAY choose not to provide again its own public key to the node MAY choose not to provide again its own public key to the
Group Manager, in order to limit the size of the Joining Request. Group Manager, in order to limit the size of the Joining Request.
The joining node MUST provide its own public key again if it has The joining node MUST provide its own public key again if it has
provided the Group Manager with multiple public keys during past provided the Group Manager with multiple public keys during past
joining processes, intended for different OSCORE groups. If the joining processes, intended for different OSCORE groups. If the
joining node provides its own public key, the Group Manager joining node provides its own public key, the Group Manager
performs consistency checks as per Section 5.3 and, in case of performs consistency checks as per Section 5.3 and, in case of
skipping to change at page 18, line 44 skipping to change at page 19, line 47
Group Manager. Group Manager.
Upon receiving the Key Renewal Request, the Group Manager processes Upon receiving the Key Renewal Request, the Group Manager processes
it as defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm], and it as defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm], and
performs one of the following actions. performs one of the following actions.
1. If the requesting group member is configured exclusively as 1. If the requesting group member is configured exclusively as
monitor, the Group Manager replies with a 4.00 (Bad Request) monitor, the Group Manager replies with a 4.00 (Bad Request)
error response. error response.
2. Otherwise, depending on the policies configured (OPT8): 2. Otherwise, depending on the configured policies (OPT8), the Group
Manager takes one of the following actions.
a. Either the Group Manager replies to the group member with a a. The Group Manager rekeys the OSCORE group. That is, the
4.00 (Bad Request) error response, and rekeys the whole OSCORE Group Manager generates new group keying material for that group
group as discussed in Section 16; (see Section 16), and replies to the group member with a group
rekeying message as defined in Section 16, providing the new
group keying material. Then, the Group Manager rekeys the rest
of the OSCORE group, as discussed in Section 16.
b. Or the Group Manager generates a new Sender ID for that group b. The Group Manager generates a new Sender ID for that group
member and replies with a Key Renewal Response, formatted as member and replies with a Key Renewal Response, formatted as
defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm]. In defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm]. In
particular, the CBOR Map in the response payload includes a particular, the CBOR Map in the response payload includes a
single parameter 'clientId' defined in Section 18.5 of this single parameter 'clientId' defined in Section 18.5 of this
document, specifying the new Sender ID of the group member document, specifying the new Sender ID of the group member
encoded as a CBOR byte string. encoded as a CBOR byte string.
9. Retrieval of Public Keys of Group Members 9. Retrieval of Public Keys of Group Members
A group member may need to retrieve the public keys of other group A group member or a signature verifier may need to retrieve the
members. To this end, the group member sends a Public Key Request public keys of (other) group members. To this end, the group member
message to the Group Manager, as per Section 4.5 of or signature verifier sends a Public Key Request message to the Group
[I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to Manager, as per Section 4.5 of [I-D.ietf-ace-key-groupcomm]. In
the endpoint /group-oscore/GROUPNAME/pub-key at the Group Manager. particular, it sends the request to the endpoint /group-
oscore/GROUPNAME/pub-key at the Group Manager.
If the Public Key Request uses the method FETCH, the Public Key If the Public Key Request uses the method FETCH, the Public Key
Request is formatted as defined in Section 4.1.3.1 of Request is formatted as defined in Section 4.1.3.1 of
[I-D.ietf-ace-key-groupcomm]. In particular, each element of the [I-D.ietf-ace-key-groupcomm]. In particular, each element of the
'get_pub_keys' parameter is a CBOR byte string, which encodes the 'get_pub_keys' parameter is a CBOR byte string, which encodes the
Sender ID of the group member for which the associated public key is Sender ID of the group member for which the associated public key is
requested. requested.
Upon receiving the Public Key Request, the Group Manager processes it Upon receiving the Public Key Request, the Group Manager processes it
as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm],
skipping to change at page 22, line 5 skipping to change at page 23, line 11
Upon receiving the Group Leaving Request, the Group Manager processes Upon receiving the Group Leaving Request, the Group Manager processes
it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm]. it as per Section 4.1.6.3 of [I-D.ietf-ace-key-groupcomm].
15. Removal of a Group Member 15. Removal of a Group Member
Other than after a spontaneous request to the Group Manager as Other than after a spontaneous request to the Group Manager as
described in Section 14, a node may be forcibly removed from the described in Section 14, a node may be forcibly removed from the
OSCORE group, e.g. due to expired or revoked authorization. OSCORE group, e.g. due to expired or revoked authorization.
In either case, if the leaving node is not configured exclusively as If, upon joining the group (see Section 5.2), the leaving node
monitor, the Group Manager performs the following actions. specified a URI in the 'control_path' parameter defined in
Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager
MUST inform the leaving node of its eviction, by sending a DELETE
request targeting the URI specified in the 'control_path' parameter
(OPT9).
If the leaving node is not configured exclusively as monitor, the
Group Manager performs the following actions.
o The Group Manager frees the OSCORE Sender ID value of the leaving o The Group Manager frees the OSCORE Sender ID value of the leaving
node, which becomes available for possible upcoming joining nodes. node, which becomes available for possible upcoming joining nodes.
o The Group Manager cancels the association between, on one hand, o The Group Manager cancels the association between, on one hand,
the public key of the leaving node and, on the other hand, the the public key of the leaving node and, on the other hand, the
Group Identifier (Gid) associated to the OSCORE group together Group Identifier (Gid) associated to the OSCORE group together
with the freed OSCORE Sender ID value. The Group Manager deletes with the freed OSCORE Sender ID value. The Group Manager deletes
the public key of the leaving node, if that public key has no the public key of the leaving node, if that public key has no
remaining association with any pair (Gid, Sender ID). remaining association with any pair (Gid, Sender ID).
skipping to change at page 22, line 45 skipping to change at page 24, line 9
Furthermore, the Group Manager MUST preserve the same unchanged Furthermore, the Group Manager MUST preserve the same unchanged
Sender IDs for all group members. This avoids affecting the Sender IDs for all group members. This avoids affecting the
retrieval of public keys from the Group Manager as well as the retrieval of public keys from the Group Manager as well as the
verification of message countersignatures. verification of message countersignatures.
The Group Manager MUST support at least the following group rekeying The Group Manager MUST support at least the following group rekeying
scheme. Future application profiles may define alternative message scheme. Future application profiles may define alternative message
formats and distribution schemes. formats and distribution schemes.
The Group Manager uses the same format of the Joining Response As group rekeying message, the Group Manager uses the same format of
message in Section 5.4. In particular: the Joining Response message in Section 5.4. In particular:
o Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile' o Only the parameters 'gkty', 'key', 'num', 'ace-groupcomm-profile'
and 'exp' are present. 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. group member to be rekeyed.
Each rekeying message MUST be secured with the pairwise secure Each rekeying message MUST be secured with the pairwise secure
communication channel between the Group Manager and the group member communication channel between the Group Manager and the group member
used during the joining process. In particular, each rekeying used during the joining process. In particular, each rekeying
message can target the 'control_path' URI path defined in message can target the 'control_path' URI path defined in
Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm], if provided by the Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm] (OPT9), if provided
intended recipient upon joining the group (see Section 5.2). by the intended recipient upon joining the group (see Section 5.2).
It is RECOMMENDED that the Group Manager gets confirmation of It is RECOMMENDED that the Group Manager gets confirmation of
successful distribution from the group members, and admits a maximum successful distribution from the group members, and admits a maximum
number of individual retransmissions to non-confirming group members. number of individual retransmissions to non-confirming group members.
In case the rekeying terminates and some group members have not In case the rekeying terminates and some group members have not
received the new keying material, they will not be able to correctly received the new keying material, they will not be able to correctly
process following secured messages exchanged in the group. These process following secured messages exchanged in the group. These
group members will eventually contact the Group Manager, in order to group members will eventually contact the Group Manager, in order to
retrieve the current keying material and its version. retrieve the current keying material and its version.
skipping to change at page 25, line 14 skipping to change at page 26, line 26
decide how to handle such collisions of Group Identifiers, e.g. by decide how to handle such collisions of Group Identifiers, e.g. by
trying to process the incoming message using one Security Context at trying to process the incoming message using one Security Context at
the time until the right one is found. the time until the right one is found.
17.2. Size of Nonces for Signature Challenge 17.2. Size of Nonces for Signature Challenge
With reference to the Joining Request message in Section 5.2, the With reference to the Joining Request message in Section 5.2, the
proof-of-possession signature included in 'client_cred_verify' is proof-of-possession signature included in 'client_cred_verify' is
computed over the challenge N_C | N_S, where | denotes concatenation. computed over the challenge N_C | N_S, where | denotes concatenation.
For the N_C value, it is RECOMMENDED to use a 8-byte long random For the N_C challenge share, it is RECOMMENDED to use a 8-byte long
nonce. Furthermore, N_C is always conveyed in the 'cnonce' parameter random nonce. Furthermore, N_C is always conveyed in the 'cnonce'
of the Joining Request, which is always sent over the secure parameter of the Joining Request, which is always sent over the
communication channel between the joining node and the Group Manager. secure communication channel between the joining node and the Group
Manager.
As defined in Section 5.2.1, the way the N_S value is computed As defined in Section 5.2.1, the way the N_S value is computed
depends on the particular interaction between the joining node and depends on the particular way the joining node provides the Group
the Group Manager. Manager with the Access Token, as well as on following interactions
between the two.
o If the Access Token is not explicitly posted to the /authz-info o If the Access Token is not explicitly posted to the /authz-info
endpoint of the Group Manager, or if the joining node re-joins endpoint of the Group Manager, then N_S is computed as a 32-byte
without re-posting the same still valid Access Token, then N_S is long challenge share (see points 2 of Section 5.2.1).
computed as a 32-byte long nonce (see points (2) and (3) of
Section 5.2.1).
o If the Access Token has been explicitly posted to the /authz-info o If the Access Token has been explicitly posted to the /authz-info
endpoint of the Group Manager, N_S takes the value conveyed in the endpoint of the Group Manager, N_S takes the most recent value
'rsnonce' parameter of the 2.01 response to the Token Post (see specified to the client by the Group Manager in the 'kdcchallenge'
Section 5.1). Similarly, if a Joining Request is not successfully parameter (see point 1 of Section 5.2.1). This is specified
processed by the Group Manager, the returned error response should either in the 2.01 response to the Token Post (see Section 5.1),
also include the 'rsnonce' parameter specifying a new nonce N_S or in a 4.00 response to a following Joining Request (see
(see Section 5.3). In either case, it is RECOMMENDED to use a Section 5.3). In either case, it is RECOMMENDED to use a 8-byte
8-byte long random nonce as value for N_S. long random challenge as value for N_S.
If we consider both N_C and N_S to be 8-byte long nonces, the If we consider both N_C and N_S to take 8-byte long values, the
following considerations hold. following considerations hold.
o If both N_C and N_S are random nonces, the average collision for o Let us consider both N_C and N_S as taking random values, and the
each nonce will happen after 2^32 messages, as per the birthday Group Manager to never change the value of the N_S provided to a
paradox and as also discussed in Section 7 of Client during the lifetime of an Access Token. Then, as per the
[I-D.ietf-ace-oscore-profile]. This amounts to considerably more birthday paradox, the average collision for N_S will happen after
token provisionings than the expected new joinings of OSCORE 2^32 new posted Access Tokens, while the average collision for N_C
groups under a same Group Manager. will happen after 2^32 new Joining Requests. This amounts to
considerably more token provisionings than the expected new
o If N_C and N_S are not generated randomly, e.g. by using a joinings of OSCORE groups under a same Group Manager, as well as
counter, the joining node and the Group Manager need to guarantee to considerably more requests to join OSCORE groups from a same
that reboot and loss of state on either node does not provoke re- Client using a same Access Token under a same Group Manager.
use. If that is not guaranteed, a joining node may repeatedly
post a valid Access Token to the /authz-info endpoint of the Group
Manager, until it gets back an exact, re-used value N_S* to use as
nonce. Then, the joining node can send a Joining Request,
conveying a reused N_C* nonce in 'cnonce' and an old stored
signature in 'client_cred_verify', computed over N_C* | N_S*. By
verifying the signature, the Group Manager would falsely believe
that the joining node possesses its own private key at that point
in time.
o Since N_C is always conveyed in a secured Joining Request, it is
practically infeasible for an on-path attacker to replay Joining
Requests from a joining node to the Group Manager, in order to
cause that joining node to use an arbitrary nonce N_S.
o Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of o Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of
[RFC8613] recommend the use of 8-byte random nonces as well. [RFC8613] recommend the use of 8-byte random values as well.
Unlike in those cases, the nonces N_C and N_S considered in this Unlike in those cases, the values of N_C and N_S considered in
specification are not used for as sensitive operations as the this specification are not used for as sensitive operations as the
derivation of a Security Context, with possible implications in derivation of a Security Context, with possible implications in
the security of AEAD ciphers. the security of AEAD ciphers.
17.3. Reusage of Nonces for Signature Challenge
As long as the Group Manager preserves the same N_S value currently
associated to an Access Token, i.e. the latest value provided to a
Client in a 'kdcchallenge' parameter, the Client is able to
successfully reuse the same signature challenge for multiple Joining
Requests to that Group Manager.
In particular, the client can reuse the same N_C value for every
Joining Request to the Group Manager, and combine it with the same
unchanged N_S value. This results in reusing the same signature
challenge for producing the signature to include in the
'client_cred_verify' parameter of the Joining Requests.
Unless the Group Manager maintains a list of N_C values already used
by that Client since the latest update to the N_S value associated to
the Access Token, the Group Manager can be forced to falsely believe
that the Client possesses its own private key at that point in time,
upon verifying the signature in the 'client_cred_verify' parameter.
18. IANA Considerations 18. 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.
18.1. ACE Groupcomm Profile Registry 18.1. ACE Groupcomm Profile Registry
skipping to change at page 29, line 27 skipping to change at page 30, line 46
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o Name: clientId o Name: clientId
o CBOR Key: TBD7 o CBOR Key: TBD7
o CBOR Type: Byte string o CBOR Type: Byte string
o Reference: [[This specification]] (Section 8) o Reference: [[This specification]] (Section 8)
18.6. TLS Exporter Label Registry 18.6. ACE Groupcomm Policy Registry
IANA is asked to register the following entry in the "ACE Groupcomm
Policy" Registry defined in Section 8.7 of
[I-D.ietf-ace-key-groupcomm].
o Name: Group OSCORE Pairwise Mode Support
o CBOR Key: TBD8
o CBOR Type: Simple value
o Description: True if the OSCORE group supports the pairwise mode
of Group OSCORE [I-D.ietf-core-oscore-groupcomm], False otherwise.
o Reference: [[This specification]] (Section 5.5)
18.7. TLS Exporter Label Registry
IANA is asked to register the following entry in the "TLS Exporter IANA is asked to register the following entry in the "TLS Exporter
Label" Registry defined in Section 6 of [RFC5705] and updated in Label" Registry defined in Section 6 of [RFC5705] and updated in
Section 12 of [RFC8447]. Section 12 of [RFC8447].
o Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app o Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app
o DTLS-OK: Y o DTLS-OK: Y
o Recommended: N o Recommended: N
o Reference: [[This specification]] (Section 5.2.1) o Reference: [[This specification]] (Section 5.2.1)
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-11 (work in progress), October 2019.
[I-D.ietf-ace-key-groupcomm] [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-05 Communication using ACE", draft-ietf-ace-key-groupcomm-06
(work in progress), March 2020. (work in progress), May 2020.
[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-33 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33
(work in progress), February 2020. (work in progress), February 2020.
[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-10 (work in progress), March 2020. oscore-profile-10 (work in progress), March 2020.
[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-07 (work in progress), draft-ietf-core-oscore-groupcomm-08 (work in progress),
March 2020. April 2020.
[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>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[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)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <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
skipping to change at page 31, line 22 skipping to change at page 32, line 46
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
19.2. Informative References [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, <https://www.rfc-editor.org/info/rfc8747>.
[I-D.dijk-core-groupcomm-bis] 19.2. Informative References
Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft-
dijk-core-groupcomm-bis-03 (work in progress), March
2020.
[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-09 (work in progress), December 2019. authorize-09 (work in progress), December 2019.
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-09 (work in (CoAP)", draft-ietf-core-coap-pubsub-09 (work in
progress), September 2019. progress), September 2019.
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", draft-ietf-core-echo- Request-Tag, and Token Processing", draft-ietf-core-echo-
request-tag-09 (work in progress), March 2020. request-tag-09 (work in progress), March 2020.
[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.
[I-D.tiloca-ace-oscore-gm-admin] [I-D.tiloca-ace-oscore-gm-admin]
Tiloca, M., Hoeglund, R., Stok, P., and F. Palombini, Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K.
"Admin Interface for the OSCORE Group Manager", draft- Hartke, "Admin Interface for the OSCORE Group Manager",
tiloca-ace-oscore-gm-admin-01 (work in progress), March draft-tiloca-ace-oscore-gm-admin-01 (work in progress),
2020. March 2020.
[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-05 (work in progress), March core-oscore-discovery-05 (work in progress), March 2020.
2020.
[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>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
skipping to change at page 32, line 31 skipping to change at page 34, line 12
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
Appendix A. Profile Requirements Appendix A. Profile Requirements
This appendix lists the specifications on this application profile of This appendix lists the specifications on this application profile of
ACE, based on the requiremens defined in Appendix A of ACE, based on the requiremens defined in Appendix A of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o REQ1 - Specify the encoding and value of the identifier of group, o REQ1 - Specify the encoding and value of the identifier of group,
for scope entries of 'scope': see Section 3.1. for scope entries of 'scope': see Section 3.1 and Section 5.1.
o 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. of 'scope': see Section 3.1.
o REQ3 - if used, specify the acceptable values for 'sign_alg': o REQ3 - if used, specify the acceptable values for 'sign_alg':
values from Tables 5 and 6 of [RFC8152]. values from Tables 5 and 6 of [RFC8152].
o REQ4 - If used, specify the acceptable values for o REQ4 - If used, specify the acceptable values for
'sign_parameters': values from the "Counter Signature Parameters" 'sign_parameters': values from the "Counter Signature Parameters"
Registry (see Section 11.1 of [I-D.ietf-core-oscore-groupcomm]). Registry (see Section 11.1 of [I-D.ietf-core-oscore-groupcomm]).
o REQ5 - If used, specify the acceptable values for o REQ5 - If used, specify the acceptable values for
'sign_key_parameters': values from the "Counter Signature Key 'sign_key_parameters': values from the "Counter Signature Key
Parameters" Registry (see Section 11.2 of Parameters" Registry (see Section 11.2 of
[I-D.ietf-core-oscore-groupcomm]). [I-D.ietf-core-oscore-groupcomm]).
o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1 o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1
("COSE_Key") from the 'Confirmation Key' column of the "CWT ("COSE_Key") from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry defined in Confirmation Method" Registry defined in [RFC8747]. Future
[I-D.ietf-ace-cwt-proof-of-possession]. Future specifications may specifications may define additional values for this parameter.
define additional values for this parameter.
o REQ7 - Format of the 'key' value: see Section 5.4. o REQ7 - Format of the 'key' value: see Section 5.4.
o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Security_Context o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Security_Context
object (see Section 5.4). object (see Section 5.4).
o REQ9: Specify the format of the identifiers of group members: see o REQ9: Specify the format of the identifiers of group members: see
Section 5.4 and Section 9. Section 5.4 and Section 9.
o REQ10 - Specify the communication protocol that the members of the o REQ10 - Specify the communication protocol that the members of the
skipping to change at page 33, line 26 skipping to change at page 35, line 6
o REQ11 - Specify the security protocols that the group members must o REQ11 - Specify the security protocols that the group members must
use to protect their communication: Group OSCORE. use to protect their communication: Group OSCORE.
o REQ12 - Specify and register the application profile identifier: o REQ12 - Specify and register the application profile identifier:
coap_group_oscore_app (see Section 18.1). coap_group_oscore_app (see Section 18.1).
o REQ13 - Specify policies at the KDC to handle member ids that are o REQ13 - Specify policies at the KDC to handle member ids that are
not included in 'get_pub_keys': see Section 9. not included in 'get_pub_keys': see Section 9.
o REQ14 - If used, specify the format and content of o REQ14 - If used, specify the format and content of
'group_policies' and its entries: see Section 5.4, and the three 'group_policies' and its entries: see Section 5.4; the three
values defined and registered, as content of the entry "Sequence values defined and registered, as content of the entry "Sequence
Number Synchronization Method" (see Section 18.4). Number Synchronization Method" (see Section 18.4); the defined and
registered encoding of the entry "Group OSCORE Pairwise Mode
Support" (see Section 18.6).
o 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, material for group members, or of the information to derive it,
and corresponding CBOR label: see Section 8. and corresponding CBOR label: see Section 8.
o REQ16 - Specify how the communication is secured between the o REQ16 - Specify how the communication is secured between the
Client and KDC: by means of any transport profile of ACE Client and KDC: by means of any transport profile of ACE
[I-D.ietf-ace-oauth-authz] between Client and Group Manager that [I-D.ietf-ace-oauth-authz] between Client and Group Manager that
complies with the requirements in Appendix C of complies with the requirements in Appendix C of
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
skipping to change at page 34, line 28 skipping to change at page 36, line 11
o OPT6 (Optional) - Specify possible or required payload formats for o OPT6 (Optional) - Specify possible or required payload formats for
specific error cases: send a 4.00 Bad Request response to a specific error cases: send a 4.00 Bad Request response to a
Joining Request (see Section 5.3). Joining Request (see Section 5.3).
o OPT7 (Optional) - Specify CBOR values to use for abbreviating o OPT7 (Optional) - Specify CBOR values to use for abbreviating
identifiers of roles in the group or topic (see Section 3.1). identifiers of roles in the group or topic (see Section 3.1).
o OPT8 (Optional) - Specify policies for the KDC to perform group o OPT8 (Optional) - Specify policies for the KDC to perform group
rekeying after receiving a Key Renewal Request: no. rekeying after receiving a Key Renewal Request: no.
o OPT9 (Optional) - 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 of
[I-D.ietf-ace-key-groupcomm]): see Section 15 for the eviction of
a group member; see Section 16 for the group rekeying process.
o OPT10 (Optional) - Specify how the identifier of the sender's
public key is included in the group request: no.
Appendix B. Document Updates Appendix B. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
B.1. Version -04 to -05 B.1. Version -05 to -06
o Added role of external signature verifier.
o Parameter 'rsnonce' renamed to 'kdcchallenge'.
o Parameter 'kdcchallenge' may be omitted in some cases.
o Clarified difference between group name and OSCORE Gid.
o Removed the role combination ["requester", "monitor"].
o Admit implicit scope and audience in the Authorization Request.
o New format for the 'sign_info' parameter.
o Scope not mandatory to include in the Joining Request.
o Group policy about supporting Group OSCORE in pairwise mode.
o Possible individual rekeying of a single requesting node combined
with a group rekeying.
o Security considerations on reusage of signature challenges.
o Addressing optional requirement OPT9 from draft-ietf-ace-key-
groupcomm
o Editorial improvements.
B.2. Version -04 to -05
o Nonce N_S also in error responses to the Joining Requests. o Nonce N_S also in error responses to the Joining Requests.
o Supporting single Access Token for multiple groups/topics. o Supporting single Access Token for multiple groups/topics.
o Supporting legal requesters/responders using the 'peer_roles' o Supporting legal requesters/responders using the 'peer_roles'
parameter. parameter.
o Registered and used dedicated label for TLS Exporter. o Registered and used dedicated label for TLS Exporter.
skipping to change at page 35, line 15 skipping to change at page 37, line 34
o Clarification on incrementing version number when rekeying the o Clarification on incrementing version number when rekeying the
group. group.
o Clarification on what is re-distributed with the group rekeying. o Clarification on what is re-distributed with the group rekeying.
o Security considerations on the size of the nonces used for the o Security considerations on the size of the nonces used for the
signature challenge. signature challenge.
o Added CBOR values to abbreviate role identifiers in the group. o Added CBOR values to abbreviate role identifiers in the group.
B.2. Version -03 to -04 B.3. Version -03 to -04
o New abstract. o New abstract.
o Moved general content to draft-ietf-ace-key-groupcomm o Moved general content to draft-ietf-ace-key-groupcomm
o Terminology: node name; node resource. o Terminology: node name; node resource.
o Creation and pointing at node resource. o Creation and pointing at node resource.
o Updated Group Manager API (REST methods and offered services). o Updated Group Manager API (REST methods and offered services).
skipping to change at page 35, line 34 skipping to change at page 38, line 4
o Updated Group Manager API (REST methods and offered services). o Updated Group Manager API (REST methods and offered services).
o Size of challenges 'cnonce' and 'rsnonce'. o Size of challenges 'cnonce' and 'rsnonce'.
o Value of 'rsnonce' for reused or non-traditionally-posted tokens. o Value of 'rsnonce' for reused or non-traditionally-posted tokens.
o Removed reference to RFC 7390. o Removed reference to RFC 7390.
o New requirements from draft-ietf-ace-key-groupcomm o New requirements from draft-ietf-ace-key-groupcomm
o Editorial improvements. o Editorial improvements.
B.3. Version -02 to -03 B.4. Version -02 to -03
o New sections, aligned with the interface of ace-key-groupcomm . o New sections, aligned with the interface of ace-key-groupcomm .
o Exchange of information on the countersignature algorithm and o Exchange of information on the countersignature algorithm and
related parameters, during the Token POST (Section 4.1). related parameters, during the Token POST (Section 4.1).
o Nonce 'rsnonce' from the Group Manager to the Client o Nonce 'rsnonce' from the Group Manager to the Client
(Section 4.1). (Section 4.1).
o Client PoP signature in the Key Distribution Request upon joining o Client PoP signature in the Key Distribution Request upon joining
skipping to change at page 36, line 12 skipping to change at page 38, line 29
o Local actions on the Group Manager, upon a new node's joining o Local actions on the Group Manager, upon a new node's joining
(Section 4.2). (Section 4.2).
o Local actions on the Group Manager, upon a node's leaving o Local actions on the Group Manager, upon a node's leaving
(Section 12). (Section 12).
o IANA registration in ACE Groupcomm Parameters Registry. o IANA registration in ACE Groupcomm Parameters Registry.
o More fulfilled profile requirements (Appendix A). o More fulfilled profile requirements (Appendix A).
B.4. Version -01 to -02 B.5. Version -01 to -02
o Editorial fixes. o Editorial fixes.
o Changed: "listener" to "responder"; "pure listener" to "monitor". o Changed: "listener" to "responder"; "pure listener" to "monitor".
o Changed profile name to "coap_group_oscore_app", to reflect it is o Changed profile name to "coap_group_oscore_app", to reflect it is
an application profile. an application profile.
o Added the 'type' parameter for all requests to a Join Resource. o Added the 'type' parameter for all requests to a Join Resource.
skipping to change at page 37, line 5 skipping to change at page 39, line 20
o Extended security considerations: proof-of-possession of signature o Extended security considerations: proof-of-possession of signature
keys; collision of OSCORE Group Identifiers (Section 8). keys; collision of OSCORE Group Identifiers (Section 8).
o Registered three entries in the IANA Registry "Sequence Number o Registered three entries in the IANA Registry "Sequence Number
Synchronization Method Registry" (Section 9). Synchronization Method Registry" (Section 9).
o Registered one public key encoding in the "ACE Public Key o Registered one public key encoding in the "ACE Public Key
Encoding" IANA Registry (Section 9). Encoding" IANA Registry (Section 9).
B.5. Version -00 to -01 B.6. 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. 80 change blocks. 
261 lines changed or deleted 366 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/