< draft-ietf-ace-key-groupcomm-oscore-13.txt   draft-ietf-ace-key-groupcomm-oscore-14.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: 8 September 2022 Universitaet Duisburg-Essen Expires: 30 October 2022 Universitaet Duisburg-Essen
F. Palombini F. Palombini
Ericsson AB Ericsson AB
7 March 2022 28 April 2022
Key Management for OSCORE Groups in ACE Key Management for OSCORE Groups in ACE
draft-ietf-ace-key-groupcomm-oscore-13 draft-ietf-ace-key-groupcomm-oscore-14
Abstract Abstract
This document defines an application profile of the ACE framework for This document defines an application profile of the ACE framework for
Authentication and Authorization, to request and provision keying Authentication and Authorization, to request and provision keying
material in group communication scenarios that are based on CoAP and material in group communication scenarios that are based on CoAP and
secured with Group Object Security for Constrained RESTful are secured with Group Object Security for Constrained RESTful
Environments (OSCORE). This application profile delegates the Environments (Group OSCORE). This application profile delegates the
authentication and authorization of Clients that join an OSCORE group authentication and authorization of Clients, that join an OSCORE
through a Resource Server acting as Group Manager for that group. group through a Resource Server acting as Group Manager for that
This application profile leverages protocol-specific transport group. This application profile leverages protocol-specific
profiles of ACE to achieve communication security, server transport profiles of ACE to achieve communication security, server
authentication and proof-of-possession for a key owned by the Client authentication and proof-of-possession for a key owned by the Client
and bound to an OAuth 2.0 Access Token. and bound to an OAuth 2.0 Access Token.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 September 2022. This Internet-Draft will expire on 30 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Overview of the Joining Process . . . . . . . . . . . . . 7 3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Overview of the Group Rekeying Process . . . . . . . . . 7 4. Authentication Credentials . . . . . . . . . . . . . . . . . 10
2.2.1. Stale OSCORE Sender IDs . . . . . . . . . . . . . . . 9 5. Authorization to Join a Group . . . . . . . . . . . . . . . . 12
3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Authorization Request . . . . . . . . . . . . . . . . . . 12
4. Joining Node to Authorization Server . . . . . . . . . . . . 11 5.2. Authorization Response . . . . . . . . . . . . . . . . . 13
4.1. Authorization Request . . . . . . . . . . . . . . . . . . 12 5.3. Token Transferring . . . . . . . . . . . . . . . . . . . 13
4.2. Authorization Response . . . . . . . . . . . . . . . . . 12 5.3.1. 'ecdh_info' Parameter . . . . . . . . . . . . . . . . 16
5. Interface at the Group Manager . . . . . . . . . . . . . . . 13 5.3.2. 'kdc_dh_creds' Parameter . . . . . . . . . . . . . . 18
5.1. ace-group/GROUPNAME/active . . . . . . . . . . . . . . . 13 6. Group Joining . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 13 6.1. Send the Joining Request . . . . . . . . . . . . . . . . 20
5.2. ace-group/GROUPNAME/verif-data . . . . . . . . . . . . . 14 6.1.1. Value of the N_S Challenge . . . . . . . . . . . . . 22
5.2.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 14 6.2. Receive the Joining Request . . . . . . . . . . . . . . . 22
5.3. ace-group/GROUPNAME/stale-sids . . . . . . . . . . . . . 14 6.2.1. Follow-up to a 4.00 (Bad Request) Error Response . . 25
5.3.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 15 6.3. Send the Joining Response . . . . . . . . . . . . . . . . 26
5.4. Admitted Methods . . . . . . . . . . . . . . . . . . . . 15 6.4. Receive the Joining Response . . . . . . . . . . . . . . 32
5.5. Operations Supported by Clients . . . . . . . . . . . . . 16 7. Overview of the Group Rekeying Process . . . . . . . . . . . 34
6. Token Transferring and Group Joining . . . . . . . . . . . . 17 7.1. Stale OSCORE Sender IDs . . . . . . . . . . . . . . . . . 35
6.1. Token Transferring . . . . . . . . . . . . . . . . . . . 18 8. Interface at the Group Manager . . . . . . . . . . . . . . . 37
6.1.1. 'ecdh_info' Parameter . . . . . . . . . . . . . . . . 20 8.1. ace-group/GROUPNAME/active . . . . . . . . . . . . . . . 37
6.1.2. 'kdc_dh_creds' Parameter . . . . . . . . . . . . . . 23 8.1.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 37
6.2. Send the Joining Request . . . . . . . . . . . . . . . . 24 8.2. ace-group/GROUPNAME/verif-data . . . . . . . . . . . . . 38
6.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 26 8.2.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 38
6.3. Receive the Joining Request . . . . . . . . . . . . . . . 26 8.3. ace-group/GROUPNAME/stale-sids . . . . . . . . . . . . . 38
6.4. Send the Joining Response . . . . . . . . . . . . . . . . 30 8.3.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 38
6.5. Receive the Joining Response . . . . . . . . . . . . . . 36 8.4. Admitted Methods . . . . . . . . . . . . . . . . . . . . 39
7. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 38 8.4.1. Signature Verifiers . . . . . . . . . . . . . . . . . 40
8. Retrieve of Updated Keying Material . . . . . . . . . . . . . 40 8.5. Operations Supported by Clients . . . . . . . . . . . . . 41
8.1. Retrieve of Group Keying Material . . . . . . . . . . . . 40 9. Additional Interactions with the Group Manager . . . . . . . 41
8.2. Retrieve of Group Keying Material and OSCORE Sender ID . 41 9.1. Retrieve Updated Keying Material . . . . . . . . . . . . 42
9. Request to Change Individual Keying Material . . . . . . . . 41 9.1.1. Get Group Keying Material . . . . . . . . . . . . . . 42
10. Retrieve Authentication Credentials of Group Members . . . . 43 9.1.2. Get Group Keying Material and OSCORE Sender ID . . . 42
11. Upload a New Authentication Credential . . . . . . . . . . . 44 9.2. Request to Change Individual Keying Material . . . . . . 43
12. Retrieve the Group Manager's Authentication Credential . . . 45 9.3. Retrieve Authentication Credentials of Group Members . . 45
13. Retrieve Signature Verification Data . . . . . . . . . . . . 46 9.4. Upload a New Authentication Credential . . . . . . . . . 45
14. Retrieve the Group Policies . . . . . . . . . . . . . . . . . 48 9.5. Retrieve the Group Manager's Authentication Credential . 47
15. Retrieve the Keying Material Version . . . . . . . . . . . . 49 9.6. Retrieve Signature Verification Data . . . . . . . . . . 48
16. Retrieve the Group Status . . . . . . . . . . . . . . . . . . 49 9.7. Retrieve the Group Policies . . . . . . . . . . . . . . . 50
17. Retrieve Group Names . . . . . . . . . . . . . . . . . . . . 50 9.8. Retrieve the Keying Material Version . . . . . . . . . . 50
18. Leave the Group . . . . . . . . . . . . . . . . . . . . . . . 53 9.9. Retrieve the Group Status . . . . . . . . . . . . . . . . 50
19. Removal of a Group Member . . . . . . . . . . . . . . . . . . 53 9.10. Retrieve Group Names . . . . . . . . . . . . . . . . . . 51
20. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 55 9.11. Leave the Group . . . . . . . . . . . . . . . . . . . . . 54
20.1. Sending Rekeying Messages . . . . . . . . . . . . . . . 57 10. Removal of a Group Member . . . . . . . . . . . . . . . . . . 54
20.2. Receiving Rekeying Messages . . . . . . . . . . . . . . 59 11. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 56
20.3. Missed Rekeying Instances . . . . . . . . . . . . . . . 60 11.1. Sending Rekeying Messages . . . . . . . . . . . . . . . 58
20.3.1. Retrieval of Stale Sender IDs . . . . . . . . . . . 62 11.2. Receiving Rekeying Messages . . . . . . . . . . . . . . 60
21. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 64 11.3. Missed Rekeying Instances . . . . . . . . . . . . . . . 61
22. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 66 11.3.1. Retrieve Stale Sender IDs . . . . . . . . . . . . . 63
23. Default Values for Group Configuration Parameters . . . . . . 66 12. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 65
23.1. Common . . . . . . . . . . . . . . . . . . . . . . . . . 67 13. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 67
23.2. Group Mode . . . . . . . . . . . . . . . . . . . . . . . 67 14. Default Values for Group Configuration Parameters . . . . . . 68
23.3. Pairwise Mode . . . . . . . . . . . . . . . . . . . . . 68 14.1. Common . . . . . . . . . . . . . . . . . . . . . . . . . 68
24. Security Considerations . . . . . . . . . . . . . . . . . . . 69 14.2. Group Mode . . . . . . . . . . . . . . . . . . . . . . . 69
24.1. Management of OSCORE Groups . . . . . . . . . . . . . . 69 14.3. Pairwise Mode . . . . . . . . . . . . . . . . . . . . . 70
24.2. Size of Nonces as Proof-of-Possesion Challenge . . . . . 70 15. Security Considerations . . . . . . . . . . . . . . . . . . . 71
24.3. Reusage of Nonces for Proof-of-Possession Input . . . . 71 15.1. Management of OSCORE Groups . . . . . . . . . . . . . . 71
25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 15.2. Size of Nonces as Proof-of-Possesion Challenge . . . . . 72
25.1. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 72 15.3. Reusage of Nonces for Proof-of-Possession Input . . . . 73
25.2. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 72 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
25.3. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 73 16.1. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 74
25.4. ACE Groupcomm Key Types . . . . . . . . . . . . . . . . 74 16.2. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 74
25.5. ACE Groupcomm Profiles . . . . . . . . . . . . . . . . . 74 16.3. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 75
25.6. OSCORE Security Context Parameters . . . . . . . . . . . 74 16.4. ACE Groupcomm Key Types . . . . . . . . . . . . . . . . 76
25.7. TLS Exporter Labels . . . . . . . . . . . . . . . . . . 76 16.5. ACE Groupcomm Profiles . . . . . . . . . . . . . . . . . 76
25.8. AIF . . . . . . . . . . . . . . . . . . . . . . . . . . 77 16.6. OSCORE Security Context Parameters . . . . . . . . . . . 76
25.9. CoAP Content-Format . . . . . . . . . . . . . . . . . . 77 16.7. TLS Exporter Labels . . . . . . . . . . . . . . . . . . 78
25.10. Group OSCORE Roles . . . . . . . . . . . . . . . . . . . 78 16.8. AIF . . . . . . . . . . . . . . . . . . . . . . . . . . 79
25.11. CoRE Resource Type . . . . . . . . . . . . . . . . . . . 78 16.9. CoAP Content-Format . . . . . . . . . . . . . . . . . . 79
25.12. ACE Scope Semantics . . . . . . . . . . . . . . . . . . 79 16.10. Group OSCORE Roles . . . . . . . . . . . . . . . . . . . 80
25.13. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 79 16.11. CoRE Resource Type . . . . . . . . . . . . . . . . . . . 80
25.14. Expert Review Instructions . . . . . . . . . . . . . . . 80 16.12. ACE Scope Semantics . . . . . . . . . . . . . . . . . . 81
26. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 16.13. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 81
26.1. Normative References . . . . . . . . . . . . . . . . . . 80 16.14. Expert Review Instructions . . . . . . . . . . . . . . . 82
26.2. Informative References . . . . . . . . . . . . . . . . . 84 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 82
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 86 17.1. Normative References . . . . . . . . . . . . . . . . . . 82
A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 86 17.2. Informative References . . . . . . . . . . . . . . . . . 86
A.2. Optional-to-Address Requirements . . . . . . . . . . . . 89 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 88
Appendix B. Extensibility for Future COSE Algorithms . . . . . . 90 A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 88
B.1. Format of 'ecdh_info_entry' . . . . . . . . . . . . . . . 91 A.2. Optional-to-Address Requirements . . . . . . . . . . . . 91
B.2. Format of 'key' . . . . . . . . . . . . . . . . . . . . . 92 Appendix B. Extensibility for Future COSE Algorithms . . . . . . 92
Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 93 B.1. Format of 'ecdh_info_entry' . . . . . . . . . . . . . . . 93
C.1. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 93 B.2. Format of 'key' . . . . . . . . . . . . . . . . . . . . . 94
C.2. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 93 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 95
C.3. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 94 C.1. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 95
C.4. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 95 C.2. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 95
C.5. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 95 C.3. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 95
C.6. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 96 C.4. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 96
C.7. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 96 C.5. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 97
C.8. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 96 C.6. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 97
C.9. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 97 C.7. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 98
C.10. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 98 C.8. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 98
C.11. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 98 C.9. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 99
C.12. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 99 C.10. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 99
C.13. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 99 C.11. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 100
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 100 C.12. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100 C.13. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 101
C.14. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 102
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 102
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 102
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) Signing and Encryption (COSE)
[I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and
enabling end-to-end security of CoAP payload and options. enabling end-to-end security of CoAP payload and options.
As described in [I-D.ietf-core-oscore-groupcomm], 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
[I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which [I-D.ietf-core-groupcomm-bis], which can employ, for example, IP
is responsible for managing an OSCORE group and enables the group multicast as underlying data transport. This relies on a Group
members to exchange CoAP messages secured with Group OSCORE. The Manager, which is responsible for managing an OSCORE group and
Group Manager can be responsible for multiple groups, coordinates the enables the group members to exchange CoAP messages secured with
joining process of new group members, and is entrusted with the Group OSCORE. The Group Manager can be responsible for multiple
distribution and renewal of group keying material. groups, coordinates the joining process of new group members, and is
entrusted with the distribution and renewal of group keying material.
This document is an application profile of This document 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.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with: Readers are expected to be familiar with:
skipping to change at page 6, line 31 skipping to change at page 6, line 43
group members from the Group Manager. group members from the Group Manager.
* Signature-only group: an OSCORE group that uses only the group * Signature-only group: an OSCORE group that uses only the group
mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]). mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]).
* Pairwise-only group: an OSCORE group that uses only the pairwise * Pairwise-only group: an OSCORE group that uses only the pairwise
mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]).
2. Protocol Overview 2. Protocol Overview
Group communication for CoAP over IP multicast has been enabled in Group communication for CoAP has been enabled in
[I-D.ietf-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 (Group OSCORE) as
described in [I-D.ietf-core-oscore-groupcomm]. A network node joins specified 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 document describes how to use [I-D.ietf-ace-key-groupcomm] and This document describes how to use [I-D.ietf-ace-key-groupcomm] and
[I-D.ietf-ace-oauth-authz] to perform a number of authentication, [I-D.ietf-ace-oauth-authz] to perform a number of authentication,
authorization and key distribution actions, as overviewed in authorization and key distribution actions as overviewed in Section 2
Section 2 of [I-D.ietf-ace-key-groupcomm], when the considered group of [I-D.ietf-ace-key-groupcomm], when the considered group is
is specifically an OSCORE group. specifically an OSCORE group.
With reference to [I-D.ietf-ace-key-groupcomm]: With reference to [I-D.ietf-ace-key-groupcomm]:
* The node wishing to join the OSCORE group, i.e., the joining node, * The node wishing to join the OSCORE group, i.e., the joining node,
is the Client. is the Client.
* The Group Manager is the Key Distribution Center (KDC), acting as * The Group Manager is the Key Distribution Center (KDC), acting as
a Resource Server. a Resource Server.
* The Authorization Server associated with the Group Manager is the * The Authorization Server associated with the Group Manager is the
AS. AS.
A node performs the steps described in Sections 3 and 4.3.1.1 of
[I-D.ietf-ace-key-groupcomm] in order to obtain an authorization for
joining an OSCORE group and then to join that group. The format and
processing of messages exchanged during such steps are further
specified in Section 5 and Section 6 of this document.
All communications between the involved entities MUST be secured. All communications between the involved entities 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. It is expected that, in the commonly referred base- authentication. It is expected that, in the commonly referred base-
case of this document, the transport profile to use is pre-configured case of this document, the transport profile to use is pre-configured
and well-known to nodes participating in constrained applications. and well-known to nodes participating in constrained applications.
Appendix A lists the specifications on this application profile of With respect to what is defined in [I-D.ietf-ace-key-groupcomm]:
ACE, based on the requirements defined in Appendix A of
[I-D.ietf-ace-key-groupcomm].
2.1. Overview of the Joining Process
A node performs the steps described in Section 4.3.1.1 of
[I-D.ietf-ace-key-groupcomm] in order to join an OSCORE group. The
format and processing of messages exchanged among the participants
are further specified in Section 4 and Section 6 of this document.
2.2. Overview of the Group Rekeying Process
In a number of cases, the Group Manager has to generate new keying
material and distribute it to the group (rekeying), as also discussed
in Section 3.2 of [I-D.ietf-core-oscore-groupcomm].
To this end the Group Manager MUST support the Group Rekeying Process
described in Section 20 of this document, as an instance of the
"Point-to-Point" rekeying scheme defined in Section 6.1 of
[I-D.ietf-ace-key-groupcomm] and registered in Section 11.14 of
[I-D.ietf-ace-key-groupcomm]. Future documents may define the use of
alternative group rekeying schemes for this application profile,
together with the corresponding rekeying message formats. The
resulting group rekeying process MUST comply with the functional
steps defined in Section 3.2 of [I-D.ietf-core-oscore-groupcomm].
Upon generating the new group keying material and before starting its
distribution, the Group Manager MUST increment the version number of
the group keying material. When rekeying a group, the Group Manager
MUST preserve the current value of the OSCORE Sender ID of each
member in that group.
The data distributed to a group through a rekeying MUST include:
* The new version number of the group keying material for the group.
* A new Group Identifier (Gid) for the group as introduced in
[I-D.ietf-ace-key-groupcomm], used as ID Context parameter of the
Group OSCORE Common Security Context of that group (see Section 2
of [I-D.ietf-core-oscore-groupcomm]).
Note that the Gid differs from the group name also introduced in
[I-D.ietf-ace-key-groupcomm], which is a plain, stable and
invariant identifier, with no cryptographic relevance and meaning.
* A new value for the Master Secret parameter of the Group OSCORE
Common Security Context of the group (see Section 2 of
[I-D.ietf-core-oscore-groupcomm]).
* A set of stale Sender IDs, which allows each rekeyed node to purge
authentication credentials and Recipient Contexts used in the
group and associated with those Sender IDs. This in turn allows
every group member to rely on stored authentication credentials to
confidently assert the group membership of other sender nodes,
when receiving protected messages in the group (see Section 3.2 of
[I-D.ietf-core-oscore-groupcomm]). More details on the
maintenance of stale Sender IDs are provided in Section 2.2.1.
Also, the data distributed through a group rekeying MAY include a new
value for the Master Salt parameter of the Group OSCORE Common
Security Context of that group.
The Group Manager MUST rekeying the group in the following cases.
* The application requires backward security - In this case, the
group is rekeyed when a node joins the group as a new member.
Therefore, a joining node cannot access communications in the
group prior its joining.
* One or more nodes leave the group - That is, the group is rekeyed
when one or more current members spontaneously request to leave
the group (see Section 18), or when the Group Manager forcibly
evicts them from the group, e.g., due to expired or revoked
authorization (see Section 19). Therefore, a leaving node cannot
access communications in the group after its leaving, thus
ensuring forward security in the group.
Due to the set of stale Sender IDs distributed through the
rekeying, this ensures that a node owning the latest group keying
material does not store the authentication credentials of former
group members (see Sections 3.2 and 12.1 of
[I-D.ietf-core-oscore-groupcomm]).
* Extension of group lifetime - That is, the group is rekeyed when
the expiration time for the group keying material approaches or
has passed, if it is appropriate to extend the group operation
beyond that.
The Group Manager MAY rekey the group for other reasons, e.g.,
according to an application-dependent rekeying period or scheduling.
2.2.1. Stale OSCORE Sender IDs
Throughout the lifetime of every group, the Group Manager MUST
maintain a collection of stale Sender IDs for that group.
The collection associated with a group MUST include up to N > 1
ordered sets of stale OSCORE Sender IDs. It is up to the application
to specify the value of N, possibly on a per-group basis.
The N-th set includes the Sender IDs that have become "stale" under
the current version V of the group keying material. The (N-1)-th set
refers to the immediately previous version (V - 1) of the group
keying material, and so on.
In the following cases, the Group Manager MUST add a new element to
the most recent set X, i.e., the set associated with the current
version V of the group keying material.
* When a current group member obtains a new Sender ID, its old
Sender ID is added to X. This happens when the Group Manager
assigns a new Sender ID upon request from the group member (see
Section 9), or in case the group member re-joins the group (see
Section 6.2 and Section 6.4), thus also obtaining a new Sender ID.
* When a current group member leaves the group, its current Sender
ID is added to X. This happens when a group member requests to
leave the group (see Section 18) or is forcibly evicted from the
group (see Section 19).
The value of N can change throughout the lifetime of the group. If
the new value N' is smaller than N, the Group Manager MUST preserve
the (up to) N' most recent sets in the collection and MUST delete any
possible older set from the collection.
Finally, the Group Manager MUST perform the following actions, when
the group is rekeyed and the group shifts to the next version V' = (V
+ 1) of the group keying material.
1. The Group Manager rekeys the group. This includes also * The interface provided by the Group Manager extends the original
distributing the set of stale Sender IDs X associated with the interface defined in Section 4.1 of [I-D.ietf-ace-key-groupcomm]
old group keying material with version V (see Section 2.2). for the KDC, as specified in Section 8 of this document.
2. After completing the group rekeying, the Group Manager creates a * In addition to those defined in Section 8 of
new empty set X' associated with the new version V' of the newly [I-D.ietf-ace-key-groupcomm], additional parameters are defined in
established group keying material, i.e., V' = (V + 1). this document and summarized in Section 12.
3. If the current collection of stale Sender IDs has size N, the * In addition to those defined in Section 9 of
Group Manager deletes the oldest set in the collection. [I-D.ietf-ace-key-groupcomm], additional error identifiers are
defined in this document and summarized in Section 13.
4. The Group Manager adds the new set X' to the collection of stale Finally, Appendix A lists the specifications on this application
Sender IDs, as the most recent set. profile of ACE, based on the requirements defined in Appendix A of
[I-D.ietf-ace-key-groupcomm].
3. Format of Scope 3. Format of Scope
Building on Section 3.1 of [I-D.ietf-ace-key-groupcomm], this section Building on Section 3.1 of [I-D.ietf-ace-key-groupcomm], this section
defines the exact format and encoding of scope to use. defines the exact format and encoding of scope used in this profile.
To this end, this profile uses the Authorization Information Format To this end, this profile uses the Authorization Information Format
(AIF) [I-D.ietf-ace-aif], and defines the following AIF specific data (AIF) [I-D.ietf-ace-aif]. In particular, with reference to the
model AIF-OSCORE-GROUPCOMM. generic AIF model
With reference to the generic AIF model
AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]] AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
the value of the CBOR byte string used as scope encodes the CBOR the value of the CBOR byte string used as scope encodes the CBOR
array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds
to one scope entry. to one scope entry.
Then, for each scope entry: Furthermore, this document defines the new AIF specific data model
AIF-OSCORE-GROUPCOMM, that this profile MUST use to format and encode
scope entries.
* the object identifier ("Toid") is specialized as a CBOR text In particular, the following holds for each scope entry.
string, specifying the group name for the scope entry;
* the permission set ("Tperm") is specialized as a CBOR unsigned * The object identifier ("Toid") is specialized as a CBOR item
integer with value R, specifying the role(s) that the client specifying the name of the groups pertaining to the scope entry.
wishes to take in the group (REQ1). The value R is computed as
follows:
- each role in the permission set is converted into the * The permission set ("Tperm") is specialized as a CBOR unsigned
integer with value R, specifying the permissions that the Client
wishes to have in the groups indicated by "Toid".
More specifically, the following applies when, as defined in this
document, a scope entry includes as set of permissions the set of
roles to take in an OSCORE group.
* The object identifier ("Toid") is a CBOR text string, specifying
the group name for the scope entry.
* The permission set ("Tperm") is a CBOR unsigned integer with value
R, specifying the role(s) that the Client wishes to take in the
group (REQ1). The value R is computed as follows.
- Each role in the permission set is converted into the
corresponding numeric identifier X from the "Value" column of corresponding numeric identifier X from the "Value" column of
the "Group OSCORE Roles" registry, for which this document the "Group OSCORE Roles" registry, for which this document
defines the entries in Figure 1. defines the entries in Figure 1.
- the set of N numbers is converted into the single value R, by - The set of N numbers is converted into the single value R, by
taking each numeric identifier X_1, X_2, ..., X_N to the power taking two to the power of each numeric identifier X_1, X_2,
of two, and then computing the inclusive OR of the binary ..., X_N, and then computing the inclusive OR of the binary
representations of all the power values. representations of all the power values.
+-----------+-------+-------------------------------------------------+ +-----------+-------+-------------------------------------------------+
| Name | Value | Description | | Name | Value | Description |
+===========+=======+=================================================+ +===========+=======+=================================================+
| Reserved | 0 | This value is reserved | | Reserved | 0 | This value is reserved |
|-----------+-------+-------------------------------------------------+ |-----------+-------+-------------------------------------------------+
| Requester | 1 | Send requests; receive responses | | Requester | 1 | Send requests; receive responses |
|-----------+-------+-------------------------------------------------+ |-----------+-------+-------------------------------------------------+
| Responder | 2 | Send responses; receive requests | | Responder | 2 | Send responses; receive requests |
+-----------+-------+-------------------------------------------------+ +-----------+-------+-------------------------------------------------+
| Monitor | 3 | Receive requests; never send requests/responses | | Monitor | 3 | Receive requests; never send requests/responses |
|-----------+-------+-------------------------------------------------| |-----------+-------+-------------------------------------------------|
| Verifier | 4 | Verify signature of intercepted messages | | Verifier | 4 | Verify signature of intercepted messages |
+-----------+-------+-------------------------------------------------+ +-----------+-------+-------------------------------------------------+
Figure 1: Numeric identifier of roles in the OSCORE group Figure 1: Numeric identifier of roles in an OSCORE group
The CDDL [RFC8610] definition of the AIF-OSCORE-GROUPCOMM data model The following CDDL [RFC8610] notation defines a scope entry that uses
is as follows: the AIF-OSCORE-GROUPCOMM data model and expresses a set of Group
OSCORE roles from those in Figure 1.
AIF-OSCORE-GROUPCOMM = AIF-Generic<gname, permissions> AIF-OSCORE-GROUPCOMM = AIF-Generic<oscore-gname, oscore-gperm>
gname = tstr ; Group name oscore-gname = tstr ; Group name
permissions = uint . bits roles oscore-gperm = uint . bits group-oscore-roles
roles = &(
group-oscore-roles = &(
Requester: 1, Requester: 1,
Responder: 2, Responder: 2,
Monitor: 3, Monitor: 3,
Verifier: 4 Verifier: 4
) )
Future specifications that define new roles MUST register a scope_entry = [oscore-gname, oscore-gperm]
corresponding numeric identifier in the "Group OSCORE Roles" registry
defined in Section 25.10 of this document.
4. Joining Node to Authorization Server Future specifications that define new Group OSCORE roles MUST
register a corresponding numeric identifier in the "Group OSCORE
Roles" registry defined in Section 16.10 of this document.
This section describes how the joining node interacts with the AS in Note that the value 0 is not available to use as numeric identifier
order to be authorized to join an OSCORE group under a given Group to specify a Group OSCORE role. It follows that, when expressing
Manager. In particular, it considers a joining node that intends to Group OSCORE roles to take in a group as per this document, a scope
contact that Group Manager for the first time. entry has the least significant bit of "Tperm" always set to 0.
The message exchange between the joining node and the AS consists of This is an explicit feature of the AIF-OSCORE-GROUPCOMM data model.
the messages Authorization Request and Authorization Response defined That is, for each scope entry, the least significant bit of "Tperm"
in Sections 3.1 and 3.2 of [I-D.ietf-ace-key-groupcomm]. Note that set to 0 explicitly identifies the scope entry as exactly expressing
what is defined in [I-D.ietf-ace-key-groupcomm] applies, and only a set of Group OSCORE roles ("Tperm"), pertaining to a single group
additions or modifications to that specification are defined here. whose name is specified by the string literal in "Toid".
4.1. Authorization Request Instead, by relying on the same AIF-OSCORE-GROUPCOMM data model,
[I-D.ietf-ace-oscore-gm-admin] defines the format of scope entries
for Administrator Clients that wish to access an admin interface at
the Group Manager. In such scope entries, the least significant bit
of "Tperm" is always set to 1.
4. Authentication Credentials
Source authentication of a message sent within the group and
protected with Group OSCORE is ensured by means of a digital
signature embedded in the message (in group mode), or by integrity-
protecting the message with pairwise keying material derived from the
asymmetric keys of sender and recipient (in pairwise mode).
Therefore, group members must be able to retrieve each other's
authentication credential from a trusted repository, in order to
verify source authenticity of incoming group messages.
As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group
Manager acts as trusted repository of the authentication credentials
of the group members, and provides those authentication credentials
to group members if requested to. Upon joining an OSCORE group, a
joining node is thus expected to provide its own authentication
credential to the Group Manager.
In particular, one of the following four cases can occur when a new
node joins an OSCORE group.
* The joining node is going to join the group exclusively as
monitor, i.e., it is not going to send messages to the group. In
this case, the joining node is not required to provide its own
authentication credential to the Group Manager, which thus does
not have to perform any check related to the format of the
authentication credential, to a signature or ECDH algorithm, and
to possible parameters associated with the algorithm and the
public key. In case the joining node still provides an
authentication credential in the 'client_cred' parameter of the
Joining Request (see Section 6.1), the Group Manager silently
ignores that parameter, as well as the related parameters 'cnonce'
and 'client_cred_verify'.
* The Group Manager already acquired the authentication credential
of the joining node during a past joining process. In this case,
the joining node MAY choose not to provide again its own
authentication credential to the Group Manager, in order to limit
the size of the Joining Request. The joining node MUST provide
its own authentication credential again if it has provided the
Group Manager with multiple authentication credentials during past
joining processes, intended for different OSCORE groups. If the
joining node provides its own authentication credential, the Group
Manager performs consistency checks as per Section 6.2 and, in
case of success, considers it as the authentication credential
associated with the joining node in the OSCORE group.
* The joining node and the Group Manager use an asymmetric proof-of-
possession key to establish a secure communication association.
Then, two cases can occur.
1. When establishing the secure communication association, the
Group Manager obtained from the joining node the joining
node's authentication credential, in the format used in the
OSCORE group and including the asymmetric proof-of-possession
key as public key. Also, such authentication credential and
the proof-of-possession key are compatible with the signature
or ECDH algorithm, and possible associated parameters used in
the OSCORE group.
In this case, the Group Manager considers the authentication
credential as the one associated with the joining node in the
OSCORE group. If the joining node is aware that the
authentication credential and the public key included thereof
are also valid for the OSCORE group, then the joining node MAY
choose to not provide again its own authentication credential
to the Group Manager.
The joining node MUST provide again its own authentication
credential if it has provided the Group Manager with multiple
authentication credentials during past joining processes,
intended for different OSCORE groups. If the joining node
provides its own authentication credential in the
'client_cred' parameter of the Joining Request (see
Section 6.1), the Group Manager performs consistency checks as
per Section 6.2 and, in case of success, considers it as the
authentication credential associated with the joining node in
the OSCORE group.
2. The authentication credential is not in the format used in the
OSCORE group, or else the authentication credential and the
proof-of-possession key included as public key are not
compatible with the signature or ECDH algorithm, and possible
associated parameters used in the OSCORE group.
In this case, the joining node MUST provide a different
compatible authentication credential and public key included
thereof to the Group Manager in the 'client_cred' parameter of
the Joining Request (see Section 6.1). Then, the Group
Manager performs consistency checks on this latest provided
authentication credential as per Section 6.2 and, in case of
success, considers it as the authentication credential
associated with the joining node in the OSCORE group.
* The joining node and the Group Manager use a symmetric proof-of-
possession key to establish a secure communication association.
In this case, upon performing a joining process with that Group
Manager for the first time, the joining node specifies its own
authentication credential in the 'client_cred' parameter of the
Joining Request (see Section 6.1).
5. Authorization to Join a Group
This section builds on Section 3 of [I-D.ietf-ace-key-groupcomm] and
is organized as follows.
First, Section 5.1 and Section 5.2 describe how the joining node
interacts with the AS, in order to be authorized to join an OSCORE
group under a given Group Manager and to obtain an Access Token.
Then, Section 5.3 describes how the joining node transfers the
obtained Access Token to the Group Manager. The following considers
a joining node that intends to contact the Group Manager for the
first time.
Note that what is defined in Section 3 of
[I-D.ietf-ace-key-groupcomm] applies, and only additions or
modifications to that specification are defined in this document.
5.1. Authorization Request
The Authorization Request message is as 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.
* If the 'scope' parameter is present: * If the 'scope' parameter is present:
- The value of the CBOR byte string encodes a CBOR array, whose - The value of the CBOR byte string encodes a CBOR array, whose
format MUST follow the data model AIF-OSCORE-GROUPCOMM defined format MUST follow the data model AIF-OSCORE-GROUPCOMM defined
in Section 3. In particular, for each OSCORE group to join: in Section 3. In particular, for each OSCORE group to join:
o The group name is encoded as a CBOR text string. o The group name is encoded as a CBOR text string.
o The set of requested roles is expressed as a single CBOR o The set of requested roles is expressed as a single CBOR
unsigned integer. This is computed as defined in Section 3, unsigned integer. This is computed as defined in Section 3,
from the numerical abbreviations of each requested role from the numerical abbreviations of each requested role
defined in the "Group OSCORE Roles" registry, for which this defined in the "Group OSCORE Roles" registry, for which this
document defines the entry in Figure 1 (REQ1). document defines the entries in Figure 1 (REQ1).
4.2. Authorization Response 5.2. Authorization Response
The Authorization Response message is as 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:
* The AS MUST include the 'expires_in' parameter. Other means for * 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 document. scope of this document.
* The AS MUST include the 'scope' parameter, when the value included * 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 Authorization Request. In such a case, the second
scope entry MUST be present, and specifies the set of roles that element of each scope entry MUST be present, and specifies the set
the joining node is actually authorized to take in the OSCORE of roles that the joining node is actually authorized to take in
group for that scope entry, encoded as specified in Section 4.1. the OSCORE group for that scope entry, encoded as specified in
Section 5.1.
Furthermore, if the AS uses the extended format of scope defined in Furthermore, if the AS uses the extended format of scope defined in
Section 7 of [I-D.ietf-ace-key-groupcomm] for the 'scope' claim of Section 7 of [I-D.ietf-ace-key-groupcomm] for the 'scope' claim of
the Access Token, the first element of the CBOR sequence [RFC8742] the Access Token, the first element of the CBOR sequence [RFC8742]
MUST be the CBOR integer with value SEM_ID_TBD, defined in MUST be the CBOR integer with value SEM_ID_TBD, defined in
Section 25.12 of this document (REQ28). This indicates that the Section 16.12 of this document (REQ28). This indicates that the
second element of the CBOR sequence, as conveying the actual access second element of the CBOR sequence, as conveying the actual access
control information, follows the scope semantics defined for this control information, follows the scope semantics defined for this
application profile in Section 3 of this document. application profile in Section 3 of this document.
5. Interface at the Group Manager 5.3. Token Transferring
The Group Manager provides the interface defined in Section 4.1 of
[I-D.ietf-ace-key-groupcomm], with the additional sub-resources
defined from Section 5.1 to Section 5.3 of this document.
Furthermore, Section 5.4 provides a summary of the CoAP methods
admitted to access different resources at the Group Manager, for
nodes with different roles in the group or as non members (REQ11).
The GROUPNAME segment of the URI path MUST match with the group name
specified in the scope entry of the Access Token scope (i.e., 'gname'
in Section 3.1 of [I-D.ietf-ace-key-groupcomm]) (REQ7).
The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is
registered in Section 25.11 (REQ10), and can be used to describe
group-membership resources and its sub-resources at a Group Manager,
e.g., by using a link-format document [RFC6690].
Applications can use this common resource type to discover links to
group-membership resources for joining OSCORE groups, e.g., by using
the approach described in [I-D.tiloca-core-oscore-discovery].
5.1. ace-group/GROUPNAME/active
This resource implements a GET handler.
5.1.1. GET Handler
The handler expects a GET request.
In addition to what is defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm], the handler verifies that the
requesting client is a current member of the group. If the
verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
response. The response MUST have Content-Format set to application/
ace-groupcomm+cbor and is formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be
set to 0 ("Operation permitted only to group members").
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying the current status of the group, i.e.,
active or inactive. The payload of the response is formatted as
defined in Section 16.
The method to set the current group status is out of the scope of
this document, and is defined for the administrator interface of the
Group Manager specified in [I-D.ietf-ace-oscore-gm-admin].
5.2. ace-group/GROUPNAME/verif-data
This resource implements a GET handler.
5.2.1. GET Handler
The handler expects a GET request.
In addition to what is defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm], the Group Manager performs the
following checks.
If the requesting client is a current group member, the Group Manager
MUST reply with a 4.03 (Forbidden) error response. The response MUST
have Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be
set to 8 ("Operation permitted only to signature verifiers").
If GROUPNAME denotes a pairwise-only group, the Group Manager MUST
reply with a 4.00 (Bad Request) error response. The response MUST
have Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be
set to 7 ("Signatures not used in the group").
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allows also a signature
verifier to verify signatures of messages protected with the group
mode and sent to the group (see Sections 3.1 and 8.5 of
[I-D.ietf-core-oscore-groupcomm]). The response MUST have Content-
Format set to application/ace-groupcomm+cbor. The payload of the
response is a CBOR map, which is formatted as defined in Section 13.
5.3. ace-group/GROUPNAME/stale-sids
This resource implements a FETCH handler.
5.3.1. FETCH Handler
The handler expects a FETCH request, whose payload specifies a
version number of the group keying material, encoded as an unsigned
CBOR integer.
In addition to what is defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm], the handler verifies that the
requesting client is a current member of the group. If the
verification fails, the Group Manager MUST reply with a 4.03
(Forbidden) error response. The response MUST have Content-Format
set to application/ace-groupcomm+cbor and is formatted as defined in
Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the
'error' field MUST be set to 0 ("Operation permitted only to group
members").
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allows the requesting client
to delete the Recipient Contexts and authentication credentials
associated with former members of the group (see Section 3.2 of
[I-D.ietf-core-oscore-groupcomm]. The payload of the response is
formatted as defined in Section 20.3.1.
5.4. Admitted Methods
The table in Figure 2 summarizes the CoAP methods admitted to access
different resources at the Group Manager, for (non-)members of a
group with group name GROUPNAME, and considering different roles.
The last two rows of the table apply to a node with node name
NODENAME.
+---------------------------------+--------+-------+-------+-------+
| Resource | Type1 | Type2 | Type3 | Type4 |
+---------------------------------+--------+-------+-------+-------+
| ace-group/ | F | F | F | F |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/ | G Po | G Po | Po * | Po |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/active | G | G | - | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/verif-data | - | - | G | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/pub-key | G F | G F | G F | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/kdc-pub-key | G | G | G | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/stale-sids | F | F | - | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/policies | G | G | - | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/num | G | G | - | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/nodes/ | G Pu D | G D | - | - |
| NODENAME | | | | |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/nodes/ | Po | - | - | - |
| NODENAME/pub-key | | | | |
+---------------------------------+--------+-------+-------+-------+
Type1 = Member as Requester and/or Responder | G = GET
Type2 = Member as Monitor | F = FETCH
Type3 = Non-member (authorized to be Verifier) | Po = POST
(*) = cannot join the group as Verifier | Pu = PUT
Type4 = Non-member (not authorized to be Verifier) | D = DELETE
Figure 2: Admitted CoAP Methods on the Group Manager Resources
5.5. Operations Supported by Clients
Building on what is defined in Section 4.1.1 of
[I-D.ietf-ace-key-groupcomm], and with reference to the resources at
the Group Manager newly defined earlier in Section 5 of this
document, it is expected that a Client minimally supports also the
following set of operations and corresponding interactions with the
Group (REQ12).
* GET request to ace-group/GROUPNAME/active , in order to check the
current status of the group.
* GET request to ace-group/GROUPNAME/verif-data , in order for a
signature verifier to retrieve data required to verify signatures
of messages protected with the group mode of Group OSCORE and sent
to a group (see Sections 3.1 and 8.5 of
[I-D.ietf-core-oscore-groupcomm]). Note that this operation is
relevant to support only to signature verifiers.
* FETCH request to ace-group/GROUPNAME/stale-sids , in order to
retrieve from the Group Manager the data required to delete some
of the stored group members' authentication credentials and
Recipient Contexts (see Section 5.3.1). This data is provided as
an aggregated set of stale Sender IDs, which are used as specified
in Section 20.3.
6. Token Transferring and Group Joining
The rest of this section describes the interactions between the
joining node and the Group Manager, i.e., the transferring of the
Access Token to the Group Manager and the Request-Response exchange
to join the OSCORE group. The message exchange between the joining
node and the Group Manager consists of the messages defined in
Sections 3.3 and 4.3.1.1 of [I-D.ietf-ace-key-groupcomm]. Note that
what is defined in [I-D.ietf-ace-key-groupcomm] applies, and only
additions or modifications to that specification are defined here.
Just like any candidate group member, a signature verifier provides
the Group Manager with an Access Token, as described in Section 6.1.
However, unlike candidate group members, it does not join any OSCORE
group, i.e., it does not perform the joining process defined in
Section 6.2.
After successfully transferring an Access Token to the Group Manager,
a signature verifier is allowed to perform only some operations as
non-member of a group, and only for the OSCORE groups specified in
the validated Access Token. These are the operations specified in
Section 10, Section 12, Section 13 and Section 17.
Consistently, in case a node is non-member of the group with group
name GROUPNAME and is authorized to be only signature verifier for
that group, the Group Manager MUST reply with a 4.03 (Forbidden)
error response if that node attempts to access any other endpoint
than: /ace-group/GROUPNAME/pub-key; ace-group/GROUPNAME/gm-pub-key;
ace-group/GROUPNAME/verif-data; and /ace-group.
6.1. Token Transferring
The exchange of Token Transfer Request and Response is defined in The exchange of Token Transfer Request and Token Transfer Response is
Section 3.3 of [I-D.ietf-ace-key-groupcomm]. In addition to that, defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm]. In addition
the following applies. to that, the following applies.
* The Token Transfer Request MAY additionally contain the following * The Token Transfer Request MAY additionally contain the following
parameters, which, if included, MUST have the corresponding values parameters, which, if included, MUST have the corresponding values
(OPT2): defined below (OPT2):
- 'ecdh_info' defined in Section 6.1.1 of this document, with - 'ecdh_info' defined in Section 5.3.1 of this document, with
value the CBOR simple value "null" (0xf6) to request value the CBOR simple value "null" (0xf6) to request
information about the ECDH algorithm, the ECDH algorithm information about the ECDH algorithm, the ECDH algorithm
parameters, the ECDH key parameters and about the exact format parameters, the ECDH key parameters and the exact format of
of authentication credentials used in the groups that the authentication credentials used in the groups that the Client
client has been authorized to join. This is relevant in case has been authorized to join. This is relevant in case the
the joining node supports the pairwise mode of Group OSCORE joining node supports the pairwise mode of Group OSCORE
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
- 'kdc_dh_creds' defined in Section 6.1.2 of this document, with - 'kdc_dh_creds' defined in Section 5.3.2 of this document, with
value the CBOR simple value "null" (0xf6) to request the value the CBOR simple value "null" (0xf6) to request the
Diffie-Hellman authentication credentials of the Group Manager Diffie-Hellman authentication credentials of the Group Manager
for the groups that the client has been authorized to join. for the groups that the Client has been authorized to join.
That is, each of such authentication credentials includes a That is, each of such authentication credentials includes a
Diffie-Hellman public key of the Group Manager. This is Diffie-Hellman public key of the Group Manager. This is
relevant in case the joining node supports the pairwise mode of relevant in case the joining node supports the pairwise mode of
Group OSCORE [I-D.ietf-core-oscore-groupcomm]. Group OSCORE [I-D.ietf-core-oscore-groupcomm].
Alternatively, the joining node may retrieve this information by Alternatively, the joining node may retrieve this information by
other means. other means.
* The 'kdcchallenge' parameter contains a dedicated nonce N_S * The 'kdcchallenge' parameter contains a dedicated nonce N_S
generated by the Group Manager. For the N_S value, it is generated by the Group Manager. For the N_S value, it is
RECOMMENDED to use a 8-byte long random nonce. The joining node RECOMMENDED to use a 8-byte long random nonce. The joining node
can use this nonce in order to prove the possession of its own can use this nonce in order to prove the possession of its own
private key, upon joining the group (see Section 6.2). private key, upon joining the group (see Section 6.1).
The 'kdcchallenge' parameter MAY be omitted from the Token The 'kdcchallenge' parameter MAY be omitted from the Token
Transfer Response, if the 'scope' of the Access Token specifies Transfer Response, if the 'scope' of the Access Token specifies
only the role "monitor" or only the role "verifier" or only a only the role "monitor" or only the role "verifier" or only the
combination of the two, for each and every of the specified two roles combined, for each and every of the specified groups.
groups.
* If the 'sign_info' parameter is present in the response, the * If the 'sign_info' parameter is present in the response, the
following applies for each element 'sign_info_entry'. following applies for each element 'sign_info_entry'.
- 'id' MUST NOT refer to OSCORE groups that are pairwise-only - 'id' MUST NOT refer to OSCORE groups that are pairwise-only
groups. groups.
- 'sign_alg' takes value from the "Value" column of the "COSE - 'sign_alg' takes value from the "Value" column of the "COSE
Algorithms" registry [COSE.Algorithms]. Algorithms" registry [COSE.Algorithms].
skipping to change at page 20, line 8 skipping to change at page 15, line 48
considered in [I-D.ietf-cose-rfc8152bis-algs], i.e., with considered in [I-D.ietf-cose-rfc8152bis-algs], i.e., with
algorithms that have only the COSE key type as their COSE algorithms that have only the COSE key type as their COSE
capability. Appendix B of [I-D.ietf-ace-key-groupcomm] describes capability. Appendix B of [I-D.ietf-ace-key-groupcomm] describes
how the format of each 'sign_info_entry' can be generalized for how the format of each 'sign_info_entry' can be generalized for
possible future registered algorithms having a different set of possible future registered algorithms having a different set of
COSE capabilities. COSE capabilities.
* If 'ecdh_info' is included in the Token Transfer Request, the * If 'ecdh_info' is included in the Token Transfer Request, the
Group Manager SHOULD include the 'ecdh_info' parameter in the Group Manager SHOULD include the 'ecdh_info' parameter in the
Token Transfer Response, as per the format defined in Token Transfer Response, as per the format defined in
Section 6.1.1. Note that the field 'id' of each 'ecdh_info_entry' Section 5.3.1. Note that the field 'id' of each 'ecdh_info_entry'
specifies the name, or array of group names, for which that specifies the name, or array of group names, for which that
'ecdh_info_entry' applies to. 'ecdh_info_entry' applies to.
As an exception, the KDC MAY omit the 'ecdh_info' parameter in the As an exception, the KDC MAY omit the 'ecdh_info' parameter in the
Token Transfer Response even if 'ecdh_info' is included in the Token Transfer Response even if 'ecdh_info' is included in the
Token Transfer Request, in case all the groups that the Client is Token Transfer Request, in case all the groups that the Client is
authorized to join are signature-only groups. authorized to join are signature-only groups.
* If 'kdc_dh_creds' is included in the Token Transfer Request and * If 'kdc_dh_creds' is included in the Token Transfer Request and
any of the groups that the client has been authorized to join is a any of the groups that the Client has been authorized to join is a
pairwise-only group, then the Group Manager MUST include the pairwise-only group, then the Group Manager MUST include the
'kdc_dh_creds' parameter in the Token Transfer Response, as per 'kdc_dh_creds' parameter in the Token Transfer Response, as per
the format defined in Section 6.1.2. Otherwise, if 'kdc_dh_creds' the format defined in Section 5.3.2. Otherwise, if 'kdc_dh_creds'
is included in the Token Transfer Request, the Group Manager MAY is included in the Token Transfer Request, the Group Manager MAY
include the 'kdc_dh_creds' parameter in the Token Transfer include the 'kdc_dh_creds' parameter in the Token Transfer
Response. Note that the field 'id' specifies the group name, or Response. Note that the field 'id' specifies the group name, or
array of group names, for which the corresponding 'kdc_dh_creds' array of group names, for which the corresponding 'kdc_dh_creds'
applies to. applies to.
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 obtained such information by alternative means. For example, have obtained such information by alternative means. For example,
information conveyed in the 'sign_info' and 'ecdh_info' parameters information conveyed in the 'sign_info' and 'ecdh_info' parameters
may have been pre-configured, or the joining node MAY early retrieve may have been pre-configured, or the joining node MAY early retrieve
it by using the approach described in it by using the approach described in
[I-D.tiloca-core-oscore-discovery], to discover the OSCORE group and [I-D.tiloca-core-oscore-discovery], to discover the OSCORE group and
the link to the associated group-membership resource at the Group the link to the associated group-membership resource at the Group
Manager (OPT3). Manager (OPT3).
6.1.1. 'ecdh_info' Parameter 5.3.1. 'ecdh_info' Parameter
The 'ecdh_info' parameter is an OPTIONAL parameter of the request and The 'ecdh_info' parameter is an OPTIONAL parameter of the request and
response messages exchanged between the client and the authz-info response messages exchanged between the Client and the authz-info
endpoint at the RS (see Section 5.10.1. of endpoint at the RS (see Section 5.10.1. of
[I-D.ietf-ace-oauth-authz]). [I-D.ietf-ace-oauth-authz]).
This parameter allows the client and the RS to exchange information This parameter allows the Client and the RS to exchange information
about an ECDH algorithm as well as about the authentication about an ECDH algorithm as well as about the authentication
credentials and public keys to accordingly use for deriving Diffie- credentials and public keys to accordingly use for deriving Diffie-
Hellman secrets. Its exact semantics and content are application Hellman secrets. Its exact semantics and content are application
specific. specific.
In this application profile, this parameter is used to exchange In this application profile, this parameter is used to exchange
information about the ECDH algorithm as well as about the information about the ECDH algorithm as well as about the
authentication credentials and public keys to be used with it, in the authentication credentials and public keys to be used with it, in the
groups indicated by the transferred Acces Token as per its 'scope' groups indicated by the transferred Acces Token as per its 'scope'
claim (see Section 3.2 of [I-D.ietf-ace-key-groupcomm]). claim (see Section 3.2 of [I-D.ietf-ace-key-groupcomm]).
When used in the Token Transfer Request sent to the Group Manager, When used in the Token Transfer Request sent to the Group Manager,
the 'ecdh_info' parameter has value the CBOR simple value "null" the 'ecdh_info' parameter has value the CBOR simple value "null"
(0xf6). This is done to ask for information about the ECDH algorithm (0xf6). This is done to ask for information about the ECDH algorithm
as well as about the authentication credentials and public keys to be as well as about the authentication credentials and public keys to be
used to compute static-static Diffie-Hellman shared secrets used to compute static-static Diffie-Hellman shared secrets
[NIST-800-56A], in the OSCORE groups that the client has been [NIST-800-56A], in the OSCORE groups that the Client has been
authorized to join and that use the pairwise mode of Group OSCORE authorized to join and that use the pairwise mode of Group OSCORE
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
When used in the following Token Transfer Response from the Group When used in the following Token Transfer Response from the Group
Manager, the 'ecdh_info' parameter is a CBOR array of one or more Manager, the 'ecdh_info' parameter is a CBOR array of one or more
elements. The number of elements is at most the number of OSCORE elements. The number of elements is at most the number of OSCORE
groups that the client has been authorized to join. groups that the Client has been authorized to join.
Each element contains information about ECDH parameters as well as Each element contains information about ECDH parameters as well as
about authentication credentials and public keys, for one or more about authentication credentials and public keys, for one or more
OSCORE groups that use the pairwise mode of Group OSCORE and that the OSCORE groups that use the pairwise mode of Group OSCORE and that the
client has been authorized to join. Each element is formatted as Client has been authorized to join. Each element is formatted as
follows. follows.
* The first element 'id' is the group name of the OSCORE group or an * The first element 'id' is the group name of the OSCORE group or an
array of group names for the OSCORE groups for which the specified array of group names for the OSCORE groups for which the specified
information applies. In particular 'id' MUST NOT refer to OSCORE information applies. In particular 'id' MUST NOT refer to OSCORE
groups that are signature-only groups. groups that are signature-only groups.
* The second element 'ecdh_alg' is a CBOR integer or a CBOR text * The second element 'ecdh_alg' is a CBOR integer or a CBOR text
string indicating the ECDH algorithm used in the OSCORE group string indicating the ECDH algorithm used in the OSCORE group
identified by 'gname'. Values are taken from the "Value" column identified by 'gname'. Values are taken from the "Value" column
skipping to change at page 22, line 16 skipping to change at page 18, line 7
"COSE Key Types" registry [COSE.Key.Types]. "COSE Key Types" registry [COSE.Key.Types].
* The fifth element 'cred_fmt' is a CBOR integer indicating the * The fifth element 'cred_fmt' is a CBOR integer indicating the
format of authentication credentials used in the OSCORE group format of authentication credentials used in the OSCORE group
identified by 'gname'. It takes value from the "Label" column of identified by 'gname'. It takes value from the "Label" column of
the "COSE Header Parameters" registry [COSE.Header.Parameters] the "COSE Header Parameters" registry [COSE.Header.Parameters]
(REQ6). Acceptable values denote a format that MUST provide the (REQ6). Acceptable values denote a format that MUST provide the
public key as well as the comprehensive set of information related public key as well as the comprehensive set of information related
to the public key algorithm, including, e.g., the used elliptic to the public key algorithm, including, e.g., the used elliptic
curve (when applicable). The same considerations and guidelines curve (when applicable). The same considerations and guidelines
for the 'pub_key_enc' element of 'sign_info' (see Section 6.1) for the 'pub_key_enc' element of 'sign_info' apply (see
apply. Section 5.3).
The CDDL notation [RFC8610] of the 'ecdh_info' parameter is given The CDDL notation [RFC8610] of the 'ecdh_info' parameter is given
below. below.
ecdh_info = ecdh_info_req / ecdh_info_resp ecdh_info = ecdh_info_req / ecdh_info_resp
ecdh_info_req = null ; in the Token Transfer ecdh_info_req = null ; in the Token Transfer
; Request to the KDC ; Request to the
; Group Manager
ecdh_info_res = [ + ecdh_info_entry ] ; in the Token Transfer ecdh_info_res = [ + ecdh_info_entry ] ; in the Token Transfer
; Response from the KDC ; Response from the
; Group Manager
ecdh_info_entry = ecdh_info_entry =
[ [
id : gname / [ + gname ], id : gname / [ + gname ],
ecdh_alg : int / tstr, ecdh_alg : int / tstr,
ecdh_parameters : [ any ], ecdh_parameters : [ any ],
ecdh_key_parameters : [ any ], ecdh_key_parameters : [ any ],
cred_fmt = int cred_fmt = int
] ]
gname = tstr gname = tstr
This format is consistent with every ECDH algorithm currently defined This format is consistent with every ECDH algorithm currently defined
in [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have in [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have
only the COSE key type as their COSE capability. Appendix B of this only the COSE key type as their COSE capability. Appendix B of this
document describes how the format of each 'ecdh_info_entry' can be document describes how the format of each 'ecdh_info_entry' can be
generalized for possible future registered algorithms having a generalized for possible future registered algorithms having a
different set of COSE capabilities. different set of COSE capabilities.
6.1.2. 'kdc_dh_creds' Parameter 5.3.2. 'kdc_dh_creds' Parameter
The 'kdc_dh_creds' parameter is an OPTIONAL parameter of the request The 'kdc_dh_creds' parameter is an OPTIONAL parameter of the request
and response messages exchanged between the Client and the authz-info and response messages exchanged between the Client and the authz-info
endpoint at the RS (see Section 5.10.1. of endpoint at the RS (see Section 5.10.1. of
[I-D.ietf-ace-oauth-authz]). [I-D.ietf-ace-oauth-authz]).
This parameter allows the client to request and retrieve the Diffie- This parameter allows the Client to request and retrieve the Diffie-
Hellman authentication credentials of the RS, i.e., authentication Hellman authentication credentials of the RS, i.e., authentication
credentials including a Diffie-Hellman public key of the RS. credentials including a Diffie-Hellman public key of the RS.
In this application profile, this parameter is used to request and In this application profile, this parameter is used to request and
retrieve from the Group Manager its Diffie-Hellman authentication retrieve from the Group Manager its Diffie-Hellman authentication
credentials to use, in the OSCORE groups that the client has been credentials to use, in the OSCORE groups that the Client has been
authorized to join. The Group Manager has specifically a Diffie- authorized to join. The Group Manager has specifically a Diffie-
Hellman authentication credential in an OSCORE group, and thus a Hellman authentication credential in an OSCORE group, and thus a
Diffie-Hellman public key in that group, if and only if the group is Diffie-Hellman public key in that group, if and only if the group is
a pairwise-only group. In this case, the early retrieval of the a pairwise-only group. In this case, the early retrieval of the
Group Manager's authentication credential is necessary in order for Group Manager's authentication credential is necessary in order for
the joining node to prove the possession of its own private key, upon the joining node to prove the possession of its own private key, upon
joining the group (see Section 6.2). joining the group (see Section 6.1).
When used in the Token Transfer Request sent to the Group Manager, When used in the Token Transfer Request sent to the Group Manager,
the 'kdc_dh_creds' parameter has value the CBOR simple value "null" the 'kdc_dh_creds' parameter has value the CBOR simple value "null"
(0xf6). This is done to ask for the Diffie-Hellman authentication (0xf6). This is done to ask for the Diffie-Hellman authentication
credentials that the Group Manager uses in the OSCORE groups that the credentials that the Group Manager uses in the OSCORE groups that the
client has been authorized to join. Client has been authorized to join.
When used in the following Token Transfer Response from the Group When used in the following Token Transfer Response from the Group
Manager, the 'kdc_dh_creds' parameter is a CBOR array of one or more Manager, the 'kdc_dh_creds' parameter is a CBOR array of one or more
elements. The number of elements is at most the number of OSCORE elements. The number of elements is at most the number of OSCORE
groups that the client has been authorized to join. groups that the Client has been authorized to join.
Each element 'kdc_dh_creds_entry' contains information about the Each element 'kdc_dh_creds_entry' contains information about the
Group Manager's Diffie-Hellman authentication credentials, for one or Group Manager's Diffie-Hellman authentication credentials, for one or
more OSCORE groups that are pairwise-only groups and that the client more OSCORE groups that are pairwise-only groups and that the Client
has been authorized to join. Each element is formatted as follows. has been authorized to join. Each element is formatted as follows.
* The first element 'id' is the group name of the OSCORE group or an * The first element 'id' is the group name of the OSCORE group or an
array of group names for the OSCORE groups for which the specified array of group names for the OSCORE groups for which the specified
information applies. In particular 'id' MUST refer exclusively to information applies. In particular 'id' MUST refer exclusively to
OSCORE groups that are pairwise-only groups. OSCORE groups that are pairwise-only groups.
* The second element 'cred_fmt' is a CBOR integer indicating the * The second element 'cred_fmt' is a CBOR integer indicating the
format of authentication credentials used in the OSCORE group format of authentication credentials used in the OSCORE group
identified by 'gname'. It takes value from the "Label" column of identified by 'gname'. It takes value from the "Label" column of
the "COSE Header Parameters" registry [COSE.Header.Parameters] the "COSE Header Parameters" registry [COSE.Header.Parameters]
(REQ6). Acceptable values denote a format that MUST explicitly (REQ6). Acceptable values denote a format that MUST explicitly
provide the public key as well as comprehensive set of information provide the public key as well as comprehensive set of information
related to the public key algorithm, including, e.g., the used related to the public key algorithm, including, e.g., the used
elliptic curve (when applicable). The same considerations and elliptic curve (when applicable). The same considerations and
guidelines for the 'pub_key_enc' element of 'sign_info' (see guidelines for the 'pub_key_enc' element of 'sign_info' apply (see
Section 6.1) apply. Section 5.3).
* The third element 'cred' is a CBOR byte string, which encodes the * The third element 'cred' is a CBOR byte string, which encodes the
Group Manager's Diffie-Hellman authentication credential in its Group Manager's Diffie-Hellman authentication credential in its
original binary representation made available to other endpoints original binary representation made available to other endpoints
in the group. In particular, the original binary representation in the group. In particular, the original binary representation
complies with the format specified by the 'cred_fmt' element. complies with the format specified by the 'cred_fmt' element.
Note that the authentication credential provides the comprehensive Note that the authentication credential provides the comprehensive
set of information related to its public key algorithm, i.e., the set of information related to its public key algorithm, i.e., the
ECDH algorithm used in the OSCORE group as pairwise key agreement ECDH algorithm used in the OSCORE group as pairwise key agreement
algorithm. algorithm.
The CDDL notation [RFC8610] of the 'kdc_dh_creds' parameter is given The CDDL notation [RFC8610] of the 'kdc_dh_creds' parameter is given
below. below.
kdc_dh_creds = kdc_dh_creds_req / kdc_dh_creds_resp kdc_dh_creds = kdc_dh_creds_req / kdc_dh_creds_resp
skipping to change at page 24, line 42 skipping to change at page 20, line 32
kdc_dh_creds_entry = kdc_dh_creds_entry =
[ [
id : gname / [ + gname ], id : gname / [ + gname ],
cred_fmt = int, cred_fmt = int,
cred = bstr cred = bstr
] ]
gname = tstr gname = tstr
6.2. Send the Joining Request 6. Group Joining
This section describes the interactions between the joining node and
the Group Manager to join an OSCORE group. The message exchange
between the joining node and the Group Manager consists of the
messages defined in Section 4.3.1.1 of [I-D.ietf-ace-key-groupcomm].
Note that what is defined in [I-D.ietf-ace-key-groupcomm] applies,
and only additions or modifications to that specification are defined
in this document.
6.1. Send the Joining Request
The joining node requests to join the OSCORE group by sending a The joining node requests to join the OSCORE group by sending a
Joining Request message to the related group-membership resource at Joining Request message to the related group-membership resource at
the Group Manager, as per Section 4.3.1.1 of the Group Manager, as per Section 4.3.1.1 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm]. Additionally to what is defined in
Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], the following applies.
Additionally to what defined in Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm], the following applies.
* The 'scope' parameter MUST be included. Its value encodes one * The 'scope' parameter MUST be included. Its value encodes one
scope entry with the format defined in Section 3, indicating the scope entry with the format defined in Section 3, indicating the
group name and the role(s) that the joining node wants to take in group name and the role(s) that the joining node wants to take in
the group. the group.
* The 'get_pub_keys' parameter is present only if the joining node * The 'get_pub_keys' parameter is present only if the joining node
wants to retrieve the authentication credentials of the group wants to retrieve the authentication credentials of the group
members from the Group Manager during the joining process (see members from the Group Manager during the joining process (see
Section 7). Otherwise, this parameter MUST NOT be present. Section 4). Otherwise, this parameter MUST NOT be present.
If this parameter is present and its value is not the CBOR simple If this parameter is present and its value is not the CBOR simple
value "null" (0xf6), each element of the inner CBOR array value "null" (0xf6), each element of the inner CBOR array
'role_filter' is encoded as a CBOR unsigned integer, with the same 'role_filter' is encoded as a CBOR unsigned integer, with the same
value of a permission set ("Tperm") indicating that role or value of a permission set ("Tperm") indicating that role or
combination of roles in a scope entry, as defined in Section 3. combination of roles in a scope entry, as defined in Section 3.
* 'cnonce' contains a dedicated nonce N_C generated by the joining * '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.
* The proof-of-possession (PoP) evidence included in * The proof-of-possession (PoP) evidence included in
'client_cred_verify' is computed as defined below (REQ14). In 'client_cred_verify' is computed as defined below (REQ14). In
either case, the N_S used to build the PoP input is as defined in either case, the N_S used to build the PoP input is as defined in
Section 6.2.1. Section 6.1.1.
- If the group is not a pairwise-only group, the PoP evidence - If the group is not a pairwise-only group, the PoP evidence
MUST be a signature. The joining node computes the signature MUST be a signature. The joining node computes the signature
by using the same private key and signature algorithm it by using the same private key and signature algorithm it
intends to use for signing messages in the OSCORE group. intends to use for signing messages in the OSCORE group.
- If the group is a pairwise-only group, the PoP evidence MUST be - If the group is a pairwise-only group, the PoP evidence MUST be
a MAC computed as follows, by using the HKDF Algorithm HKDF a MAC computed as follows, by using the HKDF Algorithm HKDF
SHA-256, which consists of composing the HKDF-Extract and HKDF- SHA-256, which consists of composing the HKDF-Extract and HKDF-
Expand steps [RFC5869]. Expand steps [RFC5869].
skipping to change at page 26, line 9 skipping to change at page 22, line 9
see Section 5.7.1.2 of [NIST-800-56A], using the ECDH see Section 5.7.1.2 of [NIST-800-56A], using the ECDH
algorithm used in the OSCORE group. The joining node uses algorithm used in the OSCORE group. The joining node uses
its own Diffie-Hellman private key and the Diffie-Hellman its own Diffie-Hellman private key and the Diffie-Hellman
public key of the Group Manager. For X25519 and X448, the public key of the Group Manager. For X25519 and X448, the
procedure is described in Section 5 of [RFC7748]. procedure is described in Section 5 of [RFC7748].
o info takes as value the PoP input. o info takes as value the PoP input.
o L is equal to 8, i.e., the size of the MAC, in bytes. o L is equal to 8, i.e., the size of the MAC, in bytes.
6.2.1. Value of the N_S Challenge 6.1.1. Value of the N_S Challenge
The value of the N_S challenge is determined as follows. The value of the N_S challenge is determined as follows.
1. If the joining node has provided the Access Token to the Group 1. If the joining node has provided the Access Token to the Group
Manager by means of a Token Transfer Request to the /authz-info Manager by means of a Token Transfer Request to the /authz-info
endpoint as in Section 6.1, then N_S takes the same value of the endpoint as in Section 5.3, then N_S takes the same value of the
most recent 'kdcchallenge' parameter received by the joining node most recent 'kdcchallenge' parameter received by the joining node
from the Group Manager. This can be either the one specified in from the Group Manager. This can be either the one specified in
the Token Transfer Response, or the one possibly specified in a the Token Transfer Response, or the one possibly specified in a
4.00 (Bad Request) error response to a following Joining Request 4.00 (Bad Request) error response to a following Joining Request
(see Section 6.3). (see Section 6.2).
2. If the provisioning of the Access Token to the Group Manager has 2. If the provisioning of the Access Token to the Group Manager has
relied on the DTLS profile of ACE [I-D.ietf-ace-dtls-authorize] relied on the DTLS profile of ACE [I-D.ietf-ace-dtls-authorize]
with the Access Token as content of the "psk_identity" field of with the Access Token as content of the "psk_identity" field of
the ClientKeyExchange message [RFC6347], N_S is an exporter value the ClientKeyExchange message [RFC6347], then N_S is an exporter
computed as defined in Section 7.5 of [RFC8446]. Specifically, value computed as defined in Section 7.5 of [RFC8446].
N_S is exported from the DTLS session between the joining node Specifically, N_S is exported from the DTLS session between the
and the Group Manager, using an empty 'context_value', 32 bytes joining node and the Group Manager, using an empty
as 'key_length', and the exporter label "EXPORTER-ACE-Sign- 'context_value', 32 bytes as 'key_length', and the exporter label
Challenge-coap-group-oscore-app" defined in Section 25.7 of this "EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app" defined in
document. Section 16.7 of this document.
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 24.3 provides security considerations on the reusage of the Section 15.3 provides security considerations on the reusage of the
N_S challenge. N_S challenge.
6.3. Receive the Joining Request 6.2. Receive 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.3.1 of [I-D.ietf-ace-key-groupcomm], with the following Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], with the following
additions. additions.
* The Group Manager MUST return a 5.03 (Service Unavailable) The Group Manager verifies the PoP evidence contained in
response in case the OSCORE group that the joining node has been 'client_cred_verify' as follows:
trying to join is currently inactive (see Section 5.1). The
response MUST have Content-Format set to application/ace-
groupcomm+cbor and is formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST
be set to 9 ("Group currently not active").
* In case the joining node is not going to join the group * As PoP input, the Group Manager uses the value of the 'scope'
exclusively as monitor, the Group Manager MUST return a 5.03 parameter from the Joining Request as a CBOR byte string,
(Service Unavailable) response if there are currently no OSCORE concatenated with N_S encoded as a CBOR byte string, concatenated
Sender IDs available to assign in the OSCORE group. The response with N_C encoded as a CBOR byte string. In particular, N_S is
MUST have Content-Format set to application/ace-groupcomm+cbor and determined as described in Section 6.1.1, while N_C is the nonce
is formatted as defined in Section 4.1.2 of provided in the 'cnonce' parameter of the Joining Request.
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST
be set to 4 ("No available node identifiers").
* In case the joining node is not going to join the group * As public key of the joining node, the Group Manager uses either
exclusively as monitor and the Joining Request does not include the one included in the authentication credential retrieved from
the 'client_cred' parameter, the joining process fails if the the 'client_cred' parameter of the Joining Request, or the one
Group Manager either: i) does not store an authentication from the already stored authentication credential as acquired from
credential with an accepted format for the joining node; or ii) previous interactions with the joining node (see Section 4).
stores multiple authentication credentials with an accepted format
for the joining node.
* In order to verify the PoP evidence contained in * If the group is not a pairwise-only group, the PoP evidence is a
'client_cred_verify', the Group Manager proceeds as follows. signature. The Group Manager verifies it by using the public key
of the joining node, as well as the signature algorithm used in
the OSCORE group and possible corresponding parameters.
- As PoP input, the Group Manager uses the value of the 'scope' * If the group is a pairwise-only group, the PoP evidence is a MAC.
parameter from the Joining Request as a CBOR byte string, The Group Manager recomputes the MAC through the same process
concatenated with N_S encoded as a CBOR byte string, taken by the joining node when preparing the value of the
concatenated with N_C encoded as a CBOR byte string. In 'client_cred_verify' parameter for the Joining Request (see
particular, N_S is determined as described in Section 6.2.1, Section 6.1), with the difference that the Group Manager uses its
while N_C is the nonce provided in the 'cnonce' parameter of own Diffie-Hellman private key and the Diffie-Hellman public key
the Joining Request; of the joining node. The verification succeeds if and only if the
recomputed MAC is equal to the MAC conveyed as PoP evidence in the
Joining Request.
- As public key of the joining node, the Group Manager uses The Group Manager MUST reply with a 5.03 (Service Unavailable) error
either the one included in the authentication credential response in the following cases:
retrieved from the 'client_cred' parameter of the Joining
Request, or the one from the already stored authentication
credential as acquired from previous interactions with the
joining node.
- The Group Manager verifies the PoP evidence as defined below. * There are currently no OSCORE Sender IDs available to assign in
the OSCORE group and, at the same time, the joining node is not
going to join the group exclusively as monitor. The response MUST
have Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST
be set to 4 ("No available node identifiers").
o If the group is not a pairwise-only group, the PoP evidence * The OSCORE group that the joining node has been trying to join is
is a signature. The Group Manager verifies it by using the currently inactive (see Section 8.1). The response MUST have
public key of the joining node, as well as the signature Content-Format set to application/ace-groupcomm+cbor and is
algorithm used in the OSCORE group and possible formatted as defined in Section 4.1.2 of
corresponding parameters. [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST
be set to 9 ("Group currently not active").
o If the group is a pairwise-only group, the PoP evidence is a The Group Manager MUST reply with a 4.00 (Bad Request) error response
MAC. The Group Manager recomputes the MAC through the same in the following cases:
process taken by the joining node when preparing the value
of the 'client_cred_verify' parameter for the Joining
Request (see Section 6.2), with the difference that the
Group Manager uses its own Diffie-Hellman private key and
the Diffie-Hellman public key of the joining node. The
verification succeeds if and only if the recomputed MAC is
equal to the MAC conveyed as PoP evidence in the Joining
Request.
* A 4.00 (Bad Request) error response from the Group Manager to the * The 'client_cred' parameter is present in the Joining Request and
joining node MUST have content format application/ace- its value is not an eligible authentication credential (e.g., it
groupcomm+cbor. The response payload is a CBOR map formatted as is not of the format accepted in the group).
follows.
- If the group uses (also) the group mode of Group OSCORE, the * The 'client_cred' parameter is not present in the Joining Request
CBOR map MUST contain the 'sign_info' parameter, whose CBOR while the joining node is not going to join the group exclusively
label is defined in Section 8 of [I-D.ietf-ace-key-groupcomm]. as monitor, and any of the following conditions holds:
This parameter has the same format of 'sign_info_res' defined
in Section 3.3.1 of [I-D.ietf-ace-key-groupcomm]. In
particular, it includes a single element 'sign_info_entry'
pertaining to the OSCORE group that the joining node has tried
to join with the Joining Request.
- If the group uses (also) the pairwise mode of Group OSCORE, the - The Group Manager does not store an eligible authentication
CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR credential (e.g., of the format accepted in the group) for the
label is defined in Section 25.3. This parameter has the same joining node.
format of 'ecdh_info_res' defined in Section 6.1.1. In
particular, it includes a single element 'ecdh_info_entry'
pertaining to the OSCORE group that the joining node has tried
to join with the Joining Request.
- If the group is a pairwise-only group, the CBOR map MUST - The Group Manager stores multiple eligible authentication
contain the 'kdc_dh_creds' parameter, whose CBOR label is credentials (e.g., of the format accepted in the group) for the
defined in Section 25.3. This parameter has the same format of joining node.
'kdc_dh_creds_res' defined in Section 6.1.2. In particular, it
includes a single element 'kdc_dh_creds_entry' pertaining to
the OSCORE group that the joining node has tried to join with
the Joining Request.
- The CBOR map MAY include the 'kdcchallenge' parameter, whose * The 'scope' parameter is not present in the Joining Request, or it
CBOR label is defined in Section 8 of is present and specifies any set of roles not included in the
[I-D.ietf-ace-key-groupcomm]. If present, this parameter is a following list: "requester", "responder", "monitor", ("requester",
CBOR byte string, which encodes a newly generated "responder"). Future specifications that define a new role for
'kdcchallenge' value that the Client can use when preparing a members of OSCORE groups MUST define possible sets of roles
Joining Request (see Section 6.2). In such a case the Group (including the new role and existing roles) that are acceptable to
Manager MUST store the newly generated value as the specify in the 'scope' parameter of a Joining Request.
'kdcchallenge' value associated with the joining node, possibly
replacing the currently stored value.
* The Group Manager MUST reply with a 4.00 (Bad Request) error * The Joining Request includes the 'client_cred' parameter but does
response in case the 'scope' parameter is not present in the not include both the 'cnonce' and 'client_cred_verify' parameters.
Joining Request, or if it is present and specifies any set of
roles not included in the following list: "requester",
"responder", "monitor", ("requester", "responder"). Future
specifications that define a new role MUST define possible sets of
roles including the new one and existing ones, that are acceptable
to specify in the 'scope' parameter of a Joining Request.
* The Group Manager MUST reply with a 4.00 (Bad Request) error In order to prevent the acceptance of Ed25519 and Ed448 public keys
response in case the Joining Request includes the 'client_cred' that cannot be successfully converted to Montgomery coordinates, and
parameter but does not include both the 'cnonce' and thus cannot be used for the derivation of pairwise keys (see
'client_cred_verify' parameters. Section 2.4.1 of [I-D.ietf-core-oscore-groupcomm]), the Group Manager
MAY reply with a 4.00 (Bad Request) error response in case all the
following conditions hold:
* The Group Manager MUST reply with a 4.00 (Bad Request) error * The OSCORE group uses the pairwise mode of Group OSCORE.
response in case an eligible authentication credential for the
joining node is neither present in the 'client_cred' parameter nor
already stored.
* The Group Manager MAY reply with a 4.00 (Bad Request) error * The OSCORE group uses EdDSA public keys [RFC8032].
response in case all the following conditions hold.
- The OSCORE group uses the pairwise mode of Group OSCORE. * The authentication credential of the joining node from the
'client_cred' parameter includes a public key which:
- The OSCORE group uses EdDSA public keys [RFC8032]. - Is for the elliptic curve Ed25519 and has its Y coordinate
equal to -1 or 1 (mod p), with p = (2^255 - 19), see
Section 4.1 of [RFC7748]; or
- The authentication credential of the joining node from the - Is for the elliptic curve Ed448 and has its Y coordinate equal
'client_cred' parameter includes a public key which: to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see
Section 4.2 of [RFC7748].
o Is for the elliptic curve Ed25519 and has its Y coordinate A 4.00 (Bad Request) error response from the Group Manager to the
equal to -1 or 1 (mod p), with p = (2^255 - 19), see joining node MUST have content format application/ace-groupcomm+cbor.
Section 4.1 of [RFC7748]; or The response payload is a CBOR map formatted as follows:
o Is for the elliptic curve Ed448 and has its Y coordinate * If the group uses (also) the group mode of Group OSCORE, the CBOR
equal to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see map MUST contain the 'sign_info' parameter, whose CBOR label is
Section 4.2 of [RFC7748]. defined in Section 8 of [I-D.ietf-ace-key-groupcomm]. This
parameter has the same format of 'sign_info_res' defined in
Section 3.3.1 of [I-D.ietf-ace-key-groupcomm]. In particular, it
includes a single element 'sign_info_entry' pertaining to the
OSCORE group that the joining node has tried to join with the
Joining Request.
This prevents the acceptance of Ed25519 and Ed448 public keys that * If the group uses (also) the pairwise mode of Group OSCORE, the
cannot be successfully converted to Montgomery coordinates, and CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR label
thus cannot be used for the derivation of pairwise keys (see is defined in Section 16.3. This parameter has the same format of
Section 2.4.1 of [I-D.ietf-core-oscore-groupcomm]). 'ecdh_info_res' defined in Section 5.3.1. In particular, it
includes a single element 'ecdh_info_entry' pertaining to the
OSCORE group that the joining node has tried to join with the
Joining Request.
* When receiving a 4.00 (Bad Request) error response, the joining * If the group is a pairwise-only group, the CBOR map MUST contain
node SHOULD send a new Joining Request to the Group Manager, the 'kdc_dh_creds' parameter, whose CBOR label is defined in
where: Section 16.3. This parameter has the same format of
'kdc_dh_creds_res' defined in Section 5.3.2. In particular, it
includes a single element 'kdc_dh_creds_entry' pertaining to the
OSCORE group that the joining node has tried to join with the
Joining Request.
- The 'cnonce' parameter MUST include a new dedicated nonce N_C * The CBOR map MAY include the 'kdcchallenge' parameter, whose CBOR
generated by the joining node. label is defined in Section 8 of [I-D.ietf-ace-key-groupcomm]. If
present, this parameter is a CBOR byte string, which encodes a
newly generated 'kdcchallenge' value that the Client can use when
preparing a Joining Request (see Section 6.1). In such a case the
Group Manager MUST store the newly generated value as the
'kdcchallenge' value associated with the joining node, possibly
replacing the currently stored value.
- The 'client_cred' parameter MUST include an authentication 6.2.1. Follow-up to a 4.00 (Bad Request) Error Response
credential in the format indicated by the Group Manager. Also,
the authentication credential as well as the included public
key MUST be compatible with the signature or ECDH algorithm,
and possible associated parameters.
- The 'client_cred_verify' parameter MUST include a PoP evidence When receiving a 4.00 (Bad Request) error response, the joining node
computed as described in Section 6.2, by using the private key MAY send a new Joining Request to the Group Manager. In such a case:
associated with the authentication credential specified in the
current 'client_cred' parameter, with the signature or ECDH
algorithm, and possible associated parameters indicated by the
Group Manager. If the error response from the Group Manager
includes the 'kdcchallenge' parameter, the joining node MUST
use its content as new N_S challenge to compute the PoP
evidence.
6.4. Send the Joining Response * The 'cnonce' parameter MUST include a new dedicated nonce N_C
generated by the joining node.
If the processing of the Joining Request described in Section 6.3 is * The 'client_cred' parameter MUST include an authentication
credential in the format indicated by the Group Manager. Also,
the authentication credential as well as the included public key
MUST be compatible with the signature or ECDH algorithm, and
possible associated parameters.
* The 'client_cred_verify' parameter MUST include a PoP evidence
computed as described in Section 6.1, by using the private key
associated with the authentication credential specified in the
current 'client_cred' parameter, with the signature or ECDH
algorithm, and possible associated parameters indicated by the
Group Manager. If the error response from the Group Manager
includes the 'kdcchallenge' parameter, the joining node MUST use
its content as new N_S challenge to compute the PoP evidence.
6.3. Send the Joining Response
If the processing of the Joining Request described in Section 6.2 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.3.1 of group GROUPNAME, as described in Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
If the joining node has not taken exclusively the role of monitor, If the joining node has not taken exclusively the role of monitor,
the Group Manager performs also the following actions. the Group Manager performs also the following actions.
* The Group Manager selects an available OSCORE Sender ID in the * The Group Manager selects an available OSCORE Sender ID in the
OSCORE group, and exclusively assigns it to the joining node. The OSCORE group, and exclusively assigns it to the joining node. The
Group Manager MUST NOT assign an OSCORE Sender ID to the joining Group Manager MUST NOT assign an OSCORE Sender ID to the joining
node if this joins the group exclusively with the role of monitor, node if this joins the group exclusively with the role of monitor,
according to what specified in the Access Token (see Section 4.2). according to what is specified in the Access Token (see
Section 5.2).
Consistently with Section 3.2.1 of Consistently with Section 3.2.1 of
[I-D.ietf-core-oscore-groupcomm], the Group Manager MUST assign an [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST assign an
OSCORE Sender ID that has not been used in the OSCORE group since OSCORE Sender ID that has not been used in the OSCORE group since
the latest time when the current Gid value was assigned to the the latest time when the current Gid value was assigned to the
group. group.
If the joining node is recognized as a current group member, e.g., If the joining node is recognized as a current group member, e.g.,
through the ongoing secure communication association, the through the ongoing secure communication association, the
following also applies. following also applies.
- The Group Manager MUST assign a new OSCORE Sender ID different - The Group Manager MUST assign a new OSCORE Sender ID different
than the one currently used by the joining node in the OSCORE than the one currently used by the joining node in the OSCORE
group. group.
- The Group Manager MUST add the old, relinquished OSCORE Sender - The Group Manager MUST add the old, relinquished OSCORE Sender
ID of the joining node to the most recent set of stale Sender ID of the joining node to the most recent set of stale Sender
IDs, in the collection associated with the group (see IDs, in the collection associated with the group (see
Section 2.2.1). Section 7.1).
* The Group Manager stores the association between i) the * The Group Manager stores the association between i) the
authentication credential of the joining node; and ii) the Group authentication credential of the joining node; and ii) the Group
Identifier (Gid), i.e., the OSCORE ID Context, associated with the Identifier (Gid), i.e., the OSCORE ID Context, associated with the
OSCORE group together with the OSCORE Sender ID assigned to the OSCORE group together with the OSCORE Sender ID assigned to the
joining node in the group. The Group Manager MUST keep this joining node in the group. The Group Manager MUST keep this
association updated over time. association updated over time.
Then, the Group Manager replies to the joining node, providing the Then, the Group Manager replies to the joining node, providing the
updated security parameters and keying meterial necessary to updated security parameters and keying meterial necessary to
participate in the group communication. This success Joining participate in the group communication. This success Joining
Response is formatted as defined in Section 4.3.1 of Response is formatted as defined in Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm], with the following additions: [I-D.ietf-ace-key-groupcomm], with the following additions:
* The 'gkty' parameter identifies a key of type * The 'gkty' parameter identifies a key of type
"Group_OSCORE_Input_Material object", defined in Section 25.4 of "Group_OSCORE_Input_Material object", defined in Section 16.4 of
this document. this document.
* The 'key' parameter includes what the joining node needs in order * The 'key' parameter includes what the joining node needs in order
to set up the Group OSCORE Security Context as per Section 2 of to set up the Group OSCORE Security Context as per Section 2 of
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
This parameter has as value a Group_OSCORE_Input_Material object, This parameter has as value a Group_OSCORE_Input_Material object,
which is defined in this document and extends the which is defined in this document and extends the
OSCORE_Input_Material object encoded in CBOR as defined in OSCORE_Input_Material object encoded in CBOR as defined in
Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. In particular, it Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. In particular, it
contains the additional parameters 'group_senderId', 'cred_fmt', contains the additional parameters 'group_senderId', 'cred_fmt',
'sign_enc_alg', 'sign_alg', 'sign_params', 'ecdh_alg' and 'sign_enc_alg', 'sign_alg', 'sign_params', 'ecdh_alg' and
'ecdh_params' defined in Section 25.6 of this document. 'ecdh_params' defined in Section 16.6 of this document.
More specifically, the 'key' parameter is composed as follows. More specifically, the 'key' parameter is composed as follows.
- The 'hkdf' parameter, if present, has as value the HKDF - The 'hkdf' parameter, if present, specifies the HKDF Algorithm
Algorithm used in the OSCORE group. This parameter MAY be used in the OSCORE group. The HKDF Algorithm is specified by
omitted, if the HKDF Algorithm used in the group is HKDF SHA- the HMAC Algorithm value. This parameter MAY be omitted, if
256. Otherwise, this parameter MUST be present. the HKDF Algorithm used in the group is HKDF SHA-256.
Otherwise, this parameter MUST be present.
- The 'salt' parameter, if present, has as value the OSCORE - The 'salt' parameter, if present, has as value the OSCORE
Master Salt used in the OSCORE group. This parameter MAY be Master Salt used in the OSCORE group. This parameter MAY be
omitted, if the Master Salt used in the group is the empty byte omitted, if the Master Salt used in the group is the empty byte
string. Otherwise, this parameter MUST be present. string. Otherwise, this parameter MUST be present.
- The 'ms' parameter includes the OSCORE Master Secret value used - The 'ms' parameter includes the OSCORE Master Secret value used
in the OSCORE group. This parameter MUST be present. in the OSCORE group. This parameter MUST be present.
- The 'contextId' parameter MUST be present and has as value the - The 'contextId' parameter has as value the Group Identifier
Group Identifier (Gid), i.e., the OSCORE ID Context of the (Gid), i.e., the OSCORE ID Context of the OSCORE group. This
OSCORE group. This parameter MUST be present. parameter MUST be present.
- The 'group_senderId' parameter, if present, has as value the - The 'group_senderId' parameter has as value the OSCORE Sender
OSCORE Sender ID assigned to the joining node by the Group ID assigned to the joining node by the Group Manager, as
Manager, as described above. This parameter MUST NOT be described above. This parameter MUST be present if and only if
present if the node joins the OSCORE group exclusively with the the node does not join the OSCORE group exclusively with the
role of monitor, according to what specified in the Access role of monitor, according to what is specified in the Access
Token (see Section 4.2). In any other case, this parameter Token (see Section 5.2).
MUST be present.
- The 'cred_fmt' parameter MUST be present and specifies the - The 'cred_fmt' parameter specifies the format of authentication
format of authentication credentials used in the OSCORE group. credentials used in the OSCORE group. This parameter MUST be
It takes value from the "Label" column of the "COSE Header present and it takes value from the "Label" column of the "COSE
Parameters" registry [COSE.Header.Parameters] (REQ6). Header Parameters" registry [COSE.Header.Parameters] (REQ6).
Consistently with Section 2.3 of Consistently with Section 2.3 of
[I-D.ietf-core-oscore-groupcomm], acceptable values denote a [I-D.ietf-core-oscore-groupcomm], acceptable values denote a
format that MUST explicitly provide the public key as well as format that MUST explicitly provide the public key as well as
the comprehensive set of information related to the public key the comprehensive set of information related to the public key
algorithm, including, e.g., the used elliptic curve (when algorithm, including, e.g., the used elliptic curve (when
applicable). applicable).
At the time of writing this specification, acceptable formats At the time of writing this specification, acceptable formats
of authentication credentials are CBOR Web Tokens (CWTs) and of authentication credentials are CBOR Web Tokens (CWTs) and
CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925]
skipping to change at page 32, line 44 skipping to change at page 28, line 46
defined above. defined above.
[ As to CWTs and CCSs, the COSE Header Parameters 'kcwt' and [ As to CWTs and CCSs, the COSE Header Parameters 'kcwt' and
'kccs' are under pending registration requested by draft-ietf- 'kccs' are under pending registration requested by draft-ietf-
lake-edhoc. ] lake-edhoc. ]
[ As to C509 certificates, the COSE Header Parameters 'c5b' and [ As to C509 certificates, the COSE Header Parameters 'c5b' and
'c5c' are under pending registration requested by draft-ietf- 'c5c' are under pending registration requested by draft-ietf-
cose-cbor-encoded-cert. ] cose-cbor-encoded-cert. ]
- The 'sign_enc_alg' parameter MUST NOT be present if the OSCORE The 'key' parameter MUST also include the following parameters, if
group is a pairwise-only group. Otherwise, it MUST be present and only if the OSCORE group is not a pairwise-only group.
and specifies the Signature Encryption Algorithm used in the
OSCORE group to encrypt messages protected with the group mode.
This parameter takes values from the "Value" column of the
"COSE Algorithms" registry [COSE.Algorithms].
- The 'sign_alg' parameter MUST NOT be present if the OSCORE - The 'sign_enc_alg' parameter, specifying the Signature
group is a pairwise-only group. Otherwise, it MUST be present Encryption Algorithm used in the OSCORE group to encrypt
and specifies the Signature Algorithm used to sign messages in messages protected with the group mode. This parameter takes
the OSCORE group. This parameter takes values from the "Value" values from the "Value" column of the "COSE Algorithms"
column of the "COSE Algorithms" registry [COSE.Algorithms]. registry [COSE.Algorithms].
- The 'sign_params' parameter MUST NOT be present if the OSCORE - The 'sign_alg' parameter, specifying the Signature Algorithm
group is a pairwise-only group. Otherwise, it MUST be present used to sign messages in the OSCORE group. This parameter
and specifies the parameters of the Signature Algorithm. This takes values from the "Value" column of the "COSE Algorithms"
parameter is a CBOR array, which includes the following two registry [COSE.Algorithms].
elements:
- The 'sign_params' parameter, specifying the parameters of the
Signature Algorithm. This parameter is a CBOR array, which
includes the following two elements:
o 'sign_alg_capab': a CBOR array, with the same format and o 'sign_alg_capab': a CBOR array, with the same format and
value of the COSE capabilities array for the Signature value of the COSE capabilities array for the Signature
Algorithm indicated in 'sign_alg', as specified for that Algorithm indicated in 'sign_alg', as specified for that
algorithm in the "Capabilities" column of the "COSE algorithm in the "Capabilities" column of the "COSE
Algorithms" registry [COSE.Algorithms]. Algorithms" registry [COSE.Algorithms].
o 'sign_key_type_capab': a CBOR array, with the same format o 'sign_key_type_capab': a CBOR array, with the same format
and value of the COSE capabilities array for the COSE key and value of the COSE capabilities array for the COSE key
type of the keys used with the Signature Algorithm indicated type of the keys used with the Signature Algorithm indicated
in 'sign_alg', as specified for that key type in the in 'sign_alg', as specified for that key type in the
"Capabilities" column of the "COSE Key Types" registry "Capabilities" column of the "COSE Key Types" registry
[COSE.Key.Types]. [COSE.Key.Types].
- The 'alg' parameter MUST NOT be present if the OSCORE group is The 'key' parameter MUST also include the following parameters, if
a signature-only group. Otherwise, it MUST be present and and only if the OSCORE group is not a signature-only group.
specifies the AEAD Algorithm used in the OSCORE group to
encrypt messages protected with the pairwise mode.
- The 'ecdh_alg' parameter MUST NOT be present if the OSCORE - The 'alg' parameter, specifying the AEAD Algorithm used in the
group is a signature-only group. Otherwise, it MUST be present OSCORE group to encrypt messages protected with the pairwise
and specifies the Pairwise Key Agreement Algorithm used in the mode.
OSCORE group. This parameter takes values from the "Value"
column of the "COSE Algorithms" registry [COSE.Algorithms].
- The 'ecdh_params' parameter MUST NOT be present if the OSCORE - The 'ecdh_alg' parameter, specifying the Pairwise Key Agreement
group is a signature-only group. Otherwise, it MUST be present Algorithm used in the OSCORE group. This parameter takes
and specifies the parameters of the Pairwise Key Agreement values from the "Value" column of the "COSE Algorithms"
Algorithm. This parameter is a CBOR array, which includes the registry [COSE.Algorithms].
following two elements:
- The 'ecdh_params' parameter, specifying the parameters of the
Pairwise Key Agreement Algorithm. This parameter is a CBOR
array, which includes the following two elements:
o 'ecdh_alg_capab': a CBOR array, with the same format and o 'ecdh_alg_capab': a CBOR array, with the same format and
value of the COSE capabilities array for the algorithm value of the COSE capabilities array for the algorithm
indicated in 'ecdh_alg', as specified for that algorithm in indicated in 'ecdh_alg', as specified for that algorithm in
the "Capabilities" column of the "COSE Algorithms" registry the "Capabilities" column of the "COSE Algorithms" registry
[COSE.Algorithms]. [COSE.Algorithms].
o 'ecdh_key_type_capab': a CBOR array, with the same format o 'ecdh_key_type_capab': a CBOR array, with the same format
and value of the COSE capabilities array for the COSE key and value of the COSE capabilities array for the COSE key
type of the keys used with the algorithm indicated in type of the keys used with the algorithm indicated in
skipping to change at page 34, line 20 skipping to change at page 30, line 26
[COSE.Key.Types]. [COSE.Key.Types].
The format of 'key' defined above is consistent with every The format of 'key' defined above is consistent with every
signature algorithm and ECDH algorithm currently considered in signature algorithm and ECDH algorithm currently considered in
[I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have [I-D.ietf-cose-rfc8152bis-algs], i.e., with algorithms that have
only the COSE key type as their COSE capability. Appendix B of only the COSE key type as their COSE capability. Appendix B of
this document describes how the format of the 'key' parameter can this document describes how the format of the 'key' parameter can
be generalized for possible future registered algorithms having a be generalized for possible future registered algorithms having a
different set of COSE capabilities. different set of COSE capabilities.
Furthermore, the following applies.
* The 'exp' parameter MUST be present. * The 'exp' parameter MUST be present.
* The 'ace-groupcomm-profile' parameter MUST be present and has * The 'ace-groupcomm-profile' parameter MUST be present and has
value coap_group_oscore_app (PROFILE_TBD), which is defined in value coap_group_oscore_app (PROFILE_TBD), which is defined in
Section 25.5 of this document. Section 16.5 of this document.
* The 'pub_keys' parameter, if present, includes the authentication * The 'pub_keys' parameter, if present, includes the authentication
credentials requested by the joining node by means of the credentials requested by the joining node by means of the
'get_pub_keys' parameter in the Joining Request. 'get_pub_keys' parameter in the Joining Request.
If the joining node has asked for the authentication credentials If the joining node has asked for the authentication credentials
of all the group members, i.e., 'get_pub_keys' had value the CBOR of all the group members, i.e., 'get_pub_keys' had value the CBOR
simple value "null" (0xf6) in the Joining Request, then the Group simple value "null" (0xf6) in the Joining Request, then the Group
Manager provides only the authentication credentials of the group Manager provides only the authentication credentials of the group
members that are relevant to the joining node. That is, in such a members that are relevant to the joining node. That is, in such a
skipping to change at page 36, line 9 skipping to change at page 32, line 20
procedure is described in Section 5 of [RFC7748]. procedure is described in Section 5 of [RFC7748].
o info takes as value the PoP input. o info takes as value the PoP input.
o L is equal to 8, i.e., the size of the MAC, in bytes. o L is equal to 8, i.e., the size of the MAC, in bytes.
* The 'group_rekeying' parameter MAY be omitted, if the Group * The 'group_rekeying' parameter MAY be omitted, if the Group
Manager uses the "Point-to-Point" group rekeying scheme registered Manager uses the "Point-to-Point" group rekeying scheme registered
in Section 11.14 of [I-D.ietf-ace-key-groupcomm] as rekeying in Section 11.14 of [I-D.ietf-ace-key-groupcomm] as rekeying
scheme in the OSCORE group (OPT9). Its detailed use for this scheme in the OSCORE group (OPT9). Its detailed use for this
profile is defined in Section 20 of this document. In any other profile is defined in Section 11 of this document. In any other
case, the 'group_rekeying' parameter MUST be included. case, the 'group_rekeying' parameter MUST be included.
As a last action, if the Group Manager reassigns Gid values during As a last action, if the Group Manager reassigns Gid values during
the group's lifetime (see Section 3.2.1.1 of the group's lifetime (see Section 3.2.1.1 of
[I-D.ietf-core-oscore-groupcomm]), the Group Manager MUST store the [I-D.ietf-core-oscore-groupcomm]), then the Group Manager MUST store
Gid specified in the 'contextId' parameter of the 'key' parameter, as the Gid specified in the 'contextId' parameter of the 'key'
the Birth Gid of the joining node in the joined group (see Section 3 parameter, as the Birth Gid of the joining node in the joined group
of [I-D.ietf-core-oscore-groupcomm]). This applies also in case the (see Section 3 of [I-D.ietf-core-oscore-groupcomm]). This applies
node is in fact re-joining the group; in such a case, the newly also in case the joining node is in fact re-joining the group; in
determined Birth Gid overwrites the one currently stored. such a case, the newly determined Birth Gid overwrites the one
currently stored.
6.5. Receive the Joining Response 6.4. Receive the Joining Response
Upon receiving the Joining Response, the joining node retrieves the Upon receiving the Joining Response, the joining node retrieves the
Group Manager's authentication credential from the 'kdc_cred' Group Manager's authentication credential from the 'kdc_cred'
parameter. The joining node MUST verify the proof-of-possession parameter. The joining node MUST verify the proof-of-possession
(PoP) evidence specified in the 'kdc_cred_verify' parameter of the (PoP) evidence specified in the 'kdc_cred_verify' parameter of the
Joining Response as defined below (REQ21). Joining Response as defined below (REQ21).
* If the group is not a pairwise-only group, the PoP evidence is a * If the group is not a pairwise-only group, the PoP evidence is a
signature. The joining node verifies it by using the public key signature. The joining node verifies it by using the public key
of the Group Manager from the received authentication credential, of the Group Manager from the received authentication credential,
as well as the signature algorithm used in the OSCORE group and as well as the signature algorithm used in the OSCORE group and
possible corresponding parameters. possible corresponding parameters.
* If the group is a pairwise-only group, the PoP evidence is a MAC. * If the group is a pairwise-only group, the PoP evidence is a MAC.
The joining node recomputes the MAC through the same process taken The joining node recomputes the MAC through the same process taken
by the Group Manager when computing the value of the by the Group Manager when computing the value of the
'kdc_cred_verify' parameter (see Section 6.4), with the difference 'kdc_cred_verify' parameter (see Section 6.3), with the difference
that the joining node uses its own Diffie-Hellman private key and that the joining node uses its own Diffie-Hellman private key and
the Diffie-Hellman public key of the Group Manager from the the Diffie-Hellman public key of the Group Manager from the
received authentication credential. The verification succeeds if received authentication credential. The verification succeeds if
and only if the recomputed MAC is equal to the MAC conveyed as PoP and only if the recomputed MAC is equal to the MAC conveyed as PoP
evidence in the Joining Response. evidence in the Joining Response.
In case of failed verification of the PoP evidence, the joining node In case of failed verification of the PoP evidence, the joining node
MUST stop processing the Joining Response and MAY send a new Joining MUST stop processing the Joining Response and MAY send a new Joining
Request to the Group Manager (see Section 6.2). Request to the Group Manager (see Section 6.1).
In case of successful verification of the PoP evidence, the joining In case of successful verification of the PoP evidence, the joining
node uses the information received in the Joining Response to set up node uses the information received in the Joining Response to set up
the Group OSCORE Security Context, as described in Section 2 of the Group OSCORE Security Context, as described in Section 2 of
[I-D.ietf-core-oscore-groupcomm]. If the following parameters were [I-D.ietf-core-oscore-groupcomm]. If the following parameters were
not included in the 'key' parameter of the Joining Response, the not included in the 'key' parameter of the Joining Response, the
joining node considers the following default values, consistently joining node considers the default values specified below,
with Section 3.2 of [RFC8613]. consistently with Section 3.2 of [RFC8613].
* Absent the 'hkdf' parameter, the joining node considers HKDF * Absent the 'hkdf' parameter, the joining node considers HKDF
SHA-256 as HKDF Algorithm to use in the OSCORE group. SHA-256 as HKDF Algorithm to use in the OSCORE group.
* Absent the 'salt' parameter, the joining node considers the empty * Absent the 'salt' parameter, the joining node considers the empty
byte string as Master Salt to use in the OSCORE group. byte string as Master Salt to use in the OSCORE group.
* Absent the 'group_rekeying' parameter, the joining node considers * Absent the 'group_rekeying' parameter, the joining node considers
the "Point-to-Point" group rekeying scheme registered in the "Point-to-Point" group rekeying scheme registered in
Section 11.14 of [I-D.ietf-ace-key-groupcomm] as the rekeying Section 11.14 of [I-D.ietf-ace-key-groupcomm] as the rekeying
scheme used in the group (OPT9). Its detailed use for this scheme used in the group (OPT9). Its detailed use for this
profile is defined in Section 20 of this document. profile is defined in Section 11 of this document.
In addition, the joining node maintains an association between each In addition, the joining node maintains an association between each
authentication credential retrieved from the 'pub_keys' parameter and authentication credential retrieved from the 'pub_keys' parameter and
the role(s) that the corresponding group member has in the OSCORE the role(s) that the corresponding group member has in the OSCORE
group. 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].
When doing so: When doing so:
skipping to change at page 37, line 43 skipping to change at page 34, line 7
* The joining node MUST NOT process an incoming response message, if * The joining node MUST NOT process an incoming response message, if
protected by a group member whose authentication credential is not protected by a group member whose authentication credential is not
associated with the role "Responder". associated with the role "Responder".
* The joining node MUST NOT use the pairwise mode of Group OSCORE to * The joining node MUST NOT use the pairwise mode of Group OSCORE to
process messages in the group, if the Joining Response did not process messages in the group, if the Joining Response did not
include the 'ecdh_alg' parameter. include the 'ecdh_alg' parameter.
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 20). As a consequence, the joining node is not able to (see Section 11). In such a case, the joining node is not able to
access secure communication in the OSCORE group occurred prior its access secure communication in the OSCORE group occurred prior its
joining. joining.
7. Public Keys of Joining Nodes 7. Overview of the Group Rekeying Process
Source authentication of a message sent within the group and In a number of cases, the Group Manager has to generate new keying
protected with Group OSCORE is ensured by means of a digital material and distribute it to the group (rekeying), as also discussed
signature embedded in the message (in group mode), or by integrity- in Section 3.2 of [I-D.ietf-core-oscore-groupcomm].
protecting the message with pairwise keying material derived from the
asymmetric keys of sender and recipient (in pairwise mode).
Therefore, group members must be able to retrieve each other's To this end the Group Manager MUST support the Group Rekeying Process
authentication credential from a trusted repository, in order to described in Section 11 of this document, as an instance of the
verify source authenticity of incoming group messages. "Point-to-Point" rekeying scheme defined in Section 6.1 of
[I-D.ietf-ace-key-groupcomm] and registered in Section 11.14 of
[I-D.ietf-ace-key-groupcomm]. Future documents may define the use of
alternative group rekeying schemes for this application profile,
together with the corresponding rekeying message formats. The
resulting group rekeying process MUST comply with the functional
steps defined in Section 3.2 of [I-D.ietf-core-oscore-groupcomm].
As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group Upon generating the new group keying material and before starting its
Manager acts as trusted repository of the authentication credentials distribution, the Group Manager MUST increment the version number of
of the group members, and provides those authentication credentials the group keying material. When rekeying a group, the Group Manager
to group members if requested to. Upon joining an OSCORE group, a MUST preserve the current value of the OSCORE Sender ID of each
joining node is thus expected to provide its own authentication member in that group.
credential to the Group Manager.
In particular, one of the following four cases can occur when a new The data distributed to a group through a rekeying MUST include:
node joins an OSCORE group.
* The joining node is going to join the group exclusively as * The new version number of the group keying material for the group.
monitor, i.e., it is not going to send messages to the group. In
this case, the joining node is not required to provide its own
authentication credential to the Group Manager, which thus does
not have to perform any check related to the format of the
authentication credential, to a signature or ECDH algorithm, and
to possible parameters associated with the algorithm and the
public key. In case that joining node still provides an
authentication credential in the 'client_cred' parameter of the
Joining Request (see Section 6.2), the Group Manager silently
ignores that parameter, as well as the related parameters 'cnonce'
and 'client_cred_verify'.
* The Group Manager already acquired the authentication credential * A new Group Identifier (Gid) for the group as introduced in
of the joining node during a past joining process. In this case, [I-D.ietf-ace-key-groupcomm], used as ID Context parameter of the
the joining node MAY choose not to provide again its own Group OSCORE Common Security Context of that group (see Section 2
authentication credential to the Group Manager, in order to limit of [I-D.ietf-core-oscore-groupcomm]).
the size of the Joining Request. The joining node MUST provide
its own authentication credential again if it has provided the
Group Manager with multiple authentication credentials during past
joining processes, intended for different OSCORE groups. If the
joining node provides its own authentication credential, the Group
Manager performs consistency checks as per Section 6.3 and, in
case of success, considers it as the authentication credential
associated with the joining node in the OSCORE group.
* The joining node and the Group Manager use an asymmetric proof-of- Note that the Gid differs from the group name also introduced in
possession key to establish a secure communication association. [I-D.ietf-ace-key-groupcomm], which is a plain, stable and
Then, two cases can occur. invariant identifier, with no cryptographic relevance and meaning.
1. When establishing the secure communication association, the * A new value for the Master Secret parameter of the Group OSCORE
Group Manager obtained from the joining node the joining Common Security Context of the group (see Section 2 of
node's authentication credential, in the format used in the [I-D.ietf-core-oscore-groupcomm]).
OSCORE group and including the asymmetric proof-of-possession
key as public key. Also, such authentication credential and
the proof-of-possession key are compatible with the signature
or ECDH algorithm, and possible associated parameters used in
the OSCORE group.
In this case, the Group Manager considers the authentication * A set of stale Sender IDs, which allows each rekeyed node to purge
credential as the one associated with the joining node in the authentication credentials and Recipient Contexts used in the
OSCORE group. If the joining node is aware that the group and associated with those Sender IDs. This in turn allows
authentication credential and the public key included thereof every group member to rely on stored authentication credentials,
are also valid for the OSCORE group, then the joining node MAY in order to confidently assert the group membership of other
choose to not provide again its own authentication credential sender nodes, when receiving protected messages in the group (see
to the Group Manager. Section 3.2 of [I-D.ietf-core-oscore-groupcomm]). More details on
the maintenance of stale Sender IDs are provided in Section 7.1.
The joining node MUST provide again its own authentication Also, the data distributed through a group rekeying MAY include a new
credential if it has provided the Group Manager with multiple value for the Master Salt parameter of the Group OSCORE Common
authentication credentials during past joining processes, Security Context of that group.
intended for different OSCORE groups. If the joining node
provides its own authentication credential in the
'client_cred' parameter of the Joining Request (see
Section 6.2), the Group Manager performs consistency checks as
per Section 6.3 and, in case of success, considers it as the
authentication credential associated with the joining node in
the OSCORE group.
2. The authentication credential is not in the format used in the The Group Manager MUST rekey the group in the following cases.
OSCORE group, or else the authentication credential and the
proof-of-possession key included as public key are not
compatible with the signature or ECDH algorithm, and possible
associated parameters used in the OSCORE group.
In this case, the joining node MUST provide a different * The application requires backward security - In this case, the
compatible authentication credential and public key included group is rekeyed when a node joins the group as a new member.
thereof to the Group Manager in the 'client_cred' parameter of Therefore, a joining node cannot access communications in the
the Joining Request (see Section 6.2). Then, the Group group prior its joining.
Manager performs consistency checks on this latest provided
authentication credential as per Section 6.3 and, in case of
success, considers it as the authentication credential
associated with the joining node in the OSCORE group.
* The joining node and the Group Manager use a symmetric proof-of- * One or more nodes leave the group - That is, the group is rekeyed
possession key to establish a secure communication association. when one or more current members spontaneously request to leave
In this case, upon performing a joining process with that Group the group (see Section 9.11), or when the Group Manager forcibly
Manager for the first time, the joining node specifies its own evicts them from the group, e.g., due to expired or revoked
authentication credential in the 'client_cred' parameter of the authorization (see Section 10). Therefore, a leaving node cannot
Joining Request targeting the group-membership endpoint (see access communications in the group after its leaving, thus
Section 6.2). ensuring forward security in the group.
8. Retrieve of Updated Keying Material Due to the set of stale Sender IDs distributed through the
rekeying, this ensures that a node owning the latest group keying
material does not store the authentication credentials of former
group members (see Sections 3.2 and 12.1 of
[I-D.ietf-core-oscore-groupcomm]).
* Extension of group lifetime - That is, the group is rekeyed when
the expiration time for the group keying material approaches or
has passed, if it is appropriate to extend the group operation
beyond that.
The Group Manager MAY rekey the group for other reasons, e.g.,
according to an application-specific rekeying period or scheduling.
7.1. Stale OSCORE Sender IDs
Throughout the lifetime of every group, the Group Manager MUST
maintain a collection of stale Sender IDs for that group.
The collection associated with a group MUST include up to N > 1
ordered sets of stale OSCORE Sender IDs. It is up to the application
to specify the value of N, possibly on a per-group basis.
The N-th set includes the Sender IDs that have become "stale" under
the current version V of the group keying material. The (N - 1)-th
set refers to the immediately previous version (V - 1) of the group
keying material, and so on.
In the following cases, the Group Manager MUST add a new element to
the most recent set X, i.e., the set associated with the current
version V of the group keying material.
* When a current group member obtains a new Sender ID, its old
Sender ID is added to X. This happens when the Group Manager
assigns a new Sender ID upon request from the group member (see
Section 9.2), or in case the group member re-joins the group (see
Section 6.1 and Section 6.3), thus also obtaining a new Sender ID.
* When a current group member leaves the group, its current Sender
ID is added to X. This happens when a group member requests to
leave the group (see Section 9.11) or is forcibly evicted from the
group (see Section 10).
The value of N can change throughout the lifetime of the group. If
the new value N' is smaller than N, the Group Manager MUST preserve
the (up to) N' most recent sets in the collection and MUST delete any
possible older set from the collection.
Finally, the Group Manager MUST perform the following actions, when
the group is rekeyed and the group shifts to the next version V' = (V
+ 1) of the group keying material.
1. The Group Manager rekeys the group. This includes also
distributing the set of stale Sender IDs X associated with the
old group keying material with version V (see Section 7).
2. After completing the group rekeying, the Group Manager creates a
new empty set X' associated with the new version V' of the newly
established group keying material, i.e., V' = (V + 1).
3. If the current collection of stale Sender IDs has size N, the
Group Manager deletes the oldest set in the collection.
4. The Group Manager adds the new set X' to the collection of stale
Sender IDs, as the most recent set.
8. Interface at the Group Manager
The Group Manager provides the interface defined in Section 4.1 of
[I-D.ietf-ace-key-groupcomm], with the additional sub-resources
defined from Section 8.1 to Section 8.3 of this document.
Furthermore, Section 8.4 provides a summary of the CoAP methods
admitted to access different resources at the Group Manager, for
nodes with different roles in the group or as non members (REQ11).
The GROUPNAME segment of the URI path MUST match with the group name
specified in the scope entry of the Access Token scope (i.e., 'gname'
in Section 3.1 of [I-D.ietf-ace-key-groupcomm]) (REQ7).
The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is
registered in Section 16.11 (REQ10), and can be used to describe
group-membership resources and its sub-resources at a Group Manager,
e.g., by using a link-format document [RFC6690].
Applications can use this common resource type to discover links to
group-membership resources for joining OSCORE groups, e.g., by using
the approach described in [I-D.tiloca-core-oscore-discovery].
8.1. ace-group/GROUPNAME/active
This resource implements a GET handler.
8.1.1. GET Handler
The handler expects a GET request.
In addition to what is defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm], the handler verifies that the
requesting Client is a current member of the group. If the
verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
response. The response MUST have Content-Format set to application/
ace-groupcomm+cbor and is formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be
set to 0 ("Operation permitted only to group members").
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying the current status of the group, i.e.,
active or inactive. The payload of the response is formatted as
defined in Section 9.9.
The method to set the current group status is out of the scope of
this document, and is defined for the administrator interface of the
Group Manager specified in [I-D.ietf-ace-oscore-gm-admin].
8.2. ace-group/GROUPNAME/verif-data
This resource implements a GET handler.
8.2.1. GET Handler
The handler expects a GET request.
In addition to what is defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm], the Group Manager performs the
following checks.
If the requesting Client is a current group member, the Group Manager
MUST reply with a 4.03 (Forbidden) error response. The response MUST
have Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be
set to 8 ("Operation permitted only to signature verifiers").
If GROUPNAME denotes a pairwise-only group, the Group Manager MUST
reply with a 4.00 (Bad Request) error response. The response MUST
have Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be
set to 7 ("Signatures not used in the group").
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allow also an external
signature verifier to verify signatures of messages protected with
the group mode and sent to the group (see Sections 3.1 and 8.5 of
[I-D.ietf-core-oscore-groupcomm]). The response MUST have Content-
Format set to application/ace-groupcomm+cbor. The payload of the
response is a CBOR map, which is formatted as defined in Section 9.6.
8.3. ace-group/GROUPNAME/stale-sids
This resource implements a FETCH handler.
8.3.1. FETCH Handler
The handler expects a FETCH request, whose payload specifies a
version number of the group keying material, encoded as an unsigned
CBOR integer.
In addition to what is defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm], the handler verifies that the
requesting Client is a current member of the group. If the
verification fails, the Group Manager MUST reply with a 4.03
(Forbidden) error response. The response MUST have Content-Format
set to application/ace-groupcomm+cbor and is formatted as defined in
Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the
'error' field MUST be set to 0 ("Operation permitted only to group
members").
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allow the requesting Client
to delete the Recipient Contexts and authentication credentials
associated with former members of the group (see Section 3.2 of
[I-D.ietf-core-oscore-groupcomm]. The payload of the response is
formatted as defined in Section 11.3.1.
8.4. Admitted Methods
The table in Figure 2 summarizes the CoAP methods admitted to access
different resources at the Group Manager, for (non-)members of a
group with group name GROUPNAME, and considering different roles.
The last two rows of the table apply to a node with node name
NODENAME.
+---------------------------------+--------+-------+-------+-------+
| Resource | Type1 | Type2 | Type3 | Type4 |
+---------------------------------+--------+-------+-------+-------+
| ace-group/ | F | F | F | F |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/ | G Po | G Po | Po * | Po |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/active | G | G | - | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/verif-data | - | - | G | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/pub-key | G F | G F | G F | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/kdc-pub-key | G | G | G | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/stale-sids | F | F | - | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/policies | G | G | - | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/num | G | G | - | - |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/nodes/ | G Pu D | G D | - | - |
| NODENAME | | | | |
+---------------------------------+--------+-------+-------+-------+
| ace-group/GROUPNAME/nodes/ | Po | - | - | - |
| NODENAME/pub-key | | | | |
+---------------------------------+--------+-------+-------+-------+
CoAP methods: G = GET; F = FETCH; Po = POST; Pu = PUT; D = DELETE
Type1 = Member as Requester and/or Responder
Type2 = Member as Monitor
Type3 = Non-member (authorized to be signature verifier)
(*) = cannot join the group as signature verifier
Type4 = Non-member (not authorized to be signature verifier)
Figure 2: Admitted CoAP Methods on the Group Manager Resources
8.4.1. Signature Verifiers
Just like any candidate group member, a signature verifier provides
the Group Manager with an Access Token, as described in Section 5.3.
However, unlike candidate group members, it does not join any OSCORE
group, i.e., it does not perform the joining process defined in
Section 6.
After successfully transferring an Access Token to the Group Manager,
a signature verifier is allowed to perform only some operations as
non-member of a group, and only for the OSCORE groups specified in
the validated Access Token. These are the operations specified in
Section 9.3, Section 9.5, Section 9.6 and Section 9.10.
Consistently, in case a node is not a member of the group with group
name GROUPNAME and is authorized to be only signature verifier for
that group, the Group Manager MUST reply with a 4.03 (Forbidden)
error response if that node attempts to access any other endpoint
than: /ace-group; ace-group/GROUPNAME/verif-data; /ace-
group/GROUPNAME/pub-key; and ace-group/GROUPNAME/kdc-pub-key.
8.5. Operations Supported by Clients
Building on what is defined in Section 4.1.1 of
[I-D.ietf-ace-key-groupcomm], and with reference to the resources at
the Group Manager newly defined earlier in Section 8 of this
document, it is expected that a Client minimally supports also the
following set of operations and corresponding interactions with the
Group Manager (REQ12).
* GET request to ace-group/GROUPNAME/active, in order to check the
current status of the group.
* GET request to ace-group/GROUPNAME/verif-data, in order for a
signature verifier to retrieve data required to verify signatures
of messages protected with the group mode of Group OSCORE and sent
to a group (see Sections 3.1 and 8.5 of
[I-D.ietf-core-oscore-groupcomm]). Note that this operation is
relevant to support only to signature verifiers.
* FETCH request to ace-group/GROUPNAME/stale-sids, in order to
retrieve from the Group Manager the data required to delete some
of the stored group members' authentication credentials and
associated Recipient Contexts (see Section 8.3.1). These data are
provided as an aggregated set of stale Sender IDs, which are used
as specified in Section 11.3.
9. Additional Interactions with the Group Manager
This section defines the possible interactions with the Group
Manager, in addition to the group joining specified in Section 6.
9.1. Retrieve Updated Keying Material
At some point, a group member considers the Group OSCORE Security At some point, a group member considers the Group OSCORE Security
Context invalid and to be renewed. This happens, for instance, after Context invalid and to be renewed. This happens, for instance, after
a number of unsuccessful security processing of incoming messages a number of unsuccessful security processing of incoming messages
from other group members, or when the Security Context expires as from other group members, or when the Security Context expires as
specified by the 'exp' parameter of the Joining Response. specified by the 'exp' parameter of the Joining Response.
When this happens, the group member retrieves updated security When this happens, the group member retrieves updated security
parameters and group keying material. This can occur in the two parameters and group keying material. This can occur in the two
different ways described below. different ways described below.
8.1. Retrieve of Group Keying Material 9.1.1. Get Group Keying Material
If the group member wants to retrieve only the latest group keying If the group member wants to retrieve only the latest group keying
material, it sends a Key Distribution Request to the Group Manager. material, it sends a Key Distribution Request to the Group Manager.
In particular, it sends a CoAP GET request to the endpoint /ace- In particular, it sends a CoAP GET request to the endpoint /ace-
group/GROUPNAME at the Group Manager. group/GROUPNAME at the Group Manager.
The Group Manager processes the Key Distribution Request according to The Group Manager processes the Key Distribution Request according to
Section 4.3.2 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution Section 4.3.2 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution
Response is formatted as defined in Section 4.3.2 of Response is formatted as defined in Section 4.3.2 of
[I-D.ietf-ace-key-groupcomm], with the following additions. [I-D.ietf-ace-key-groupcomm], with the following additions.
* The 'key' parameter is formatted as defined in Section 6.4 of this * The 'key' parameter is formatted as defined in Section 6.3 of this
document, with the difference that it does not include the document, with the difference that it does not include the
'group_SenderId' parameter. 'group_SenderId' parameter.
* The 'exp' parameter MUST be present. * The 'exp' parameter MUST be present.
* The 'ace-groupcomm-profile' parameter MUST be present and has * The 'ace-groupcomm-profile' parameter MUST be present and has
value coap_group_oscore_app. value coap_group_oscore_app.
Upon receiving the Key Distribution Response, the group member Upon receiving the Key Distribution Response, the group member
retrieves the updated security parameters and group keying material, retrieves the updated security parameters and group keying material,
and, if they differ from the current ones, uses them to set up the and, if they differ from the current ones, uses them to set up the
new Group OSCORE Security Context as described in Section 2 of new Group OSCORE Security Context as described in Section 2 of
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
8.2. Retrieve of Group Keying Material and OSCORE Sender ID 9.1.2. Get Group Keying Material and OSCORE Sender ID
If the group member wants to retrieve the latest group keying If the group member wants to retrieve the latest group keying
material as well as the OSCORE Sender ID that it has in the OSCORE material as well as the OSCORE Sender ID that it has in the OSCORE
group, it sends a Key Distribution Request to the Group Manager. group, it sends a Key Distribution Request to the Group Manager.
In particular, it sends a CoAP GET request to the endpoint /ace- In particular, it sends a CoAP GET request to the endpoint /ace-
group/GROUPNAME/nodes/NODENAME at the Group Manager. group/GROUPNAME/nodes/NODENAME at the Group Manager.
The Group Manager processes the Key Distribution Request according to The Group Manager processes the Key Distribution Request according to
Section 4.8.1 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution Section 4.8.1 of [I-D.ietf-ace-key-groupcomm]. The Key Distribution
Response is formatted as defined in Section 4.8.1 of Response is formatted as defined in Section 4.8.1 of
[I-D.ietf-ace-key-groupcomm], with the following additions. [I-D.ietf-ace-key-groupcomm], with the following additions.
* The 'key' parameter is formatted as defined in Section 6.4 of this * The 'key' parameter is formatted as defined in Section 6.3 of this
document. In particular, if the requesting group member has document. In particular, if the requesting group member has
exclusively the role of monitor, no 'group_SenderId' is specified exclusively the role of monitor, then the 'key' parameter does not
within the 'key' parameter. include the 'group_SenderId'.
Note that, in any other case, the current Sender ID of the group Note that, in any other case, the current Sender ID of the group
member is not specified as a separate parameter, but rather member is not specified as a separate parameter, but rather
specified as 'group_SenderId' within the 'key' parameter. specified by 'group_SenderId' within the 'key' parameter.
* The 'exp' parameter MUST be present. * The 'exp' parameter MUST be present.
Upon receiving the Key Distribution Response, the group member Upon receiving the Key Distribution Response, the group member
retrieves the updated security parameters, group keying material and retrieves the updated security parameters, group keying material and
Sender ID, and, if they differ from the current ones, uses them to Sender ID, and, if they differ from the current ones, uses them to
set up the new Group OSCORE Security Context as described in set up the new Group OSCORE Security Context as described in
Section 2 of [I-D.ietf-core-oscore-groupcomm]. Section 2 of [I-D.ietf-core-oscore-groupcomm].
9. Request to Change Individual Keying Material 9.2. Request to Change Individual Keying Material
As discussed in Section 2.5.2 of [I-D.ietf-core-oscore-groupcomm], a As discussed in Section 2.5.2 of [I-D.ietf-core-oscore-groupcomm], a
group member may at some point exhaust its Sender Sequence Numbers in group member may at some point exhaust its Sender Sequence Numbers in
the OSCORE group. the OSCORE group.
When this happens, the group member MUST send a Key Renewal Request When this happens, the group member MUST send a Key Renewal Request
message to the Group Manager, as per Section 4.8.2.1 of message to the Group Manager, as per Section 4.8.2.1 of
[I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP PUT
request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the
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.8.2 of [I-D.ietf-ace-key-groupcomm], with it as defined in Section 4.8.2 of [I-D.ietf-ace-key-groupcomm], with
the following additions. the following additions.
The Group Manager MUST return a 5.03 (Service Unavailable) response The Group Manager MUST return a 5.03 (Service Unavailable) response
in case the OSCORE group identified by GROUPNAME is currently in case the OSCORE group identified by GROUPNAME is currently
inactive (see Section 5.1). The response MUST have Content-Format inactive (see Section 8.1). The response MUST have Content-Format
set to application/ace-groupcomm+cbor and is formatted as defined in set to application/ace-groupcomm+cbor and is formatted as defined in
Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the
'error' field MUST be set to 9 ("Group currently not active"). 'error' field MUST be set to 9 ("Group currently not active").
Otherwise, the Group Manager performs one of the following actions. Otherwise, the Group Manager performs one of the following actions.
1. If the requesting group member has exclusively the role of 1. If the requesting group member has exclusively the role of
monitor, the Group Manager replies with a 4.03 (Forbidden) error monitor, the Group Manager replies with a 4.03 (Forbidden) error
response. The response MUST have Content-Format set to response. The response MUST have Content-Format set to
application/ace-groupcomm+cbor and is formatted as defined in application/ace-groupcomm+cbor and is formatted as defined in
Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the
'error' field MUST be set to 1 ("Request inconsistent with the 'error' field MUST be set to 1 ("Request inconsistent with the
current roles"). current roles").
2. Otherwise, the Group Manager takes one of the following actions. 2. Otherwise, the Group Manager takes one of the following actions.
* The Group Manager rekeys the OSCORE group. That is, the Group * The Group Manager rekeys the OSCORE group. That is, the Group
Manager generates new group keying material for that group Manager generates new group keying material for that group
(see Section 20), and replies to the group member with a group (see Section 11), and replies to the group member with a group
rekeying message as defined in Section 20, providing the new rekeying message as defined in Section 11, providing the new
group keying material. Then, the Group Manager rekeys the group keying material. Then, the Group Manager rekeys the
rest of the OSCORE group, as discussed in Section 20. rest of the OSCORE group, as discussed in Section 11.
The Group Manager SHOULD perform a group rekeying only if The Group Manager SHOULD perform a group rekeying only if
already scheduled to occur shortly, e.g., according to an already scheduled to occur shortly, e.g., according to an
application-dependent rekeying period or scheduling, or as a application-specific rekeying period or scheduling, or as a
reaction to a recent change in the group membership. In any reaction to a recent change in the group membership. In any
other case, the Group Manager SHOULD NOT rekey the OSCORE other case, the Group Manager SHOULD NOT rekey the OSCORE
group when receiving a Key Renewal Request (OPT12). group when receiving a Key Renewal Request (OPT12).
* The Group Manager determines and assigns a new OSCORE Sender * The Group Manager determines and assigns a new OSCORE Sender
ID for that group member, and replies with a Key Renewal ID for that group member, and replies with a Key Renewal
Response formatted as defined in Section 4.8.2 of Response formatted as defined in Section 4.8.2 of
[I-D.ietf-ace-key-groupcomm]. In particular, the CBOR Map in [I-D.ietf-ace-key-groupcomm]. In particular, the CBOR Map in
the response payload includes a single parameter the response payload includes a single parameter
'group_SenderId' defined in Section 25.3 of this document, 'group_SenderId' defined in Section 16.3 of this document,
specifying the new Sender ID of the group member encoded as a specifying the new Sender ID of the group member encoded as a
CBOR byte string. CBOR byte string.
Consistently with Section 2.5.3.1 of Consistently with Section 2.5.3.1 of
[I-D.ietf-core-oscore-groupcomm], the Group Manager MUST [I-D.ietf-core-oscore-groupcomm], the Group Manager MUST
assign a new Sender ID that has not been used in the OSCORE assign a new Sender ID that has not been used in the OSCORE
group since the latest time when the current Gid value was group since the latest time when the current Gid value was
assigned to the group. assigned to the group.
Furthermore, the Group Manager MUST add the old, relinquished Furthermore, the Group Manager MUST add the old, relinquished
Sender ID of the group member to the most recent set of stale Sender ID of the group member to the most recent set of stale
Sender IDs, in the collection associated with the group (see Sender IDs, in the collection associated with the group (see
Section 2.2.1). Section 7.1).
The Group Manager MUST return a 5.03 (Service Unavailable) The Group Manager MUST return a 5.03 (Service Unavailable)
response in case there are currently no Sender IDs available response in case there are currently no Sender IDs available
to assign in the OSCORE group. The response MUST have to assign in the OSCORE group. The response MUST have
Content-Format set to application/ace-groupcomm+cbor and is Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4.1.2 of formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field
MUST be set to 4 ("No available node identifiers"). MUST be set to 4 ("No available node identifiers").
10. Retrieve Authentication Credentials of Group Members 9.3. Retrieve Authentication Credentials of Group Members
A group member or a signature verifier may need to retrieve the A group member or a signature verifier may need to retrieve the
authentication credentials of (other) group members. To this end, authentication credentials of (other) group members. To this end,
the group member or signature verifier sends a Public Key Request the group member or signature verifier sends a Public Key Request
message to the Group Manager, as per Sections 4.4.1.1 and 4.4.2.1 of message to the Group Manager, as per Sections 4.4.1.1 and 4.4.2.1 of
[I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to [I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to
the endpoint /ace-group/GROUPNAME/pub-key at the Group Manager. the endpoint /ace-group/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.4.1 of Request is formatted as defined in Section 4.4.1 of
[I-D.ietf-ace-key-groupcomm]. In particular: [I-D.ietf-ace-key-groupcomm]. In particular:
* Each element (if any) of the inner CBOR array 'role_filter' is * Each element (if any) of the inner CBOR array 'role_filter' is
formatted as in the inner CBOR array 'role_filter' of the formatted as in the inner CBOR array 'role_filter' of the
'get_pub_keys' parameter of the Joining Request when the parameter 'get_pub_keys' parameter of the Joining Request when the parameter
value is not the CBOR simple value "null" (0xf6) (see value is not the CBOR simple value "null" (0xf6) (see
Section 6.2). Section 6.1).
* Each element (if any) of the inner CBOR array 'id_filter' is a * Each element (if any) of the inner CBOR array 'id_filter' is a
CBOR byte string, which encodes the OSCORE Sender ID of the group CBOR byte string, which encodes the OSCORE Sender ID of the group
member for which the associated authentication credential is member for which the associated authentication credential is
requested (REQ25). requested (REQ25).
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.4.1 or Section 4.4.2 of as per Section 4.4.1 or Section 4.4.2 of
[I-D.ietf-ace-key-groupcomm], depending on the request method being [I-D.ietf-ace-key-groupcomm], depending on the request method being
FETCH or GET, respectively. Additionally, if the Public Key Request FETCH or GET, respectively. Additionally, if the Public Key Request
uses the method FETCH, the Group Manager silently ignores node uses the method FETCH, the Group Manager silently ignores node
identifiers included in the 'get_pub_keys' parameter of the request identifiers included in the 'get_pub_keys' parameter of the request
that are not associated with any current group member (REQ26). that are not associated with any current group member (REQ26).
The success Public Key Response is formatted as defined in The success Public Key Response is formatted as defined in
Section 4.4.1 or Section 4.4.2 of [I-D.ietf-ace-key-groupcomm], Section 4.4.1 or Section 4.4.2 of [I-D.ietf-ace-key-groupcomm],
depending on the request method being FETCH or GET, respectively. depending on the request method being FETCH or GET, respectively.
11. Upload a New Authentication Credential 9.4. Upload a New Authentication Credential
A group member may need to provide the Group Manager with its new A group member may need to provide the Group Manager with its new
authentication credential to use in the group from then on, hence authentication credential to use in the group from then on, hence
replacing the current one. This can be the case, for instance, if replacing the current one. This can be the case, for instance, if
the signature or ECDH algorithm, and possible associated parameters the signature or ECDH algorithm and possible associated parameters
used in the OSCORE group have been changed, and the current used in the OSCORE group have been changed, and the current
authentication credential is not compatible with them. authentication credential is not compatible with them.
To this end, the group member sends a Public Key Update Request To this end, the group member sends a Public Key Update Request
message to the Group Manager, as per Section 4.9.1.1 of message to the Group Manager, as per Section 4.9.1.1 of
[I-D.ietf-ace-key-groupcomm], with the following addition. [I-D.ietf-ace-key-groupcomm], with the following addition.
* The group member computes the proof-of-possession (PoP) evidence * The group member computes the proof-of-possession (PoP) evidence
included in 'client_cred_verify' in the same way taken when included in 'client_cred_verify' in the same way taken when
preparing a Joining Request for the OSCORE group in question, as preparing a Joining Request for the OSCORE group in question, as
defined in Section 6.2 (REQ14). defined in Section 6.1 (REQ14).
In particular, the group member sends a CoAP POST request to the In particular, the group member sends a CoAP POST request to the
endpoint /ace-group/GROUPNAME/nodes/NODENAME/pub-key at the Group endpoint /ace-group/GROUPNAME/nodes/NODENAME/pub-key at the Group
Manager. Manager.
Upon receiving the Public Key Update Request, the Group Manager Upon receiving the Public Key Update Request, the Group Manager
processes it as per Section 4.9.1 of [I-D.ietf-ace-key-groupcomm], processes it as per Section 4.9.1 of [I-D.ietf-ace-key-groupcomm],
with the following additions. with the following additions.
* The N_S challenge used to build the proof-of-possession input is * The N_S challenge used to build the proof-of-possession input is
computed as per point (1) in Section 6.2.1 (REQ15). computed as defined in Section 6.1.1 (REQ15).
* The Group Manager verifies the PoP challenge included in * The Group Manager verifies the PoP challenge included in
'client_cred_verify' in the same way taken when processing a 'client_cred_verify' in the same way taken when processing a
Joining Request for the OSCORE group in question, as defined in Joining Request for the OSCORE group in question, as defined in
Section 6.3 (REQ14). Section 6.2 (REQ14).
* The Group Manager MUST return a 5.03 (Service Unavailable) * The Group Manager MUST return a 5.03 (Service Unavailable)
response in case the OSCORE group identified by GROUPNAME is response in case the OSCORE group identified by GROUPNAME is
currently inactive (see Section 5.1). The response MUST have currently inactive (see Section 8.1). The response MUST have
Content-Format set to application/ace-groupcomm+cbor and is Content-Format set to application/ace-groupcomm+cbor and is
formatted as defined in Section 4.1.2 of formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST
be set to 9 ("Group currently not active"). be set to 9 ("Group currently not active").
* If the requesting group member has exclusively the role of * If the requesting group member has exclusively the role of
monitor, the Group Manager replies with a 4.00 (Bad request) error monitor, the Group Manager replies with a 4.00 (Bad request) error
response. The response MUST have Content-Format set to response. The response MUST have Content-Format set to
application/ace-groupcomm+cbor and is formatted as defined in application/ace-groupcomm+cbor and is formatted as defined in
Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value of the
'error' field MUST be set to 1 ("Request inconsistent with the 'error' field MUST be set to 1 ("Request inconsistent with the
current roles"). current roles").
* If the request is successfully processed, the Group Manager stores * If the request is successfully processed, the Group Manager stores
the association between i) the new authentication credential of the association between i) the new authentication credential of
the group member; and ii) the Group Identifier (Gid), i.e., the the group member; and ii) the Group Identifier (Gid), i.e., the
OSCORE ID Context, associated with the OSCORE group together with OSCORE ID Context, associated with the OSCORE group together with
the OSCORE Sender ID assigned to the group member in the group. the OSCORE Sender ID assigned to the group member in the group.
The Group Manager MUST keep this association updated over time. The Group Manager MUST keep this association updated over time.
12. Retrieve the Group Manager's Authentication Credential 9.5. Retrieve the Group Manager's Authentication Credential
A group member or a signature verifier may need to retrieve the A group member or a signature verifier may need to retrieve the
authentication credential of the Group Manager. To this end, the authentication credential of the Group Manager. To this end, the
requesting client sends a KDC Public Key Request message to the Group requesting Client sends a KDC Public Key Request message to the Group
Manager. Manager.
In particular, it sends a CoAP GET request to the endpoint /ace- In particular, it sends a CoAP GET request to the endpoint /ace-
group/GROUPNAME/kdc-pub-key at the Group Manager defined in group/GROUPNAME/kdc-pub-key at the Group Manager defined in
Section 4.5.1.1 of [I-D.ietf-ace-key-groupcomm], where GROUPNAME is Section 4.5.1.1 of [I-D.ietf-ace-key-groupcomm], where GROUPNAME is
the name of the OSCORE group. the name of the OSCORE group.
In addition to what is defined in Section 4.5.1 of In addition to what is defined in Section 4.5.1 of
[I-D.ietf-ace-key-groupcomm], the Group Manager MUST respond with a [I-D.ietf-ace-key-groupcomm], the Group Manager MUST respond with a
4.00 (Bad Request) error response, if the requesting client is not a 4.00 (Bad Request) error response, if the requesting Client is not a
current group member and GROUPNAME denotes a pairwise-only group. current group member and GROUPNAME denotes a pairwise-only group.
The response MUST have Content-Format set to application/ace- The response MUST have Content-Format set to application/ace-
groupcomm+cbor and is formatted as defined in Section 4.1.2 of groupcomm+cbor and is formatted as defined in Section 4.1.2 of
[I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be [I-D.ietf-ace-key-groupcomm]. The value of the 'error' field MUST be
set to 7 ("Signatures not used in the group"). set to 7 ("Signatures not used in the group").
The payload of the 2.05 (Content) KDC Public Key Response is a CBOR The payload of the 2.05 (Content) KDC Public Key Response is a CBOR
map, which is formatted as defined in Section 4.5.1 of map, which is formatted as defined in Section 4.5.1 of
[I-D.ietf-ace-key-groupcomm]. In particular, the Group Manager [I-D.ietf-ace-key-groupcomm]. In particular, the Group Manager
specifies the parameters 'kdc_cred', 'kdc_nonce' and 'kdc_challenge' specifies the parameters 'kdc_cred', 'kdc_nonce' and 'kdc_challenge'
as defined for the Joining Response in Section 6.4 of this document. as defined for the Joining Response in Section 6.3 of this document.
This especially applies to the computing of the proof-of-possession This especially applies to the computing of the proof-of-possession
(PoP) evidence included in 'kdc_cred_verify' (REQ21). (PoP) evidence included in 'kdc_cred_verify' (REQ21).
Upon receiving a 2.05 (Content) KDC Public Key Response, the Upon receiving a 2.05 (Content) KDC Public Key Response, the
requesting client retrieves the Group Manager's authentication requesting Client retrieves the Group Manager's authentication
credential from the 'kdc_cred' parameter, and proceeds as defined in credential from the 'kdc_cred' parameter, and proceeds as defined in
Section 4.5.1.1 of [I-D.ietf-ace-key-groupcomm]. In particular, the Section 4.5.1.1 of [I-D.ietf-ace-key-groupcomm]. In particular, the
requesting client verifies the PoP evidence included in requesting Client verifies the PoP evidence included in
'kdc_cred_verify' by means of the same method used when processing 'kdc_cred_verify' by means of the same method used when processing
the Joining Response, as defined in Section 6.4 of this document the Joining Response, as defined in Section 6.3 of this document
(REQ21). (REQ21).
Note that a signature verifier would not receive a successful Note that a signature verifier would not receive a successful
response from the Group Manager, in case GROUPNAME denotes a response from the Group Manager, in case GROUPNAME denotes a
pairwise-only group. pairwise-only group.
13. Retrieve Signature Verification Data 9.6. Retrieve Signature Verification Data
A signature verifier may need to retrieve data required to verify A signature verifier may need to retrieve data required to verify
signatures of messages protected with the group mode and sent to a signatures of messages protected with the group mode and sent to a
group (see Sections 3.1 and 8.5 of [I-D.ietf-core-oscore-groupcomm]). group (see Sections 3.1 and 8.5 of [I-D.ietf-core-oscore-groupcomm]).
To this end, the signature verifier sends a Signature Verification To this end, the signature verifier sends a Signature Verification
Data Request message to the Group Manager. Data Request message to the Group Manager.
In particular, it sends a CoAP GET request to the endpoint /ace- In particular, it sends a CoAP GET request to the endpoint /ace-
group/GROUPNAME/verif-data at the Group Manager defined in group/GROUPNAME/verif-data at the Group Manager defined in
Section 5.2 of this document, where GROUPNAME is the name of the Section 8.2 of this document, where GROUPNAME is the name of the
OSCORE group. OSCORE group.
The payload of the 2.05 (Content) Signature Verification Data The payload of the 2.05 (Content) Signature Verification Data
Response is a CBOR map, which has the format used for the Joining Response is a CBOR map, which has the format used for the Joining
Response message in Section 6.4, with the following differences. Response message in Section 6.3, with the following differences.
* From the Joining Response message, only the parameters 'gkty', * From the Joining Response message, only the parameters 'gkty',
'key', 'num', 'exp' and 'ace-groupcomm-profile' are present. In 'key', 'num', 'exp' and 'ace-groupcomm-profile' are present. In
particular, the 'key' parameter includes only the following data. particular, the 'key' parameter includes only the following data.
- The parameters 'hkdf', 'contextId', 'cred_fmt', 'sign_enc_alg', - The parameters 'hkdf', 'contextId', 'cred_fmt', 'sign_enc_alg',
'sign_alg', 'sign_params'. These parameters MUST be present. 'sign_alg', 'sign_params'. These parameters MUST be present.
- The parameters 'alg' and 'ecdh_alg'. These parameter MUST NOT - The parameters 'alg' and 'ecdh_alg'. These parameter MUST NOT
be present if the group is a signature-only group. Otherwise, be present if the group is a signature-only group. Otherwise,
they MUST be present. they MUST be present.
* The parameter 'group_enc_key' is also included, with CBOR label * The parameter 'group_enc_key' is also included, with CBOR label
defined in Section 25.3. This parameter specifies the Group defined in Section 16.3. This parameter specifies the Group
Encryption Key of the OSCORE Group, encoded as a CBOR byte string. Encryption Key of the OSCORE Group, encoded as a CBOR byte string.
The Group Manager derives the Group Encryption Key from the group The Group Manager derives the Group Encryption Key from the group
keying material, as per Section 2.1.6 of keying material, as per Section 2.1.6 of
[I-D.ietf-core-oscore-groupcomm]. This parameter MUST be present. [I-D.ietf-core-oscore-groupcomm]. This parameter MUST be present.
In order to verify signatures in the group (see Section 8.5 of In order to verify signatures in the group (see Section 8.5 of
[I-D.ietf-core-oscore-groupcomm]), the signature verifier relies on: [I-D.ietf-core-oscore-groupcomm]), the signature verifier relies on:
the data retrieved from the 2.05 (Content) Signature Verification the data retrieved from the 2.05 (Content) Signature Verification
Data Response; the public keys of the group members signing the Data Response; the public keys of the group members signing the
messages to verify, retrieved from those members' authentication messages to verify, retrieved from those members' authentication
credentials that can be obtained as defined in Section 10; and the credentials that can be obtained as defined in Section 9.3; and the
public key of the Group Manager, retrieved from the Group Manager's public key of the Group Manager, retrieved from the Group Manager's
authentication credential that can be obtained as defined in authentication credential that can be obtained as defined in
Section 12. Section 9.5.
Figure 3 gives an overview of the exchange described above, while Figure 3 gives an overview of the exchange described above, while
Figure 4 shows an example. Figure 4 shows an example.
Signature Group Signature Group
Verifier Manager Verifier Manager
| | | |
| Signature Verification Data Request | | Signature Verification Data Request |
|------------------------------------------------------------>| |------------------------------------------------------------>|
| GET ace-group/GROUPNAME/verif-data | | GET ace-group/GROUPNAME/verif-data |
skipping to change at page 48, line 24 skipping to change at page 49, line 37
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor" Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation, with GROUPCOMM_KEY_TBD Payload (in CBOR diagnostic notation, with GROUPCOMM_KEY_TBD
and PROFILE_TBD being CBOR integers, while GROUP_ENC_KEY and PROFILE_TBD being CBOR integers, while GROUP_ENC_KEY
being a CBOR byte string): being a CBOR byte string):
{ {
"gkty": GROUPCOMM_KEY_TBD, "gkty": GROUPCOMM_KEY_TBD,
"key": { "key": {
'hkdf': -10, ; HKDF SHA-256 'hkdf': 5, ; HMAC 256/256
'contextId': h'37fc', 'contextId': h'37fc',
'cred_fmt': 33, ; x5chain 'cred_fmt': 33, ; x5chain
'sign_enc_alg': 10, ; AES-CCM-16-64-128 'sign_enc_alg': 10, ; AES-CCM-16-64-128
'sign_alg': -8, ; EdDSA 'sign_alg': -8, ; EdDSA
'sign_params': [[1], [1, 6]] ; [[OKP], [OKP, Ed25519]] 'sign_params': [[1], [1, 6]] ; [[OKP], [OKP, Ed25519]]
}, },
"num": 12, "num": 12,
"exp": 1609459200, "exp": 1609459200,
"ace_groupcomm_profile": PROFILE_TBD, "ace_groupcomm_profile": PROFILE_TBD,
"group_enc_key": GROUP_ENC_KEY "group_enc_key": GROUP_ENC_KEY
} }
Figure 4: Example of Signature Verification Data Request-Response Figure 4: Example of Signature Verification Data Request-Response
14. Retrieve the Group Policies 9.7. Retrieve the Group Policies
A group member may request the current policies used in the OSCORE A group member may request the current policies used in the OSCORE
group. To this end, the group member sends a Policies Request, as group. To this end, the group member sends a Policies Request, as
per Section 4.6.1.1 of [I-D.ietf-ace-key-groupcomm]. In particular, per Section 4.6.1.1 of [I-D.ietf-ace-key-groupcomm]. In particular,
it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/ it sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/
policies at the Group Manager, where GROUPNAME is the name of the policies at the Group Manager, where GROUPNAME is the name of the
OSCORE group. OSCORE group.
Upon receiving the Policies Request, the Group Manager processes it Upon receiving the Policies Request, the Group Manager processes it
as per Section 4.6.1 of [I-D.ietf-ace-key-groupcomm]. The success as per Section 4.6.1 of [I-D.ietf-ace-key-groupcomm]. The success
Policies Response is formatted as defined in Section 4.6.1 of Policies Response is formatted as defined in Section 4.6.1 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
15. Retrieve the Keying Material Version 9.8. Retrieve the Keying Material Version
A group member may request the current version of the keying material A group member may request the current version of the keying material
used in the OSCORE group. To this end, the group member sends a used in the OSCORE group. To this end, the group member sends a
Version Request, as per Section 4.7.1.1 of Version Request, as per Section 4.7.1.1 of
[I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET
request to the endpoint /ace-group/GROUPNAME/num at the Group request to the endpoint /ace-group/GROUPNAME/num at the Group
Manager, where GROUPNAME is the name of the OSCORE group. Manager, where GROUPNAME is the name of the OSCORE group.
Upon receiving the Version Request, the Group Manager processes it as Upon receiving the Version Request, the Group Manager processes it as
per Section 4.7.1 of [I-D.ietf-ace-key-groupcomm]. The success per Section 4.7.1 of [I-D.ietf-ace-key-groupcomm]. The success
Version Response is formatted as defined in Section 4.7.1 of Version Response is formatted as defined in Section 4.7.1 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
16. Retrieve the Group Status 9.9. Retrieve the Group Status
A group member may request the current status of the the OSCORE A group member may request the current status of the the OSCORE
group, i.e., active or inactive. To this end, the group member sends group, i.e., active or inactive. To this end, the group member sends
a Group Status Request to the Group Manager. a Group Status Request to the Group Manager.
In particular, the group member sends a CoAP GET request to the In particular, the group member sends a CoAP GET request to the
endpoint /ace-group/GROUPNAME/active at the Group Manager defined in endpoint /ace-group/GROUPNAME/active at the Group Manager defined in
Section 5.1 of this document, where GROUPNAME is the name of the Section 8.1 of this document, where GROUPNAME is the name of the
OSCORE group. OSCORE group.
The payload of the 2.05 (Content) Group Status Response includes the The payload of the 2.05 (Content) Group Status Response includes the
CBOR simple value "true" (0xf5) if the group is currently active, or CBOR simple value "true" (0xf5) if the group is currently active, or
the CBOR simple value "false" (0xf4) otherwise. The group is the CBOR simple value "false" (0xf4) otherwise. The group is
considered active if it is set to allow new members to join, and if considered active if it is set to allow new members to join, and if
communication within the group is fine to happen. communication within the group is fine to happen.
Upon learning from a 2.05 (Content) response that the group is Upon learning from a 2.05 (Content) response that the group is
currently inactive, the group member SHOULD stop taking part in currently inactive, the group member SHOULD stop taking part in
skipping to change at page 50, line 32 skipping to change at page 51, line 39
Payload: - Payload: -
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Payload (in CBOR diagnostic notation): Payload (in CBOR diagnostic notation):
true true
Figure 6: Example of Group Status Request-Response Figure 6: Example of Group Status Request-Response
17. Retrieve Group Names 9.10. Retrieve Group Names
A node may want to retrieve from the Group Manager the group name and A node may want to retrieve from the Group Manager the group name and
the URI of the group-membership resource of a group. This is the URI of the group-membership resource of a group. This is
relevant in the following cases. relevant in the following cases.
* Before joining a group, a joining node may know only the current * Before joining a group, a joining node may know only the current
Group Identifier (Gid) of that group, but not the group name and Group Identifier (Gid) of that group, but not the group name and
the URI to the group-membership resource. the URI to the group-membership resource.
* As current group member in several groups, the node has missed a * As current group member in several groups, the node has missed a
previous group rekeying in one of them (see Section 20). Hence, previous group rekeying in one of them (see Section 11). Hence,
it retains stale keying material and fails to decrypt received it retains stale keying material and fails to decrypt received
messages exchanged in that group. messages exchanged in that group.
Such messages do not provide a direct hint to the correct group Such messages do not provide a direct hint to the correct group
name, that the node would need in order to retrieve the latest name, that the node would need in order to retrieve the latest
keying material and authentication credentials from the Group keying material and authentication credentials from the Group
Manager (see Section 8.1, Section 8.2 and Section 10). However, Manager (see Section 9.1.1, Section 9.1.2 and Section 9.3).
such messages may specify the current Gid of the group, as value However, such messages may specify the current Gid of the group,
of the 'kid_context' field of the OSCORE CoAP option (see as value of the 'kid_context' field of the OSCORE CoAP option (see
Section 6.1 of [RFC8613] and Section 4.2 of Section 6.1 of [RFC8613] and Section 4.2 of
[I-D.ietf-core-oscore-groupcomm]). [I-D.ietf-core-oscore-groupcomm]).
* As signature verifier, the node also refers to a group name for * As signature verifier, the node also refers to a group name for
retrieving the required authentication credentials from the Group retrieving the required authentication credentials from the Group
Manager (see Section 10). As discussed above, intercepted Manager (see Section 9.3). As discussed above, intercepted
messages do not provide a direct hint to the correct group name, messages do not provide a direct hint to the correct group name,
while they may specify the current Gid of the group, as value of while they may specify the current Gid of the group, as value of
the 'kid_context' field of the OSCORE CoAP option. In such a the 'kid_context' field of the OSCORE CoAP option. In such a
case, upon intercepting a message in the group, the node requires case, upon intercepting a message in the group, the node requires
to correctly map the Gid currently used in the group with the to correctly map the Gid currently used in the group with the
invariant group name. invariant group name.
Furthermore, since it is not a group member, the node does not Furthermore, since it is not a group member, the node does not
take part to a possible group rekeying. Thus, following a group take part to a possible group rekeying. Thus, following a group
rekeying and the consequent change of Gid in a group, the node rekeying and the consequent change of Gid in a group, the node
skipping to change at page 52, line 17 skipping to change at page 53, line 17
[I-D.ietf-ace-key-groupcomm]. The success Group Name and URI [I-D.ietf-ace-key-groupcomm]. The success Group Name and URI
Retrieval Response is formatted as defined in Section 4.2.1 of Retrieval Response is formatted as defined in Section 4.2.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
CBOR array 'gid' is a CBOR byte string (REQ13), which encodes the Gid CBOR array 'gid' is a CBOR byte string (REQ13), which encodes the Gid
of the group for which the group name and the URI to the group- of the group for which the group name and the URI to the group-
membership resource are provided. membership resource are provided.
For each of its groups, the Group Manager maintains an association For each of its groups, the Group Manager maintains an association
between the group name and the URI to the group-membership resource between the group name and the URI to the group-membership resource
on one hand, and only the current Gid for that group on the other on one hand, and only the current Gid for that group on the other
hand. That is, the Group Manager MUST NOT maintain an association hand. That is, the Group Manager does not maintain an association
between the former pair and any other Gid for that group than the between the former pair and any other Gid for that group than the
current, most recent one. current, most recent one.
Figure 7 gives an overview of the exchanges described above, while Figure 7 gives an overview of the exchanges described above, while
Figure 8 shows an example. Figure 8 shows an example.
Group Group
Node Manager Node Manager
| | | |
|---- Group Name and URI Retrieval Request: FETCH ace-group/ --->| |---- Group Name and URI Retrieval Request: FETCH ace-group/ --->|
skipping to change at page 53, line 29 skipping to change at page 54, line 29
Content-Format: "application/ace-groupcomm+cbor" Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation): Payload (in CBOR diagnostic notation):
{ {
"gid": [h'37fc', h'84bd'], "gid": [h'37fc', h'84bd'],
"gname": ["g1", "g2"], "gname": ["g1", "g2"],
"guri": ["ace-group/g1", "ace-group/g2"] "guri": ["ace-group/g1", "ace-group/g2"]
} }
Figure 8: Example of Group Name and URI Retrieval Request-Response Figure 8: Example of Group Name and URI Retrieval Request-Response
18. Leave the Group 9.11. Leave the Group
A group member may request to leave the OSCORE group. To this end, A group member may request to leave the OSCORE group. To this end,
the group member sends a Group Leaving Request, as per the group member sends a Group Leaving Request, as per
Section 4.8.3.1 of [I-D.ietf-ace-key-groupcomm]. In particular, it Section 4.8.3.1 of [I-D.ietf-ace-key-groupcomm]. In particular, it
sends a CoAP DELETE request to the endpoint /ace- sends a CoAP DELETE request to the endpoint /ace-
group/GROUPNAME/nodes/NODENAME at the Group Manager. group/GROUPNAME/nodes/NODENAME at the Group Manager.
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.8.3 of [I-D.ietf-ace-key-groupcomm]. Then, the it as per Section 4.8.3 of [I-D.ietf-ace-key-groupcomm]. Then, the
Group Manager performs the follow-up actions defined in Section 19. Group Manager performs the follow-up actions defined in Section 10 of
this document.
19. Removal of a Group Member 10. 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 18, a node may be forcibly removed from the described in Section 9.11, 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 Group Manager reassigns Gid values during the In either case, if the Group Manager reassigns Gid values during the
group's lifetime (see Section 3.2.1.1 of group's lifetime (see Section 3.2.1.1 of
[I-D.ietf-core-oscore-groupcomm]), the Group Manager "forgets" the [I-D.ietf-core-oscore-groupcomm]), the Group Manager "forgets" the
Birth Gid currently associated with the leaving node in the OSCORE Birth Gid currently associated with the leaving node in the OSCORE
group. This was stored following the Joining Response sent to that group. This was stored following the Joining Response sent to that
node, after its latest (re-)joining of the OSCORE group (see node, after its latest (re-)joining of the OSCORE group (see
Section 6.4). Section 6.3).
If any of the two conditions below holds, the Group Manager MUST If any of the two conditions below holds, the Group Manager MUST
inform the leaving node of its eviction as follows. If both inform the leaving node of its eviction as follows. If both
conditions hold, the Group Manager MUST inform the leaving node only conditions hold, the Group Manager MUST inform the leaving node by
once, using either of the corresponding methods. using only the method corresponding to one of either conditions.
* If, upon joining the group (see Section 6.2), the leaving node * If, upon joining the group (see Section 6.1), the leaving node
specified a URI in the 'control_uri' parameter defined in specified a URI in the 'control_uri' parameter defined in
Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], the Group Manager
sends a DELETE request targeting the URI specified in the sends a DELETE request targeting the URI specified in the
'control_uri' parameter (OPT7). 'control_uri' parameter (OPT7).
* If, when sending Joining Responses to nodes joining the group (see
Section 6.4) the Group Manager specifies a URI in the
'control_group_uri' parameter defined in Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm], the Group Manager sends a DELETE
request targeting the URI specified in the 'control_group_uri'
parameter (OPT10).
* If the leaving node has been observing the associated resource at * If the leaving node has been observing the associated resource at
ace-group/GROUPNAME/nodes/NODENAME, the Group Manager sends an ace-group/GROUPNAME/nodes/NODENAME, the Group Manager sends an
unsolicited 4.04 (Not Found) error response to the leaving node, unsolicited 4.04 (Not Found) error response to the leaving node,
as specified in Section 4.3.2 of [I-D.ietf-ace-key-groupcomm]. as specified in Section 4.3.2 of [I-D.ietf-ace-key-groupcomm].
Furthermore, the Group Manager might intend to evict all the current
group members from the group at once. In such a case, if the Joining
Responses sent by the Group Manager to nodes joining the group (see
Section 6.3) specify a URI in the 'control_group_uri' parameter
defined in Section 4.3.1 of [I-D.ietf-ace-key-groupcomm], then the
Group Manager MUST additionally send a DELETE request targeting the
URI specified in the 'control_group_uri' parameter (OPT10).
If the leaving node has not exclusively the role of monitor, the If the leaving node has not exclusively the role of monitor, the
Group Manager performs the following actions. Group Manager performs the following actions.
* The Group Manager frees the OSCORE Sender ID value of the leaving * The Group Manager frees the OSCORE Sender ID value of the leaving
node. This value MUST NOT become available for possible upcoming node. This value MUST NOT become available for possible upcoming
joining nodes in the same group, until the group has been rekeyed joining nodes in the same group, until the group has been rekeyed
and assigned a new Group Identifier (Gid). and assigned a new Group Identifier (Gid).
* The Group Manager MUST add the relinquished Sender ID of the * The Group Manager MUST add the relinquished Sender ID of the
leaving node to the most recent set of stale Sender IDs, in the leaving node to the most recent set of stale Sender IDs, in the
collection associated with the group (see Section 2.2.1). collection associated with the group (see Section 7.1).
* The Group Manager cancels the association between, on one hand, * The Group Manager cancels the association between, on one hand,
the authentication credential of the leaving node and, on the the authentication credential of the leaving node and, on the
other hand, the Gid associated with the OSCORE group together with other hand, the Gid associated with the OSCORE group together with
the freed Sender ID value. The Group Manager deletes the the freed Sender ID value. The Group Manager deletes the
authentication credential of the leaving node, if that authentication credential of the leaving node, if that
authentication credential has no remaining association with any authentication credential has no remaining association with any
pair (Gid, Sender ID). pair (Gid, Sender ID).
Then, the Group Manager MUST generate updated security parameters and Then, the Group Manager MUST generate updated security parameters and
group keying material, and provide it to the remaining group members group keying material, and provide it to the remaining group members
(see Section 20). As a consequence, the leaving node is not able to (see Section 11). As a consequence, the leaving node is not able to
acquire the new security parameters and group keying material acquire the new security parameters and group keying material
distributed after its leaving. distributed after its leaving.
The same considerations from Section 5 of The same considerations from Section 5 of
[I-D.ietf-ace-key-groupcomm] apply here as well, considering the [I-D.ietf-ace-key-groupcomm] apply here as well, considering the
Group Manager acting as KDC. Group Manager acting as KDC.
20. Group Rekeying Process 11. Group Rekeying Process
In order to rekey the OSCORE group, the Group Manager distributes a In order to rekey the OSCORE group, the Group Manager distributes a
new Group Identifier (Gid), i.e., a new OSCORE ID Context; a new new Group Identifier (Gid), i.e., a new OSCORE ID Context; a new
OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for OSCORE Master Secret; and, optionally, a new OSCORE Master Salt for
that group. When doing so, the Group Manager MUST increment the that group. When doing so, the Group Manager MUST increment the
version number of the group keying material, before starting its version number of the group keying material, before starting its
distribution. distribution.
As per Section 3.2.1.1 of [I-D.ietf-core-oscore-groupcomm], the Group As per Section 3.2.1.1 of [I-D.ietf-core-oscore-groupcomm], the Group
Manager MAY reassign a Gid to the same group over that group's Manager MAY reassign a Gid to the same group over that group's
lifetime, e.g., once the whole space of Gid values has been used for lifetime, e.g., once the whole space of Gid values has been used for
the group in question. If the Group Manager supports reassignment of the group in question. If the Group Manager supports reassignment of
Gid values and performs it in a group, then the Group Manager Gid values and performs it in a group, then the Group Manager
additionally takes the following actions. additionally takes the following actions.
* Before rekeying the group, the Group Manager MUST check if the new * Before rekeying the group, the Group Manager MUST check if the new
Gid to be distributed coincides with the Birth Gid of any of the Gid to be distributed coincides with the Birth Gid of any of the
current group members (see Section 6.4). current group members (see Section 6.3).
* If any of such "elder members" is found in the group, the Group * If any of such "elder members" is found in the group, the Group
Manager MUST evict them from the group. That is, the Group Manager MUST evict them from the group. That is, the Group
Manager MUST terminate their membership and MUST rekey the group Manager MUST terminate their membership and MUST rekey the group
in such a way that the new keying material is not provided to in such a way that the new keying material is not provided to
those evicted elder members. This also includes adding their those evicted elder members. This also includes adding their
relinquished Sender IDs to the most recent set of stale Sender relinquished Sender IDs to the most recent set of stale Sender
IDs, in the collection associated with the group (see IDs, in the collection associated with the group (see
Section 2.2.1), before rekeying the group. Section 7.1), before rekeying the group.
Until a further following group rekeying, the Group Manager MUST Until a further following group rekeying, the Group Manager MUST
store the list of those latest-evicted elder members. If any of store the list of those latest-evicted elder members. If any of
those nodes re-joins the group before a further following group those nodes re-joins the group before a further following group
rekeying occurs, the Group Manager MUST NOT rekey the group upon rekeying occurs, the Group Manager MUST NOT rekey the group upon
their re-joining. When one of those nodes re-joins the group, the their re-joining. When one of those nodes re-joins the group, the
Group Manager can rely, e.g., on the ongoing secure communication Group Manager can rely, e.g., on the ongoing secure communication
association to recognize the node as included in the stored list. association to recognize the node as included in the stored list.
Across the rekeying execution, the Group Manager MUST preserve the Across the rekeying execution, the Group Manager MUST preserve the
same unchanged OSCORE Sender IDs for all group members intended to same unchanged OSCORE Sender IDs for all group members intended to
remain in the group. This avoids affecting the retrieval of remain in the group. This avoids affecting the retrieval of
authentication credentials from the Group Manager and the authentication credentials from the Group Manager and the
verification of group messages. verification of group messages.
The Group Manager MUST support the "Point-to-Point" group rekeying The Group Manager MUST support the "Point-to-Point" group rekeying
scheme registered in Section 11.14 of [I-D.ietf-ace-key-groupcomm], scheme registered in Section 11.14 of [I-D.ietf-ace-key-groupcomm],
as per the detailed use defined in Section 20.1 of this document. as per the detailed use defined in Section 11.1 of this document.
Future specifications may define how this application profile can use Future specifications may define how this application profile can use
alternative group rekeying schemes, which MUST comply with the alternative group rekeying schemes, which MUST comply with the
functional steps defined in Section 3.2 of functional steps defined in Section 3.2 of
[I-D.ietf-core-oscore-groupcomm]. The Group Manager MUST indicate [I-D.ietf-core-oscore-groupcomm]. The Group Manager MUST indicate
the use of such an alternative group rekeying scheme to joining the use of such an alternative group rekeying scheme to joining
nodes, by means of the 'group_rekeying' parameter included in Joining nodes, by means of the 'group_rekeying' parameter included in Joining
Response messages (see Section 6.4). Response messages (see Section 6.3).
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.
Once completed the group rekeying process, the Group Manager creates Once completed the group rekeying process, the Group Manager creates
a new empty set X' of stale Sender IDs associated with the version of a new empty set X' of stale Sender IDs associated with the version of
the newly distributed group keying material. Then, the Group Manager the newly distributed group keying material. Then, the Group Manager
MUST add the set X' to the collection of stale Sender IDs associated MUST add the set X' to the collection of stale Sender IDs associated
with the group (see Section 2.2.1). with the group (see Section 7.1).
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.
Some of these group members may be in multiple groups, each Some of these group members may be in multiple groups, each
associated with a different Group Manager. When failing to correctly associated with a different Group Manager. When failing to correctly
process messages secured with the new keying material, these group process messages secured with the new keying material, these group
members may not have sufficient information to determine which exact members may not have sufficient information to determine which exact
Group Manager they should contact, in order to retrieve the current Group Manager they should contact, in order to retrieve the current
keying material they are missing. keying material they are missing.
If the Gid is formatted as described in Appendix C of If the Gid is formatted as described in Appendix C of
[I-D.ietf-core-oscore-groupcomm], the Group Prefix can be used as a [I-D.ietf-core-oscore-groupcomm], the Group Prefix can be used as a
hint to determine the right Group Manager, as long as no collisions hint to determine the right Group Manager, as long as no collisions
among Group Prefixes are experienced. Otherwise, a group member among Group Prefixes are experienced. Otherwise, a group member
needs to contact the Group Manager of each group, e.g., by first needs to contact the Group Manager of each group, e.g., by first
requesting only the version of the current group keying material (see requesting only the version of the current group keying material (see
Section 15) and then possibly requesting the current keying material Section 9.8) and then possibly requesting the current keying material
(see Section 8.1). (see Section 9.1.1).
Furthermore, some of these group members can be in multiple groups, Furthermore, some of these group members can be in multiple groups,
all of which associated with the same Group Manager. In this case, all of which associated with the same Group Manager. In this case,
these group members may also not have sufficient information to these group members may also not have sufficient information to
determine which exact group they should refer to, when contacting the determine which exact group they should refer to, when contacting the
right Group Manager. Hence, they need to contact a Group Manager right Group Manager. Hence, they need to contact a Group Manager
multiple times, i.e., separately for each group they belong to and multiple times, i.e., separately for each group they belong to and
associated with that Group Manager. associated with that Group Manager.
Finally, Section 20.3 discusses how a group member can realize that Section 11.2 defines the actions performed by a group member upon
it has missed one or more rekeying instances, and the actions it is receiving the new group keying material. Section 11.3 discusses how
accordingly required to take. a group member can realize that it has missed one or more rekeying
instances, and the actions it is accordingly required to take.
20.1. Sending Rekeying Messages 11.1. Sending Rekeying Messages
The group rekeying messages MUST have Content-Format set to When using the "Point-to-Point" group rekeying scheme, the group
application/ace-groupcomm+cbor and have the same format used for the rekeying messages MUST have Content-Format set to application/ace-
Joining Response message in Section 6.4, with the following groupcomm+cbor and have the same format used for the Joining Response
differences. Note that this extends the minimal content of a message in Section 6.3, with the following differences. Note that
rekeying message as defined in Section 6 of this extends the minimal content of a rekeying message as defined in
[I-D.ietf-ace-key-groupcomm] (OPT14). Section 6 of [I-D.ietf-ace-key-groupcomm] (OPT14).
* From the Joining Response, only the parameters 'gkty', 'key', * From the Joining Response, only the parameters 'gkty', 'key',
'num', 'exp', and 'ace-groupcomm-profile' are present. In 'num', 'exp', and 'ace-groupcomm-profile' are present. In
particular, the 'key' parameter includes only the following data. particular, the 'key' parameter includes only the following data.
- The 'ms' parameter, specifying the new OSCORE Master Secret - The 'ms' parameter, specifying the new OSCORE Master Secret
value. This parameter MUST be present. value. This parameter MUST be present.
- The 'contextId' parameter, specifying the new Gid to use as - The 'contextId' parameter, specifying the new Gid to use as
OSCORE ID Context value. This parameter MUST be present. OSCORE ID Context value. This parameter MUST be present.
- The 'salt' value, specifying the new OSCORE Master Salt value. - The 'salt' value, specifying the new OSCORE Master Salt value.
This parameter MAY be present. This parameter MAY be present.
* The parameter 'stale_node_ids' MUST also be included, with CBOR * The parameter 'stale_node_ids' MUST also be included, with CBOR
label defined in Section 25.3. This parameter is encoded as a label defined in Section 16.3. This parameter is encoded as a
CBOR array, where each element is encoded as a CBOR byte string. CBOR array, where each element is encoded as a CBOR byte string.
The CBOR array has to be intended as a set, i.e., the order of its The CBOR array has to be intended as a set, i.e., the order of its
elements is irrelevant. The parameter is populated as follows. elements is irrelevant. The parameter is populated as follows.
- The Group Manager creates an empty CBOR array ARRAY. - The Group Manager creates an empty CBOR array ARRAY.
- The Group Manager considers the collection of stale Sender IDs - The Group Manager considers the collection of stale Sender IDs
associated with the group (see Section 2.2.1), and takes the associated with the group (see Section 7.1), and takes the most
most recent set X, i.e., the set associated with the current recent set X, i.e., the set associated with the current version
version of the group keying material about to be relinquished. of the group keying material about to be relinquished.
- For each Sender ID in X, the Group Manager encodes it as a CBOR - For each Sender ID in X, the Group Manager encodes it as a CBOR
byte string and adds the result to ARRAY. byte string and adds the result to ARRAY.
- The parameter 'stale_node_ids' takes ARRAY as value. - The parameter 'stale_node_ids' takes ARRAY as value.
* The parameters 'pub_keys', 'peer_roles' and 'peer_identifiers' * The parameters 'pub_keys', 'peer_roles' and 'peer_identifiers'
SHOULD be present, if the group rekeying is performed due to one SHOULD be present, if the group rekeying is performed due to one
or multiple Clients that have requested join the group. Following or multiple Clients that have requested to join the group.
the same semantics used in the Joining Response message (see Following the same semantics used in the Joining Response message
Section 6.4), the three parameters specify the authentication (see Section 6.3), the three parameters specify the authentication
credential, roles in the group and node identifier of each of the credential, roles in the group and node identifier of each of the
Clients that have requested to join the group. The Group Manager Clients that have requested to join the group. The Group Manager
MUST NOT include a non-empty subset of these three parameters. MUST NOT include a non-empty subset of these three parameters.
The Group Manager separately sends a group rekeying message formatted The Group Manager separately sends a group rekeying message formatted
as defined above to each group member to be rekeyed. as defined above to each 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 association between the Group Manager and the group
used during the joining process. In particular, each rekeying member used during the joining process. In particular, each rekeying
message can target the 'control_uri' URI path defined in message can target the 'control_uri' URI path defined in
Section 4.3.1 of [I-D.ietf-ace-key-groupcomm] (OPT7), if provided by Section 4.3.1 of [I-D.ietf-ace-key-groupcomm] (OPT7), if provided by
the intended recipient upon joining the group (see Section 6.2). the intended recipient upon joining the group (see Section 6.1).
This distribution approach requires group members to act (also) as This distribution approach requires group members to act (also) as
servers, in order to correctly handle unsolicited group rekeying servers, in order to correctly handle unsolicited group rekeying
messages from the Group Manager. In particular, if a group member messages from the Group Manager. In particular, if a group member
and the Group Manager use OSCORE [RFC8613] to secure their pairwise and the Group Manager use OSCORE [RFC8613] to secure their pairwise
communications, the group member MUST create a Replay Window in its communications, the group member MUST create a Replay Window in its
own Recipient Context upon establishing the OSCORE Security Context own Recipient Context upon establishing the OSCORE Security Context
with the Group Manager, e.g., by means of the OSCORE profile of ACE with the Group Manager, e.g., by means of the OSCORE profile of ACE
[I-D.ietf-ace-oscore-profile]. [I-D.ietf-ace-oscore-profile].
skipping to change at page 59, line 9 skipping to change at page 60, line 18
Section 6 of [I-D.ietf-ace-key-groupcomm]. In particular, a group Section 6 of [I-D.ietf-ace-key-groupcomm]. In particular, a group
member may use CoAP Observe [RFC7641] and subscribe for updates to member may use CoAP Observe [RFC7641] and subscribe for updates to
the group-membership resource of the group, at the endpoint /ace- the group-membership resource of the group, at the endpoint /ace-
group/GROUPNAME/ of the Group Manager (see Section 6.1 of group/GROUPNAME/ of the Group Manager (see Section 6.1 of
[I-D.ietf-ace-key-groupcomm]). Alternatively, a full-fledged Pub-Sub [I-D.ietf-ace-key-groupcomm]). Alternatively, a full-fledged Pub-Sub
model can be considered [I-D.ietf-core-coap-pubsub], where the Group model can be considered [I-D.ietf-core-coap-pubsub], where the Group
Manager publishes to a rekeying topic hosted at a Broker, while the Manager publishes to a rekeying topic hosted at a Broker, while the
group members subscribe to such topic (see Section 6.2 of group members subscribe to such topic (see Section 6.2 of
[I-D.ietf-ace-key-groupcomm]). [I-D.ietf-ace-key-groupcomm]).
20.2. Receiving Rekeying Messages 11.2. Receiving Rekeying Messages
Once received the new group keying material, a group member proceeds Once received the new group keying material, a group member proceeds
as follows. as follows. Unless otherwise specified, the following is independent
of the specifically used group rekeying scheme.
The group member considers the stale Sender IDs received from the The group member considers the stale Sender IDs received from the
Group Manager. If the group rekeying scheme defined in Section 20.1 Group Manager. If the "Point-to-Point" group rekeying scheme as
is used, the stale Sender IDs are specified by the 'stale_node_ids' detailed in Section 11.1 is used, the stale Sender IDs are specified
parameter. by the 'stale_node_ids' parameter.
After that, as per Section 3.2 of [I-D.ietf-core-oscore-groupcomm], After that, as per Section 3.2 of [I-D.ietf-core-oscore-groupcomm],
the group member MUST remove every authentication credential the group member MUST remove every authentication credential
associated with a stale Sender ID from its list of group members' associated with a stale Sender ID from its list of group members'
authentication credentials used in the group, and MUST delete each of authentication credentials used in the group, and MUST delete each of
its Recipient Contexts used in the group whose corresponding its Recipient Contexts used in the group whose corresponding
Recipient ID is a stale Sender ID. Recipient ID is a stale Sender ID.
Then, the following cases can occur, based on the version number V' Then, the following cases can occur, based on the version number V'
of the new group keying material distributed through the rekeying of the new group keying material distributed through the rekeying
process. If the group rekeying scheme defined in Section 20.1 is process. If the "Point-to-Point" group rekeying scheme as detailed
used, this information is specified by the 'num' parameter. in Section 11.1 is used, this information is specified by the 'num'
parameter.
* The group member has not missed any group rekeying. That is, the * The group member has not missed any group rekeying. That is, the
old keying material stored by the group member has version number old keying material stored by the group member has version number
V, while the received new keying material has version number V' = V, while the received new keying material has version number V' =
(V + 1). In such a case, the group member simply installs the new (V + 1). In such a case, the group member simply installs the new
keying material and derives the corresponding new Security keying material and derives the corresponding new Security
Context. Context.
* The group member has missed one or more group rekeying instances. * The group member has missed one or more group rekeying instances.
That is, the old keying material stored by the group member has That is, the old keying material stored by the group member has
version number V, while the received new keying material has version number V, while the received new keying material has
version number V' > (V + 1). In such a case, the group member version number V' > (V + 1). In such a case, the group member
MUST proceed as defined in Section 20.3. MUST proceed as defined in Section 11.3.
* The group member has received keying material not newer than the * The group member has received keying material not newer than the
stored one. That is, the old keying material stored by the group stored one. That is, the old keying material stored by the group
member has version number V, while the received keying material member has version number V, while the received keying material
has version number V' < (V + 1). In such a case, the group member has version number V' < (V + 1). In such a case, the group member
MUST ignore the received rekeying messages and MUST NOT install MUST ignore the received rekeying messages and MUST NOT install
the received keying material. the received keying material.
20.3. Missed Rekeying Instances 11.3. Missed Rekeying Instances
A group member can realize to have missed one or more rekeying A group member can realize to have missed one or more rekeying
instances in one of the ways discussed below. In the following, V instances in one of the ways discussed below. In the following, V
denotes the version number of the old keying material stored by the denotes the version number of the old keying material stored by the
group member, while V' denotes the version number of the latest, group member, while V' denotes the version number of the latest,
possibly just distributed, keying material. possibly just distributed, keying material.
a. The group member has participated to a rekeying process that has a. The group member has participated to a rekeying process that has
distributed new keying material with version number V' > (V + 1), as distributed new keying material with version number V' > (V + 1), as
discussed in Section 20.2. discussed in Section 11.2.
b. The group member has obtained the latest keying material from the b. The group member has obtained the latest keying material from the
Group Manager, as a response to a Key Distribution Request (see Group Manager, as a response to a Key Distribution Request (see
Section 8.1) or to a Joining Request when re-joining the group (see Section 9.1.1) or to a Joining Request when re-joining the group (see
Section 6.2). In particular, V is different than V' specified by the Section 6.1). In particular, V is different than V' specified by the
'num' parameter in the response. 'num' parameter in the response.
c. The group member has obtained the authentication credentials of c. The group member has obtained the authentication credentials of
other group members, through a Public Key Request-Response exchange other group members, through a Public Key Request-Response exchange
with the Group Manager (see Section 10). In particular, V is with the Group Manager (see Section 9.3). In particular, V is
different than V' specified by the 'num' parameter in the response. different than V' specified by the 'num' parameter in the response.
d. The group member has performed a Version Request-Response d. The group member has performed a Version Request-Response
exchange with the Group Manager (see Section 15). In particular, V exchange with the Group Manager (see Section 9.8). In particular, V
is different than V' specified by the 'num' parameter in the is different than V' specified by the 'num' parameter in the
response. response.
In either case, the group member MUST delete the stored keying In either case, the group member MUST delete the stored keying
material with version number V. material with version number V.
If case (a) or case (b) applies, the group member MUST perform the If case (a) or case (b) applies, the group member MUST perform the
following actions. following actions.
1. The group member MUST NOT install the latest keying material yet, 1. The group member MUST NOT install the latest keying material yet,
in case that was already obtained. in case that was already obtained.
2. The group member sends a Stale Sender IDs Request to the Group 2. The group member sends a Stale Sender IDs Request to the Group
Manager (see Section 20.3.1), specifying the version number V as Manager (see Section 11.3.1), specifying the version number V as
payload of the request. payload of the request.
If the Stale Sender IDs Response from the Group Manager has no If the Stale Sender IDs Response from the Group Manager has no
payload, the group member MUST remove all the authentication payload, the group member MUST remove all the authentication
credentials from its list of group members' authentication credentials from its list of group members' authentication
credentials used in the group, and MUST delete all its Recipient credentials used in the group, and MUST delete all its Recipient
Contexts used in the group. Contexts used in the group.
Otherwise, the group member considers the stale Sender IDs Otherwise, the group member considers the stale Sender IDs
specified in the Stale Sender IDs Response from the Group specified in the Stale Sender IDs Response from the Group
skipping to change at page 61, line 20 skipping to change at page 62, line 33
MUST delete each of its Recipient Contexts used in the group MUST delete each of its Recipient Contexts used in the group
whose corresponding Recipient ID is a stale Sender ID. whose corresponding Recipient ID is a stale Sender ID.
3. The group member installs the latest keying material with version 3. The group member installs the latest keying material with version
number V' and derives the corresponding new Security Context. number V' and derives the corresponding new Security Context.
If case (c) or case (d) applies, the group member SHOULD perform the If case (c) or case (d) applies, the group member SHOULD perform the
following actions. following actions.
1. The group member sends a Stale Sender IDs Request to the Group 1. The group member sends a Stale Sender IDs Request to the Group
Manager (see Section 20.3.1), specifying the version number V as Manager (see Section 11.3.1), specifying the version number V as
payload of the request. payload of the request.
If the Stale Sender IDs Response from the Group Manager has no If the Stale Sender IDs Response from the Group Manager has no
payload, the group member MUST remove all the authentication payload, the group member MUST remove all the authentication
credentials from its list of group members' authentication credentials from its list of group members' authentication
credentials used in the group, and MUST delete all its Recipient credentials used in the group, and MUST delete all its Recipient
Contexts used in the group. Contexts used in the group.
Otherwise, the group member considers the stale Sender IDs Otherwise, the group member considers the stale Sender IDs
specified in the Stale Sender IDs Response from the Group specified in the Stale Sender IDs Response from the Group
Manager. Then, the group member MUST remove every authentication Manager. Then, the group member MUST remove every authentication
credential associated with a stale Sender ID from its list of credential associated with a stale Sender ID from its list of
group members' authentication credentials used in the group, and group members' authentication credentials used in the group, and
MUST delete each of its Recipient Contexts used in the group MUST delete each of its Recipient Contexts used in the group
whose corresponding Recipient ID is a stale Sender ID. whose corresponding Recipient ID is a stale Sender ID.
2. The group member obtains the latest keying material with version 2. The group member obtains the latest keying material with version
number V' from the Group Manager. This can happen by sending a number V' from the Group Manager. This can happen by sending a
Key Distribution Request to the Group Manager (see Section 8.1), Key Distribution Request to the Group Manager (see Section 9.1.1)
or by re-joining the group (see Section 6.2). and Section 9.1.2).
3. The group member installs the latest keying material with version 3. The group member installs the latest keying material with version
number V' and derives the corresponding new Security Context. number V' and derives the corresponding new Security Context.
If case (c) or case (d) applies, the group member can alternatively If case (c) or case (d) applies, the group member can alternatively
perform the following actions. perform the following actions.
1. The group member re-joins the group (see Section 6.2). When 1. The group member re-joins the group (see Section 6.1). When
doing so, the group member MUST re-join with the same roles it doing so, the group member MUST re-join with the same roles it
currently has in the group, and MUST request the Group Manager currently has in the group, and MUST request the Group Manager
for the authentication credentials of all the current group for the authentication credentials of all the current group
members. That is, the 'get_pub_keys' parameter of the Joining members. That is, the 'get_pub_keys' parameter of the Joining
Request MUST be present and MUST be set to the CBOR simple value Request MUST be present and MUST be set to the CBOR simple value
"null" (0xf6). "null" (0xf6).
2. When receiving the Joining Response (see Section 6.5 and 2. When receiving the Joining Response (see Section 6.4 and
Section 6.5), the group member retrieves the set Z of Section 6.4), the group member retrieves the set Z of
authentication credentials specified in the 'pub_keys' parameter. authentication credentials specified in the 'pub_keys' parameter.
Then, the group member MUST remove every authentication Then, the group member MUST remove every authentication
credential which is not in Z from its list of group members' credential which is not in Z from its list of group members'
authentication credentials used in the group, and MUST delete authentication credentials used in the group, and MUST delete
each of its Recipient Contexts used in the group that does not each of its Recipient Contexts used in the group that does not
include any of the authentication credentials in Z. include any of the authentication credentials in Z.
3. The group member installs the latest keying material with version 3. The group member installs the latest keying material with version
number V' and derives the corresponding new Security Context. number V' and derives the corresponding new Security Context.
20.3.1. Retrieval of Stale Sender IDs 11.3.1. Retrieve Stale Sender IDs
When realizing to have missed one or more group rekeying instances When realizing to have missed one or more group rekeying instances
(see Section 20.3), a node needs to retrieve from the Group Manager (see Section 11.3), a node needs to retrieve from the Group Manager
the data required to delete some of its stored group members' the data required to delete some of its stored group members'
authentication credentials and Recipient Contexts (see authentication credentials and Recipient Contexts (see
Section 5.3.1). This data is provided as an aggregated set of stale Section 8.3.1). These data are provided as an aggregated set of
Sender IDs, which are used as specified in Section 20.3. stale Sender IDs, which are used as specified in Section 11.3.
In particular, the node sends a CoAP FETCH request to the endpoint In particular, the node sends a CoAP FETCH request to the endpoint
/ace-group/GROUPNAME/stale-sids at the Group Manager defined in /ace-group/GROUPNAME/stale-sids at the Group Manager defined in
Section 5.3 of this document, where GROUPNAME is the name of the Section 8.3 of this document, where GROUPNAME is the name of the
OSCORE group. OSCORE group.
The payload of the Stale Sender IDs Request MUST include a CBOR The payload of the Stale Sender IDs Request MUST include a CBOR
unsigned integer. This encodes the version number V of the most unsigned integer. This encodes the version number V of the most
recent group keying material stored and installed by the requesting recent group keying material stored and installed by the requesting
client, which is older than the latest, possibly just distributed, Client, which is older than the latest, possibly just distributed,
keying material with version number V'. keying material with version number V'.
The handler MUST reply with a 4.00 (Bad Request) error response, if The handler MUST reply with a 4.00 (Bad Request) error response, if
the request is not formatted correctly. Also, the handler MUST the request is not formatted correctly. Also, the handler MUST
respond with a 4.00 (Bad Request) error response, if the specified respond with a 4.00 (Bad Request) error response, if the specified
version number V is greater or equal than the version number V' version number V is greater or equal than the version number V'
associated with the latest keying material in the group, i.e., if V associated with the latest keying material in the group, i.e., in
>= V'. case V >= V'.
Otherwise, the handler responds with a 2.05 (Content) Stale Sender Otherwise, the handler responds with a 2.05 (Content) Stale Sender
IDs Response. The payload of the response is formatted as defined IDs Response. The payload of the response is formatted as defined
below, where SKEW = (V' - V + 1). below, where SKEW = (V' - V + 1).
* The Group Manager considers ITEMS as the current number of sets * The Group Manager considers ITEMS as the current number of sets
stored in the collection of stale Sender IDs associated with the stored in the collection of stale Sender IDs associated with the
group (see Section 2.2.1). group (see Section 7.1).
* If SKEW > ITEMS, the Stale Sender IDs Response MUST NOT have a * If SKEW > ITEMS, the Stale Sender IDs Response MUST NOT have a
payload. payload.
* Otherwise, the payload of the Stale Sender IDs Response MUST * Otherwise, the payload of the Stale Sender IDs Response MUST
include a CBOR array, where each element is encoded as a CBOR byte include a CBOR array, where each element is encoded as a CBOR byte
string. The CBOR array has to be intended as a set, i.e., the string. The CBOR array has to be intended as a set, i.e., the
order of its elements is irrelevant. The Group Manager populates order of its elements is irrelevant. The Group Manager populates
the CBOR array as follows. the CBOR array as follows.
skipping to change at page 64, line 35 skipping to change at page 65, line 42
42 42
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Payload (in CBOR diagnostic notation): Payload (in CBOR diagnostic notation):
[h'01', h'fc', h'12ab', h'de44', h'ff'] [h'01', h'fc', h'12ab', h'de44', h'ff']
Figure 10: Example of Stale Sender IDs Request-Response Figure 10: Example of Stale Sender IDs Request-Response
21. ACE Groupcomm Parameters 12. ACE Groupcomm Parameters
Clients are required to support the new parameters defined in this In addition to those defined in Section 8 of
application profile as specified below (REQ29). [I-D.ietf-ace-key-groupcomm], this application profile defines
additional parameters used during the second part of the message
exchange with the Group Manager, i.e., after the exchange of Token
Transfer Request and Response (see Section 5.3). The table below
summarizes them and specifies the CBOR key to use instead of the full
descriptive name.
Note that the media type application/ace-groupcomm+cbor MUST be used
when these parameters are transported in the respective message
fields.
+----------------+------+-------+-----------------+
| Name | CBOR | CBOR | Reference |
| | Key | Type | |
+----------------+------+-------+-----------------+
| group_senderId | TBD | bstr | [this document] |
+----------------+------+-------+-----------------+
| ecdh_info | TBD | array | [this document] |
+----------------+------+-------+-----------------+
| kdc_dh_creds | TBD | array | [this document] |
+----------------+------+-------+-----------------+
| group_enc_key | TBD | bstr | [this document] |
+----------------+------+-------+-----------------+
| stale_node_ids | TBD | array | [this document] |
+----------------+------+-------+-----------------+
Figure 11: ACE Groupcomm Parameters
The Group Manager is expected to support and understand all the
parameters above. Instead, a Client is required to support the new
parameters defined in this application profile as specified below
(REQ29).
* 'group_senderId' MUST be supported by a Client that intends to * 'group_senderId' MUST be supported by a Client that intends to
join an OSCORE group with the role of Requester and/or Responder. join an OSCORE group with the role of Requester and/or Responder.
* 'ecdh_info' MUST be supported by a Client that intends to join a * 'ecdh_info' MUST be supported by a Client that intends to join a
group which uses the pairwise mode of Group OSCORE. group which uses the pairwise mode of Group OSCORE.
* 'kdc_dh_creds' MUST be supported by a Client that intends to join * 'kdc_dh_creds' MUST be supported by a Client that intends to join
a group which uses the pairwise mode of Group OSCORE and that does a group which uses the pairwise mode of Group OSCORE and that does
not plan to or cannot rely on an early retrieval of the Group not plan to or cannot rely on an early retrieval of the Group
Manager's Diffie-Hellman authentication credential. Manager's Diffie-Hellman authentication credential.
* 'group_enc_key' MUST be supported by a Client that intends to join * 'group_enc_key' MUST be supported by a Client that intends to join
a group which uses the group mode of Group OSCORE or to be a group which uses the group mode of Group OSCORE or to be
signature verifier for that group. signature verifier for that group.
* 'stale_node_ids' MUST be supported. * 'stale_node_ids' MUST be supported.
When the conditional parameters defined in Section 8 of When the conditional parameters defined in Section 8 of
[I-D.ietf-ace-key-groupcomm] are used with this application profile, [I-D.ietf-ace-key-groupcomm] are used with this application profile,
Clients must, should or may support them as specified below (REQ30). a Client must, should or may support them as specified below (REQ30).
* 'client_cred', 'cnonce', 'client_cred_verify'. A Client that has * 'client_cred', 'cnonce', 'client_cred_verify'. A Client that has
an own authentication credential to use in a group MUST support an own authentication credential to use in a group MUST support
these parameters. these parameters.
* 'kdcchallenge'. A Client that has an own authentication * 'kdcchallenge'. A Client that has an own authentication
credential to use in a group and that provides the Access Token to credential to use in a group and that provides the Access Token to
the Group Manager through a Token Transfer Request (see the Group Manager through a Token Transfer Request (see
Section 6.1) MUST support this parameter. Section 5.3) MUST support this parameter.
* 'pub_keys_repo'. This parameter is not relevant for this * 'pub_keys_repo'. This parameter is not relevant for this
application profile, since the Group Manager always acts as application profile, since the Group Manager always acts as
repository of the group members' authentication credentials. repository of the group members' authentication credentials.
* 'group_policies'. A Client that is interested in the specific * 'group_policies'. A Client that is interested in the specific
policies used in a group, but that does not know them or cannot policies used in a group, but that does not know them or cannot
become aware of them before joining that group SHOULD support this become aware of them before joining that group, SHOULD support
parameter. this parameter.
* 'peer_roles'. A Client MUST support this parameter, since in this * 'peer_roles'. A Client MUST support this parameter, since in this
application profile it is relevant for Clients to know the roles application profile it is relevant for Clients to know the roles
of the group member associated with each authentication of the group member associated with each authentication
credential. credential.
* 'kdc_nonce', 'kdc_cred' and 'kdc_cred_verify'. A Client MUST * 'kdc_nonce', 'kdc_cred' and 'kdc_cred_verify'. A Client MUST
support these parameters, since the Group Manager's authentication support these parameters, since the Group Manager's authentication
credential is required to process messages protected with Group credential is required to process messages protected with Group
OSCORE (see Section 4.3 of [I-D.ietf-core-oscore-groupcomm]). OSCORE (see Section 4.3 of [I-D.ietf-core-oscore-groupcomm]).
* 'mgt_key_material'. A Client that supports an advanced rekeying * 'mgt_key_material'. A Client that supports an advanced rekeying
scheme possibly used in the group, such as based on one-to-many scheme possibly used in the group, such as based on one-to-many
rekeying messages sent over IP multicast, MUST support this rekeying messages sent by the Group Manager (e.g., over IP
parameter. multicast), MUST support this parameter.
* 'control_group_uri'. A Client that support the hosting of local * 'control_group_uri'. A Client that supports the hosting of local
resources each associated with a group (hence acting as CoAP resources each associated with a group (hence acting as CoAP
server) and the reception of one-to-many requests sent to those server) and the reception of one-to-many requests sent to those
resources by the Group Manager (e.g., over IP multicast) MUST resources by the Group Manager (e.g., over IP multicast) MUST
support this parameter. support this parameter.
22. ACE Groupcomm Error Identifiers 13. ACE Groupcomm Error Identifiers
In addition to what is defined in Section 9 of In addition to those defined in Section 9 of
[I-D.ietf-ace-key-groupcomm], this application profile defines new [I-D.ietf-ace-key-groupcomm], this application profile defines new
values that the Group Manager can include as error identifiers, in values that the Group Manager can include as error identifiers, in
the 'error' field of an error response with Content-Format the 'error' field of an error response with Content-Format
application/ace-groupcomm+cbor. application/ace-groupcomm+cbor.
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
| Value | Description | | Value | Description |
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
| 7 | Signatures not used in the group | | 7 | Signatures not used in the group |
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
| 8 | Operation permitted only to signature verifiers | | 8 | Operation permitted only to signature verifiers |
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
| 9 | Group currently not active | | 9 | Group currently not active |
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
Figure 11: ACE Groupcomm Error Identifiers Figure 12: ACE Groupcomm Error Identifiers
A Client supporting the 'error' parameter (see Sections 4.1.2 and 8 A Client supporting the 'error' parameter (see Sections 4.1.2 and 8
of [I-D.ietf-ace-key-groupcomm]) and able to understand the specified of [I-D.ietf-ace-key-groupcomm]) and able to understand the specified
error may use that information to determine what actions to take error may use that information to determine what actions to take
next. If it is included in the error response and supported by the next. If it is included in the error response and supported by the
Client, the 'error_description' parameter may provide additional Client, the 'error_description' parameter may provide additional
context. In particular, the following guidelines apply. context. In particular, the following guidelines apply.
* In case of error 7, the Client should stop sending the request in * In case of error 7, the Client should stop sending the request in
question to the Group Manager. In this application profile, this question to the Group Manager. In this application profile, this
error is relevant only for a signature verifiers, in case it tries error is relevant only for a signature verifier, in case it tries
to access resources related to a pairwise-only group. to access resources related to a pairwise-only group.
* In case of error 8, the Client should stop sending the request in * In case of error 8, the Client should stop sending the request in
question to the Group Manager. question to the Group Manager.
* In case of error 9, the Client should wait for a certain (pre- * In case of error 9, the Client should wait for a certain (pre-
configured) amount of time, before trying re-sending its request configured) amount of time, before trying re-sending its request
to the Group Manager. to the Group Manager.
23. Default Values for Group Configuration Parameters 14. Default Values for Group Configuration Parameters
This section defines the default values that the Group Manager This section defines the default values that the Group Manager
assumes for the configuration parameters of an OSCORE group, unless assumes for the configuration parameters of an OSCORE group, unless
differently specified when creating and configuring the group. This differently specified when creating and configuring the group. This
can be achieved as specified in [I-D.ietf-ace-oscore-gm-admin]. can be achieved as specified in [I-D.ietf-ace-oscore-gm-admin].
23.1. Common 14.1. Common
This section always applies, as related to common configuration This section always applies, as related to common configuration
parameters. parameters.
* For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use the * For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use HKDF
same default value defined in Section 3.2 of [RFC8613], i.e., HKDF SHA-256, defined as default in Section 3.2 of [RFC8613]. In the
SHA-256 (COSE algorithm encoding: -10). 'hkdf' parameter, this HKDF Algorithm is specified by the HMAC
Algorithm HMAC 256/256 (COSE algorithm encoding: 5).
* For the format 'cred_fmt' used for the authentication credentials * For the format 'cred_fmt' used for the authentication credentials
in the group, the Group Manager SHOULD use CBOR Web Token (CWT) or in the group, the Group Manager SHOULD use CBOR Web Token (CWT) or
CWT Claims Set (CCS) [RFC8392], i.e., the COSE Header Parameter CWT Claims Set (CCS) [RFC8392], i.e., the COSE Header Parameter
'kcwt' and 'kccs', respectively. 'kcwt' and 'kccs', respectively.
[ These COSE Header Parameters are under pending registration [ These COSE Header Parameters are under pending registration
requested by draft-ietf-lake-edhoc. ] requested by draft-ietf-lake-edhoc. ]
* For 'max_stale_sets', the Group Manager SHOULD consider N = 3 as * For 'max_stale_sets', the Group Manager SHOULD consider N = 3 as
the maximum number of stored sets of stale Sender IDs in the the maximum number of stored sets of stale Sender IDs in the
collection associated with the group (see Section 2.2.1). collection associated with the group (see Section 7.1).
23.2. Group Mode 14.2. Group Mode
This section applies if the group uses (also) the group mode of Group This section applies if the group uses (also) the group mode of Group
OSCORE. OSCORE.
* For the Signature Encryption Algorithm 'sign_enc_alg' used to * For the Signature Encryption Algorithm 'sign_enc_alg' used to
encrypted messages protected with the group mode, the Group encrypt messages protected with the group mode, the Group Manager
Manager SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10) SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10) as
as default value. default value.
The Group Manager SHOULD use the following default values for the The Group Manager SHOULD use the following default values for the
Signature Algorithm 'sign_alg' and related parameters 'sign_params', Signature Algorithm 'sign_alg' and related parameters 'sign_params',
consistently with the "COSE Algorithms" registry [COSE.Algorithms], consistently with the "COSE Algorithms" registry [COSE.Algorithms],
the "COSE Key Types" registry [COSE.Key.Types] and the "COSE Elliptic the "COSE Key Types" registry [COSE.Key.Types] and the "COSE Elliptic
Curves" registry [COSE.Elliptic.Curves]. Curves" registry [COSE.Elliptic.Curves].
* For the Signature Algorithm 'sign_alg' used to sign messages * For the Signature Algorithm 'sign_alg' used to sign messages
protected with the group mode, the signature algorithm EdDSA protected with the group mode, the signature algorithm EdDSA
[RFC8032]. [RFC8032].
skipping to change at page 68, line 21 skipping to change at page 70, line 13
the COSE key type EC2 and the elliptic curve P-384. the COSE key type EC2 and the elliptic curve P-384.
- The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is - The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is
specified for 'sign_alg'. In particular, this indicates to use specified for 'sign_alg'. In particular, this indicates to use
the COSE key type EC2 and the elliptic curve P-521. the COSE key type EC2 and the elliptic curve P-521.
- The array [[RSA], [RSA]], in case PS256, PS384 or PS512 - The array [[RSA], [RSA]], in case PS256, PS384 or PS512
[RFC8017] is specified for 'sign_alg'. In particular, this [RFC8017] is specified for 'sign_alg'. In particular, this
indicates to use the COSE key type RSA. indicates to use the COSE key type RSA.
23.3. Pairwise Mode 14.3. Pairwise Mode
This section applies if the group uses (also) the pairwise mode of This section applies if the group uses (also) the pairwise mode of
Group OSCORE. Group OSCORE.
For the AEAD Algorithm 'alg' used to encrypt messages protected with For the AEAD Algorithm 'alg' used to encrypt messages protected with
the pairwise mode, the Group Manager SHOULD use the same default the pairwise mode, the Group Manager SHOULD use the same default
value defined in Section 3.2 of [RFC8613], i.e., AES-CCM-16-64-128 value defined in Section 3.2 of [RFC8613], i.e., AES-CCM-16-64-128
(COSE algorithm encoding: 10). (COSE algorithm encoding: 10).
For the Pairwise Key Agreement Algorithm 'ecdh_alg' and related For the Pairwise Key Agreement Algorithm 'ecdh_alg' and related
skipping to change at page 68, line 46 skipping to change at page 70, line 38
* For the Pairwise Key Agreement Algorithm 'ecdh_alg' used to * For the Pairwise Key Agreement Algorithm 'ecdh_alg' used to
compute static-static Diffie-Hellman shared secrets, the ECDH compute static-static Diffie-Hellman shared secrets, the ECDH
algorithm ECDH-SS + HKDF-256 specified in Section 6.3.1 of algorithm ECDH-SS + HKDF-256 specified in Section 6.3.1 of
[I-D.ietf-cose-rfc8152bis-algs]. [I-D.ietf-cose-rfc8152bis-algs].
* For the parameters 'ecdh_params' of the Pairwise Key Agreement * For the parameters 'ecdh_params' of the Pairwise Key Agreement
Algorithm: Algorithm:
- The array [[OKP], [OKP, X25519]], in case EdDSA is assumed or - The array [[OKP], [OKP, X25519]], in case EdDSA is assumed or
specified for 'sign_alg'. In particular, this indicates to use specified for 'sign_alg', or in case the group is a pairwise-
the COSE key type OKP and the elliptic curve X25519 [RFC8032]. only group. In particular, this indicates to use the COSE key
type OKP and the elliptic curve X25519 [RFC8032].
- The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is - The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is
specified for 'sign_alg'. In particular, this indicates to use specified for 'sign_alg'. In particular, this indicates to use
the COSE key type EC2 and the elliptic curve P-256. the COSE key type EC2 and the elliptic curve P-256.
- The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is - The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is
specified for 'sign_alg'. In particular, this indicates to use specified for 'sign_alg'. In particular, this indicates to use
the COSE key type EC2 and the elliptic curve P-384. the COSE key type EC2 and the elliptic curve P-384.
- The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is - The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is
specified for 'sign_alg'. In particular, this indicates to use specified for 'sign_alg'. In particular, this indicates to use
the COSE key type EC2 and the elliptic curve P-521. the COSE key type EC2 and the elliptic curve P-521.
24. Security Considerations 15. Security Considerations
Security considerations for this profile are inherited from Security considerations for this profile are inherited from
[I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication
and Authorization [I-D.ietf-ace-oauth-authz], and the specific and Authorization [I-D.ietf-ace-oauth-authz], and the specific
transport profile of ACE signalled by the AS, such as transport profile of ACE signalled by the AS, such as
[I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile].
The following security considerations also apply for this profile. The following security considerations also apply for this profile.
24.1. Management of OSCORE Groups 15.1. Management of OSCORE Groups
This profile leverages the following management aspects related to This profile leverages the following management aspects related to
OSCORE groups and discussed in the sections of OSCORE groups and discussed in the sections of
[I-D.ietf-core-oscore-groupcomm] referred below. [I-D.ietf-core-oscore-groupcomm] referred below.
* Management of group keying material (see Section 3.2 of * Management of group keying material (see Section 3.2 of
[I-D.ietf-core-oscore-groupcomm]). The Group Manager is [I-D.ietf-core-oscore-groupcomm]). The Group Manager is
responsible for the renewal and re-distribution of the keying responsible for the renewal and re-distribution of the keying
material in the groups of its competence (rekeying). According to material in the groups of its competence (rekeying).
the specific application requirements, this can include rekeying
the group upon changes in its membership. In particular, renewing The Group Manager performs a rekeying when one ore more members
the group keying material is required upon a new node's joining or leave the group, thus preserving forward security and ensuring
a current node's leaving, in case backward security and forward that the security properties of Group OSCORE are fulfilled.
security have to be preserved, respectively. According to the specific application requirements, the Group
Manager can also rekey the group upon a new node's joining, in
case backward security has also to be preserved.
* Provisioning and retrieval of authentication credentials (see * Provisioning and retrieval of authentication credentials (see
Section 3 of [I-D.ietf-core-oscore-groupcomm]). The Group Manager Section 3 of [I-D.ietf-core-oscore-groupcomm]). The Group Manager
acts as repository of authentication credentials of group members, acts as repository of authentication credentials of group members,
and provides them upon request. and provides them upon request.
* Synchronization of sequence numbers (see Section 6.3 of * Synchronization of sequence numbers (see Section 6.3 of
[I-D.ietf-core-oscore-groupcomm]). This concerns how a responder [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder
node that has just joined an OSCORE group can synchronize with the node that has just joined an OSCORE group can synchronize with the
sequence number of requesters in the same group. sequence number of requesters in the same group.
Before sending the Joining Response, the Group Manager MUST verify Before sending the Joining Response, the Group Manager MUST verify
that the joining node actually owns the associated private key. To that the joining node actually owns the associated private key. To
this end, the Group Manager can rely on the proof-of-possession this end, the Group Manager can rely on the proof-of-possession
challenge-response defined in Section 6. challenge-response defined in Section 6.
Alternatively, when establishing a secure communication association Alternatively, when establishing a secure communication association
with the Group Manager, the joining node can provide the Group with the Group Manager, the joining node can provide the Group
Manager with its own authentication credential, and use the public Manager with its own authentication credential, and use the public
key included thereof as asymmetric proof-of-possession key, e.g., as key included thereof as asymmetric proof-of-possession key. For
in Section 3.2.2 of [I-D.ietf-ace-dtls-authorize] in case the joining example, this is the case when the joining node relies on
node authenticates itself during the DTLS handshake with the the Section 3.2.2 of [I-D.ietf-ace-dtls-authorize] and authenticates
Group Manager. However, this requires the authentication credential itself during the DTLS handshake with the Group Manager. However,
to be in the format used in the OSCORE group, and that both the this requires the authentication credential to be in the format used
authentication credential and the included public key are compatible in the OSCORE group, and that both the authentication credential of
with the signature or ECDH algorithm, and possible associated the joining node and the included public key are compatible with the
parameters used in the OSCORE group. signature or ECDH algorithm, and possible associated parameters used
in the OSCORE group.
A node may have joined multiple OSCORE groups under different non- A node may have joined multiple OSCORE groups under different non-
synchronized Group Managers. Therefore, it can happen that those synchronized Group Managers. Therefore, it can happen that those
OSCORE groups have the same Group Identifier (Gid). It follows that, OSCORE groups have the same Group Identifier (Gid). It follows that,
upon receiving a Group OSCORE message addressed to one of those upon receiving a Group OSCORE message addressed to one of those
groups, the node would have multiple Security Contexts matching with groups, the node would have multiple Security Contexts matching with
the Gid in the incoming message. It is up to the application to the Gid in the incoming message. It is up to the application to
decide how to handle such collisions of Group Identifiers, e.g., by 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.
24.2. Size of Nonces as Proof-of-Possesion Challenge 15.2. Size of Nonces as Proof-of-Possesion Challenge
With reference to the Joining Request message in Section 6.2, the With reference to the Joining Request message in Section 6.1, the
proof-of-possession (PoP) evidence included in 'client_cred_verify' proof-of-possession (PoP) evidence included in 'client_cred_verify'
is computed over an input including also N_C | N_S, where | denotes is computed over an input including also N_C | N_S, where | denotes
concatenation. concatenation.
For the N_C challenge, it is RECOMMENDED to use a 8-byte long random For the N_C challenge, it is RECOMMENDED to use a 8-byte long random
nonce. Furthermore, N_C is always conveyed in the 'cnonce' parameter nonce. Furthermore, N_C is always conveyed in the 'cnonce' parameter
of the Joining Request, which is always sent over the secure of the Joining Request, which is always sent over the secure
communication channel between the joining node and the Group Manager. communication association between the joining node and the Group
Manager.
As defined in Section 6.2.1, the way the N_S value is computed As defined in Section 6.1.1, the way the N_S value is computed
depends on the particular way the joining node provides the Group depends on the particular way the joining node provides the Group
Manager with the Access Token, as well as on following interactions Manager with the Access Token, as well as on following interactions
between the two. between the two.
* If the Access Token has not been provided to the Group Manager by * If the Access Token has not been provided to the Group Manager by
means of a Token Transfer Request to the /authz-info endpoint as means of a Token Transfer Request to the /authz-info endpoint as
in Section 6.1, then N_S is computed as a 32-byte long challenge. in Section 5.3, then N_S is computed as a 32-byte long challenge.
For an example, see point (2) of Section 6.2.1. For an example, see point (2) of Section 6.1.1.
* If the Access Token has been provided to the Group Manager by * If the Access Token has been provided to the Group Manager by
means of a Token Transfer Request to the /authz-info endpoint as means of a Token Transfer Request to the /authz-info endpoint as
in Section 6.1, then N_S takes the most recent value provided to in Section 5.3, then N_S takes the most recent value provided to
the client by the Group Manager in the 'kdcchallenge' parameter, the Client by the Group Manager in the 'kdcchallenge' parameter,
as specified in point (1) of Section 6.2.1. This is provided as specified in point (1) of Section 6.1.1. This value is
either in the Token Transfer Response (see Section 6.1), or in a provided either in the Token Transfer Response (see Section 5.3),
4.00 (Bad Request) error response to a following Joining Request or in a 4.00 (Bad Request) error response to a following Joining
(see Section 6.3). In either case, it is RECOMMENDED to use a Request (see Section 6.2). In either case, it is RECOMMENDED to
8-byte long random challenge as value for N_S. use a 8-byte long random challenge as value for N_S.
If we consider both N_C and N_S to take 8-byte long values, the If we consider both N_C and N_S to take 8-byte long values, the
following considerations hold. following considerations hold.
* Let us consider both N_C and N_S as taking random values, and the * Let us consider both N_C and N_S as taking random values, and the
Group Manager to never change the value of the N_S provided to a Group Manager to never change the value of the N_S provided to a
Client during the lifetime of an Access Token. Then, as per the Client during the lifetime of an Access Token. Then, as per the
birthday paradox, the average collision for N_S will happen after birthday paradox, the average collision for N_S will happen after
2^32 new transferred Access Tokens, while the average collision 2^32 new transferred Access Tokens, while the average collision
for N_C will happen after 2^32 new Joining Requests. This amounts for N_C will happen after 2^32 new Joining Requests. This amounts
skipping to change at page 71, line 31 skipping to change at page 73, line 36
to considerably more requests to join OSCORE groups from a same to considerably more requests to join OSCORE groups from a same
Client using a same Access Token under a same Group Manager. Client using a same Access Token under a same Group Manager.
* Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of * Section 7 of [I-D.ietf-ace-oscore-profile] as well Appendix B.2 of
[RFC8613] recommend the use of 8-byte random values as well. [RFC8613] recommend the use of 8-byte random values as well.
Unlike in those cases, the values of N_C and N_S considered in Unlike in those cases, the values of N_C and N_S considered in
this document are not used for as sensitive operations as the this document are not used for as sensitive operations as the
derivation of a Security Context, and thus do not have possible derivation of a Security Context, and thus do not have possible
implications in the security of AEAD ciphers. implications in the security of AEAD ciphers.
24.3. Reusage of Nonces for Proof-of-Possession Input 15.3. Reusage of Nonces for Proof-of-Possession Input
As long as the Group Manager preserves the same N_S value currently As long as the Group Manager preserves the same N_S value currently
associated with an Access Token, i.e., the latest value provided to a associated with an Access Token, i.e., the latest value provided to a
Client in a 'kdcchallenge' parameter, the Client is able to Client in a 'kdcchallenge' parameter, the Client is able to
successfully reuse the same proof-of-possession (PoP) input for successfully reuse the same proof-of-possession (PoP) input for
multiple Joining Requests to that Group Manager. multiple Joining Requests to that Group Manager.
In particular, the Client can reuse the same N_C value for every 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 Joining Request to the Group Manager, and combine it with the same
unchanged N_S value. This results in reusing the same PoP input for unchanged N_S value. This results in reusing the same PoP input for
producing the PoP evidence to include in the 'client_cred_verify' producing the PoP evidence to include in the 'client_cred_verify'
parameter of the Joining Requests. parameter of the Joining Requests.
Unless the Group Manager maintains a list of N_C values already used 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 by that Client since the latest update to the N_S value associated
with the Access Token, the Group Manager can be forced to falsely with the Access Token, the Group Manager can be forced to falsely
believe that the Client possesses its own private key at that point believe that the Client possesses its own private key at that point
in time, upon verifying the PoP evidence in the 'client_cred_verify' in time, upon verifying the PoP evidence in the 'client_cred_verify'
parameter. parameter.
25. IANA Considerations 16. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "[[This Note to RFC Editor: Please replace all occurrences of "[[This
document]]" with the RFC number of this specification and delete this document]]" with the RFC number of this specification and delete this
paragraph. paragraph.
This document has the following actions for IANA. This document has the following actions for IANA.
25.1. OAuth Parameters 16.1. OAuth Parameters
IANA is asked to register the following entries to the "OAuth IANA is asked to register the following entries to the "OAuth
Parameters" registry, as per the procedure specified in Section 11.2 Parameters" registry, as per the procedure specified in Section 11.2
of [RFC6749]. of [RFC6749].
* Parameter name: ecdh_info * Parameter name: ecdh_info
* Parameter usage location: client-rs request, rs-client response * Parameter usage location: client-rs request, rs-client response
* Change Controller: IESG * Change Controller: IESG
* Specification Document(s): [[This specification]] * Specification Document(s): [[This document]]
* Parameter name: kdc_dh_creds * Parameter name: kdc_dh_creds
* Parameter usage location: client-rs request, rs-client response * Parameter usage location: client-rs request, rs-client response
* Change Controller: IESG * Change Controller: IESG
* Specification Document(s): [[This specification]] * Specification Document(s): [[This document]]
25.2. OAuth Parameters CBOR Mappings 16.2. OAuth Parameters CBOR Mappings
IANA is asked to register the following entries to the "OAuth IANA is asked to register the following entries to the "OAuth
Parameters CBOR Mappings" registry, as per the procedure specified in Parameters CBOR Mappings" registry, as per the procedure specified in
Section 8.10 of [I-D.ietf-ace-oauth-authz]. Section 8.10 of [I-D.ietf-ace-oauth-authz].
* Name: ecdh_info * Name: ecdh_info
* CBOR Key: TBD (range -256 to 255) * CBOR Key: TBD (range -256 to 255)
* Value Type: Simple value "null" / array * Value Type: Simple value "null" / Array
* Reference: [[This specification]]
* Reference: [[This document]]
* Name: kdc_dh_creds * Name: kdc_dh_creds
* CBOR Key: TBD (range -256 to 255) * CBOR Key: TBD (range -256 to 255)
* Value Type: Simple value "null" / array * Value Type: Simple value "null" / Array
* Reference: [[This specification]] * Reference: [[This document]]
25.3. ACE Groupcomm Parameters 16.3. ACE Groupcomm Parameters
IANA is asked to register the following entry to the "ACE Groupcomm IANA is asked to register the following entry to the "ACE Groupcomm
Parameters" registry defined in Section 11.7 of Parameters" registry defined in Section 11.7 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
* Name: group_senderId * Name: group_senderId
* CBOR Key: TBD * CBOR Key: TBD
* CBOR Type: Byte string * CBOR Type: Byte string
* Reference: [[This document]] (Section 9) * Reference: [[This document]] (Section 9.2)
* Name: ecdh_info * Name: ecdh_info
* CBOR Key: TBD * CBOR Key: TBD
* CBOR Type: Array * CBOR Type: Array
* Reference: [[This document]] (Section 6.3) * Reference: [[This document]] (Section 6.2)
* Name: kdc_dh_creds * Name: kdc_dh_creds
* CBOR Key: TBD * CBOR Key: TBD
* CBOR Type: Array * CBOR Type: Array
* Reference: [[This document]] (Section 6.3) * Reference: [[This document]] (Section 6.2)
* Name: group_enc_key * Name: group_enc_key
* CBOR Key: TBD * CBOR Key: TBD
* CBOR Type: Byte String * CBOR Type: Byte string
* Reference: [[This document]] (Section 5.2.1) * Reference: [[This document]] (Section 8.2.1)
* Name: stale_node_ids * Name: stale_node_ids
* CBOR Key: TBD * CBOR Key: TBD
* CBOR Type: Array * CBOR Type: Array
* Reference: [[This document]] (Section 20) * Reference: [[This document]] (Section 11)
25.4. ACE Groupcomm Key Types 16.4. ACE Groupcomm Key Types
IANA is asked to register the following entry to the "ACE Groupcomm IANA is asked to register the following entry to the "ACE Groupcomm
Key Types" registry defined in Section 11.8 of Key Types" registry defined in Section 11.8 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
* Name: Group_OSCORE_Input_Material object * Name: Group_OSCORE_Input_Material object
* Key Type Value: GROUPCOMM_KEY_TBD * Key Type Value: GROUPCOMM_KEY_TBD
* Profile: "coap_group_oscore_app", defined in Section 25.5 of this * Profile: "coap_group_oscore_app", defined in Section 16.5 of this
document. document.
* Description: A Group_OSCORE_Input_Material object encoded as * Description: A Group_OSCORE_Input_Material object encoded as
described in Section 6.4 of this document. described in Section 6.3 of this document.
* Reference: [[This document]] (Section 6.4) * Reference: [[This document]] (Section 6.3)
25.5. ACE Groupcomm Profiles 16.5. ACE Groupcomm Profiles
IANA is asked to register the following entry to the "ACE Groupcomm IANA is asked to register the following entry to the "ACE Groupcomm
Profiles" registry defined in Section 11.9 of Profiles" registry defined in Section 11.9 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
* Name: coap_group_oscore_app * Name: coap_group_oscore_app
* Description: Application profile to provision keying material for * Description: Application profile to provision keying material for
participating in group communication protected with Group OSCORE participating in group communication protected with Group OSCORE
as per [I-D.ietf-core-oscore-groupcomm]. as per [I-D.ietf-core-oscore-groupcomm].
* CBOR Value: PROFILE_TBD * CBOR Value: PROFILE_TBD
* Reference: [[This document]] (Section 6.4) * Reference: [[This document]] (Section 6.3)
25.6. OSCORE Security Context Parameters 16.6. OSCORE Security Context Parameters
IANA is asked to register the following entries in the "OSCORE IANA is asked to register the following entries in the "OSCORE
Security Context Parameters" registry defined in Section 9.4 of Security Context Parameters" registry defined in Section 9.4 of
[I-D.ietf-ace-oscore-profile]. [I-D.ietf-ace-oscore-profile].
* Name: group_SenderId * Name: group_SenderId
* CBOR Label: TBD * CBOR Label: TBD
* CBOR Type: bstr * CBOR Type: Byte string
* Registry: - * Registry: -
* Description: OSCORE Sender ID assigned to a member of an OSCORE * Description: OSCORE Sender ID assigned to a member of an OSCORE
group group
* Reference: [[This document]] (Section 6.4) * Reference: [[This document]] (Section 6.3)
* Name: cred_fmt * Name: cred_fmt
* CBOR Label: TBD * CBOR Label: TBD
* CBOR Type: integer * CBOR Type: Integer
* Registry: COSE Header Parameters * Registry: COSE Header Parameters
* Description: Format of authentication credentials to be used in * Description: Format of authentication credentials to be used in
the OSCORE group the OSCORE group
* Reference: [[This document]] (Section 6.4) * Reference: [[This document]] (Section 6.3)
* Name: sign_enc_alg * Name: sign_enc_alg
* CBOR Label: TBD * CBOR Label: TBD
* CBOR Type: tstr / int * CBOR Type: Text string / Integer
* Registry: COSE Algorithms * Registry: COSE Algorithms
* Description: OSCORE Signature Encryption Algorithm Value * Description: OSCORE Signature Encryption Algorithm Value
* Reference: [[This document]] (Section 6.4) * Reference: [[This document]] (Section 6.3)
* Name: sign_alg * Name: sign_alg
* CBOR Label: TBD * CBOR Label: TBD
* CBOR Type: tstr / int * CBOR Type: Text string / Integer
* Registry: COSE Algorithms * Registry: COSE Algorithms
* Description: OSCORE Signature Algorithm Value * Description: OSCORE Signature Algorithm Value
* Reference: [[This document]] (Section 6.4) * Reference: [[This document]] (Section 6.3)
* Name: sign_params * Name: sign_params
* CBOR Label: TBD * CBOR Label: TBD
* CBOR Type: array * CBOR Type: Array
* Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves * Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves
* Description: OSCORE Signature Algorithm Parameters * Description: OSCORE Signature Algorithm Parameters
* Reference: [[This document]] (Section 6.4) * Reference: [[This document]] (Section 6.3)
* Name: ecdh_alg * Name: ecdh_alg
* CBOR Label: TBD * CBOR Label: TBD
* CBOR Type: tstr / int * CBOR Type: Text string / Integer
* Registry: COSE Algorithms * Registry: COSE Algorithms
* Description: OSCORE Pairwise Key Agreement Algorithm Value * Description: OSCORE Pairwise Key Agreement Algorithm Value
* Reference: [[This document]] (Section 6.4) * Reference: [[This document]] (Section 6.3)
* Name: ecdh_params * Name: ecdh_params
* CBOR Label: TBD * CBOR Label: TBD
* CBOR Type: array * CBOR Type: Array
* Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves * Registry: COSE Algorithms, COSE Key Types, COSE Elliptic Curves
* Description: OSCORE Pairwise Key Agreement Algorithm Parameters * Description: OSCORE Pairwise Key Agreement Algorithm Parameters
* Reference: [[This document]] (Section 6.4) * Reference: [[This document]] (Section 6.3)
25.7. TLS Exporter Labels 16.7. TLS Exporter Labels
IANA is asked to register the following entry to the "TLS Exporter IANA is asked to register the following entry to the "TLS Exporter
Labels" registry defined in Section 6 of [RFC5705] and updated in Labels" registry defined in Section 6 of [RFC5705] and updated in
Section 12 of [RFC8447]. Section 12 of [RFC8447].
* Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app * Value: EXPORTER-ACE-Sign-Challenge-coap-group-oscore-app
* DTLS-OK: Y * DTLS-OK: Y
* Recommended: N * Recommended: N
* Reference: [[This document]] (Section 6.2.1) * Reference: [[This document]] (Section 6.1.1)
25.8. AIF 16.8. AIF
For the media-types application/aif+cbor and application/aif+json For the media-types application/aif+cbor and application/aif+json
defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to
register the following entries for the two media-type parameters Toid register the following entries for the two media-type parameters Toid
and Tperm, in the respective sub-registry defined in Section 5.2 of and Tperm, in the respective sub-registry defined in Section 5.2 of
[I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter" [I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter"
registry group. registry group.
* Name: oscore-group-name * Name: oscore-gname
* Description/Specification: group name of an OSCORE group * Description/Specification: OSCORE group name
* Reference: [[This document]] * Reference: [[This document]]
* Name: oscore-group-roles * Name: oscore-gperm
* Description/Specification: role(s) in the OSCORE group * Description/Specification: permissions pertaining OSCORE groups
* Reference: [[This document]] * Reference: [[This document]]
25.9. CoAP Content-Format 16.9. CoAP Content-Format
IANA is asked to register the following entries to the "CoAP Content- IANA is asked to register the following entries to the "CoAP Content-
Formats" registry within the "Constrained RESTful Environments (CoRE) Formats" registry within the "Constrained RESTful Environments (CoRE)
Parameters" registry group. Parameters" registry group.
* Media Type: application/aif+cbor;Toid="oscore-group- * Media Type: application/aif+cbor;Toid="oscore-
name",Tperm="oscore-group-roles" gname",Tperm="oscore-gperm"
* Encoding: - * Encoding: -
* ID: TBD * ID: TBD
* Reference: [[This document]] * Reference: [[This document]]
* Media Type: application/aif+json;Toid="oscore-group- * Media Type: application/aif+json;Toid="oscore-
name",Tperm="oscore-group-roles" gname",Tperm="oscore-gperm"
* Encoding: - * Encoding: -
* ID: TBD * ID: TBD
* Reference: [[This document]] * Reference: [[This document]]
25.10. Group OSCORE Roles 16.10. Group OSCORE Roles
This document establishes the IANA "Group OSCORE Roles" registry. This document establishes the IANA "Group OSCORE Roles" registry.
The registry has been created to use the "Expert Review" registration The registry has been created to use the "Expert Review" registration
procedure [RFC8126]. Expert review guidelines are provided in procedure [RFC8126]. Expert review guidelines are provided in
Section 25.14. Section 16.14.
This registry includes the possible roles that nodes can take in an This registry includes the possible roles that nodes can take in an
OSCORE group, each in combination with a numeric identifier. These OSCORE group, each in combination with a numeric identifier. These
numeric identifiers are used to express authorization information numeric identifiers are used to express authorization information
about joining OSCORE groups, as specified in Section 3 of [[This about joining OSCORE groups, as specified in Section 3 of [[This
document]]. document]].
The columns of this registry are: The columns of this registry are:
* Name: A value that can be used in documents for easier * Name: A value that can be used in documents for easier
skipping to change at page 78, line 44 skipping to change at page 80, line 44
* Description: This field contains a brief description of the role. * Description: This field contains a brief description of the role.
* Reference: This contains a pointer to the public specification for * Reference: This contains a pointer to the public specification for
the role. the role.
This registry will be initially populated by the values in Figure 1. This registry will be initially populated by the values in Figure 1.
The Reference column for all of these entries will be [[This The Reference column for all of these entries will be [[This
document]]. document]].
25.11. CoRE Resource Type 16.11. CoRE Resource Type
IANA is asked to register the following entry in the "Resource Type IANA is asked to register the following entry in the "Resource Type
(rt=) Link Target Attribute Values" registry within the "Constrained (rt=) Link Target Attribute Values" registry within the "Constrained
Restful Environments (CoRE) Parameters" registry group. Restful Environments (CoRE) Parameters" registry group.
* Value: "core.osc.gm" * Value: "core.osc.gm"
* Description: Group-membership resource of an OSCORE Group Manager. * Description: Group-membership resource of an OSCORE Group Manager.
* Reference: [[This document]] * Reference: [[This document]]
Client applications can use this resource type to discover a group Client applications can use this resource type to discover a group
membership resource at an OSCORE Group Manager, where to send a membership resource at an OSCORE Group Manager, where to send a
request for joining the corresponding OSCORE group. request for joining the corresponding OSCORE group.
25.12. ACE Scope Semantics 16.12. ACE Scope Semantics
IANA is asked to register the following entry in the "ACE Scope IANA is asked to register the following entry in the "ACE Scope
Semantics" registry defined in Section 11.12 of Semantics" registry defined in Section 11.12 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
* Value: SEM_ID_TBD * Value: SEM_ID_TBD
* Description: Membership and key management operations at the ACE * Description: Membership and key management operations at the ACE
Group Manager for Group OSCORE. Group Manager for Group OSCORE.
* Reference: [[This document]] * Reference: [[This document]]
25.13. ACE Groupcomm Errors 16.13. ACE Groupcomm Errors
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Errors" registry defined in Section 11.13 of Errors" registry defined in Section 11.13 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
* Value: 7 * Value: 7
* Description: Signatures not used in the group. * Description: Signatures not used in the group.
* Reference: [[This document]] * Reference: [[This document]]
skipping to change at page 80, line 5 skipping to change at page 82, line 5
* Description: Operation permitted only to signature verifiers. * Description: Operation permitted only to signature verifiers.
* Reference: [[This document]] * Reference: [[This document]]
* Value: 9 * Value: 9
* Description: Group currently not active. * Description: Group currently not active.
* Reference: [[This document]] * Reference: [[This document]]
25.14. Expert Review Instructions 16.14. Expert Review Instructions
The IANA registry established in this document is defined as "Expert The IANA registry established in this document is defined as "Expert
Review". This section gives some general guidelines for what the Review". This section gives some general guidelines for what the
experts should be looking for, but they are being designated as experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude. experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
* Clarity and correctness of registrations. Experts are expected to * Clarity and correctness of registrations. Experts are expected to
check the clarity of purpose and use of the requested entries. check the clarity of purpose and use of the requested entries.
Experts should inspect the entry for the considered role, to Experts should inspect the entry for the considered role, to
verify the correctness of its description against the role as verify the correctness of its description against the role as
intended in the specification that defined it. Expert should intended in the specification that defined it. Experts should
consider requesting an opinion on the correctness of registered consider requesting an opinion on the correctness of registered
parameters from the Authentication and Authorization for parameters from the Authentication and Authorization for
Constrained Environments (ACE) Working Group and the Constrained Constrained Environments (ACE) Working Group and the Constrained
RESTful Environments (CoRE) Working Group. RESTful Environments (CoRE) Working Group.
Entries that do not meet these objective of clarity and Entries that do not meet these objective of clarity and
completeness should not be registered. completeness should not be registered.
* Duplicated registration and point squatting should be discouraged. * Duplicated registration and point squatting should be discouraged.
Reviewers are encouraged to get sufficient information for Reviewers are encouraged to get sufficient information for
skipping to change at page 80, line 47 skipping to change at page 82, line 47
of devices it will be used on. Additionally, given a 'Value' V as of devices it will be used on. Additionally, given a 'Value' V as
code point, the length of the encoding of (2^(V+1) - 1) should be code point, the length of the encoding of (2^(V+1) - 1) should be
weighed against how many code points resulting in that encoding weighed against how many code points resulting in that encoding
length are left, and the resources and capabilities of devices it length are left, and the resources and capabilities of devices it
will be used on. will be used on.
* Specifications are recommended. When specifications are not * Specifications are recommended. When specifications are not
provided, the description provided needs to have sufficient provided, the description provided needs to have sufficient
information to verify the points above. information to verify the points above.
26. References 17. References
26.1. Normative References 17.1. Normative References
[COSE.Algorithms] [COSE.Algorithms]
IANA, "COSE Algorithms", IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>. cose.xhtml#algorithms>.
[COSE.Elliptic.Curves] [COSE.Elliptic.Curves]
IANA, "COSE Elliptic Curves", IANA, "COSE Elliptic Curves",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/
cose.xhtml#elliptic-curves>. cose.xhtml#elliptic-curves>.
skipping to change at page 81, line 28 skipping to change at page 83, line 28
parameters>. parameters>.
[COSE.Key.Types] [COSE.Key.Types]
IANA, "COSE Key Types", IANA, "COSE Key Types",
<https://www.iana.org/assignments/cose/cose.xhtml#key- <https://www.iana.org/assignments/cose/cose.xhtml#key-
type>. type>.
[I-D.ietf-ace-aif] [I-D.ietf-ace-aif]
Bormann, C., "An Authorization Information Format (AIF) Bormann, C., "An Authorization Information Format (AIF)
for ACE", Work in Progress, Internet-Draft, draft-ietf- for ACE", Work in Progress, Internet-Draft, draft-ietf-
ace-aif-06, 4 March 2022, ace-aif-07, 15 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-ace-aif- <https://www.ietf.org/archive/id/draft-ietf-ace-aif-
06.txt>. 07.txt>.
[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)", Work in Progress, Constrained Environments (ACE)", Work in Progress,
Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June
2021, <https://www.ietf.org/archive/id/draft-ietf-ace- 2021, <https://www.ietf.org/archive/id/draft-ietf-ace-
dtls-authorize-18.txt>. dtls-authorize-18.txt>.
skipping to change at page 84, line 29 skipping to change at page 86, line 29
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
26.2. Informative References 17.2. Informative References
[I-D.ietf-ace-oscore-gm-admin] [I-D.ietf-ace-oscore-gm-admin]
Tiloca, M., Höglund, R., Stok, P. V. D., and F. Palombini, Tiloca, M., Höglund, R., Stok, P. V. D., and F. Palombini,
"Admin Interface for the OSCORE Group Manager", Work in "Admin Interface for the OSCORE Group Manager", Work in
Progress, Internet-Draft, draft-ietf-ace-oscore-gm-admin- Progress, Internet-Draft, draft-ietf-ace-oscore-gm-admin-
05, 7 March 2022, <https://www.ietf.org/archive/id/draft- 05, 7 March 2022, <https://www.ietf.org/archive/id/draft-
ietf-ace-oscore-gm-admin-05.txt>. ietf-ace-oscore-gm-admin-05.txt>.
[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-
skipping to change at page 86, line 15 skipping to change at page 88, line 15
Appendix A. Profile Requirements Appendix A. Profile Requirements
This section lists how this application profile of ACE addresses the This section lists how this application profile of ACE addresses the
requirements defined in Appendix A of [I-D.ietf-ace-key-groupcomm]. requirements defined in Appendix A of [I-D.ietf-ace-key-groupcomm].
A.1. Mandatory-to-Address Requirements A.1. Mandatory-to-Address Requirements
* REQ1 - Specify the format and encoding of 'scope'. This includes * REQ1 - Specify the format and encoding of 'scope'. This includes
defining the set of possible roles and their identifiers, as well defining the set of possible roles and their identifiers, as well
as the corresponding encoding to use in the scope entries as the corresponding encoding to use in the scope entries
according to the used scope format: see Section 3 and Section 4.1. according to the used scope format: see Section 3 and Section 5.1.
* REQ2 - If the AIF format of 'scope' is used, register its specific * REQ2 - If the AIF format of 'scope' is used, register its specific
instance of "Toid" and "Tperm" as Media Type parameters and a instance of "Toid" and "Tperm" as Media Type parameters and a
corresponding Content-Format, as per the guidelines in corresponding Content-Format, as per the guidelines in
[I-D.ietf-ace-aif]: see Section 25.8 and Section 25.9. [I-D.ietf-ace-aif]: see Section 16.8 and Section 16.9.
* REQ3 - if used, specify the acceptable values for 'sign_alg': * REQ3 - if used, specify the acceptable values for 'sign_alg':
values from the "Value" column of the "COSE Algorithms" registry values from the "Value" column of the "COSE Algorithms" registry
[COSE.Algorithms]. [COSE.Algorithms].
* REQ4 - If used, specify the acceptable values for * REQ4 - If used, specify the acceptable values for
'sign_parameters': format and values from the COSE algorithm 'sign_parameters': format and values from the COSE algorithm
capabilities as specified in the "COSE Algorithms" registry capabilities as specified in the "COSE Algorithms" registry
[COSE.Algorithms]. [COSE.Algorithms].
* REQ5 - If used, specify the acceptable values for * REQ5 - If used, specify the acceptable values for
'sign_key_parameters': format and values from the COSE key type 'sign_key_parameters': format and values from the COSE key type
capabilities as specified in the "COSE Key Types" registry capabilities as specified in the "COSE Key Types" registry
[COSE.Key.Types]. [COSE.Key.Types].
* REQ6 - Specify the acceptable formats for authentication * REQ6 - Specify the acceptable formats for authentication
credentials and, if used, the acceptable values for 'pub_key_enc': credentials and, if used, the acceptable values for 'pub_key_enc':
acceptable formats explicitly provide the public key as well as acceptable formats explicitly provide the public key as well as
the comprehensive set of information related to the public key the comprehensive set of information related to the public key
algorithm (see Section 6.1 and Section 6.4). Consistent algorithm (see Section 5.3 and Section 6.3). Consistent
acceptable values for 'pub_key_enc' are taken from the "Label" acceptable values for 'pub_key_enc' are taken from the "Label"
column of the "COSE Header Parameters" registry column of the "COSE Header Parameters" registry
[COSE.Header.Parameters]. [COSE.Header.Parameters].
* REQ7 - If the value of the GROUPNAME URI path and the group name * REQ7 - If the value of the GROUPNAME URI path and the group name
in the Access Token scope (gname in Section 3.1 of in the Access Token scope (gname in Section 3.1 of
[I-D.ietf-ace-key-groupcomm]) are not required to coincide, [I-D.ietf-ace-key-groupcomm]) are not required to coincide,
specify the mechanism to map the GROUPNAME value in the URI to the specify the mechanism to map the GROUPNAME value in the URI to the
group name: not applicable, since a perfect matching is required. group name: not applicable, since a perfect matching is required.
* REQ8 - Define whether the KDC has an authentication credential and * REQ8 - Define whether the KDC has an authentication credential and
if this has to be provided through the 'kdc_cred' parameter, see if this has to be provided through the 'kdc_cred' parameter, see
Section 4.1 of [I-D.ietf-ace-key-groupcomm]: yes, as required by Section 4.1 of [I-D.ietf-ace-key-groupcomm]: yes, as required by
the Group OSCORE protocol [I-D.ietf-core-oscore-groupcomm], see the Group OSCORE protocol [I-D.ietf-core-oscore-groupcomm], see
Section 6.4 of this document. Section 6.3 of this document.
* REQ9 - Specify if any part of the KDC interface as defined in * REQ9 - Specify if any part of the KDC interface as defined in
Section 4.1 of [I-D.ietf-ace-key-groupcomm] is not supported by Section 4.1 of [I-D.ietf-ace-key-groupcomm] is not supported by
the KDC: not applicable. the KDC: not applicable.
* REQ10 - Register a Resource Type for the root url-path, which is * REQ10 - Register a Resource Type for the root url-path, which is
used to discover the correct url to access at the KDC (see used to discover the correct url to access at the KDC (see
Section 4.1 of [I-D.ietf-ace-key-groupcomm]): the Resource Type Section 4.1 of [I-D.ietf-ace-key-groupcomm]): the Resource Type
(rt=) Link Target Attribute value "core.osc.gm" is registered in (rt=) Link Target Attribute value "core.osc.gm" is registered in
Section 25.11. Section 16.11.
* REQ11 - Define what specific actions (e.g., CoAP methods) are * REQ11 - Define what specific actions (e.g., CoAP methods) are
allowed on each resource provided by the KDC interface, depending allowed on each resource provided by the KDC interface, depending
on whether the Client is a current group member; the roles that a on whether the Client is a current group member; the roles that a
Client is authorized to take as per the obtained access token; and Client is authorized to take as per the obtained access token; and
the roles that the Client has as current group member: see the roles that the Client has as current group member: see
Section 5.4. Section 8.4.
* REQ12 - Categorize possible newly defined operations for Clients * REQ12 - Categorize possible newly defined operations for Clients
into primary operations expected to be minimally supported and into primary operations expected to be minimally supported and
secondary operations, and provide accompanying considerations (see secondary operations, and provide accompanying considerations: see
Section 5.5). Section 8.5.
* REQ13 - Specify the encoding of group identifier (see * REQ13 - Specify the encoding of group identifier (see
Section 4.2.1 of [I-D.ietf-ace-key-groupcomm]): CBOR byte string Section 4.2.1 of [I-D.ietf-ace-key-groupcomm]): CBOR byte string
(see Section 17). (see Section 9.10).
* REQ14 - Specify the approaches used to compute and verify the PoP * REQ14 - Specify the approaches used to compute and verify the PoP
evidence to include in 'client_cred_verify', and which of those evidence to include in 'client_cred_verify', and which of those
approaches is used in which case: see Section 6.2 and Section 6.3. approaches is used in which case: see Section 6.1 and Section 6.2.
* REQ15 - Specify how the nonce N_S is generated, if the token is * REQ15 - Specify how the nonce N_S is generated, if the token is
not provided to the KDC through the Token Transfer Request to the not provided to the KDC through the Token Transfer Request to the
authz-info endpoint (e.g., if it is used directly to validate TLS authz-info endpoint (e.g., if it is used directly to validate TLS
instead): see Section 6.2.1. instead): see Section 6.1.1.
* REQ16 - Define the initial value of the 'num' parameter: The * REQ16 - Define the initial value of the 'num' parameter: the
initial value MUST be set to 0 when creating the OSCORE group, initial value MUST be set to 0 when creating the OSCORE group,
e.g., as in [I-D.ietf-ace-oscore-gm-admin]. e.g., as in [I-D.ietf-ace-oscore-gm-admin].
* REQ17 - Specify the format of the 'key' parameter: see * REQ17 - Specify the format of the 'key' parameter: see
Section 6.4. Section 6.3.
* REQ18 - Specify acceptable values of the 'gkty' parameter: * REQ18 - Specify acceptable values of the 'gkty' parameter:
Group_OSCORE_Input_Material object (see Section 6.4). Group_OSCORE_Input_Material object (see Section 6.3).
* REQ19 - Specify and register the application profile identifier: * REQ19 - Specify and register the application profile identifier:
coap_group_oscore_app (see Section 25.5). coap_group_oscore_app (see Section 16.5).
* REQ20 - If used, specify the format and content of * REQ20 - If used, specify the format and content of
'group_policies' and its entries: see Section 6.4. 'group_policies' and its entries: see Section 6.3.
* REQ21 - Specify the approaches used to compute and verify the PoP * REQ21 - Specify the approaches used to compute and verify the PoP
evidence to include in 'kdc_cred_verify', and which of those evidence to include in 'kdc_cred_verify', and which of those
approaches is used in which case: see Section 6.4, Section 6.5 and approaches is used in which case: see Section 6.3, Section 6.4 and
Section 12. Section 9.5.
* REQ22 - Specify the communication protocol that the members of the * REQ22 - Specify the communication protocol that the members of the
group must use: CoAP [RFC7252], possibly over IP multicast group must use: CoAP [RFC7252], also for group communication
[I-D.ietf-core-groupcomm-bis]. [I-D.ietf-core-groupcomm-bis].
* REQ23 - Specify the security protocols that the group members must * REQ23 - Specify the security protocols that the group members must
use to protect their communication: Group OSCORE use to protect their communication: Group OSCORE
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
* REQ24 - Specify how the communication is secured between the * REQ24 - 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].
* REQ25 - Specify the format of the identifiers of group members: * REQ25 - Specify the format of the identifiers of group members:
the Sender ID used in the OSCORE group (see Section 6.4 and the Sender ID used in the OSCORE group (see Section 6.3 and
Section 10). Section 9.3).
* REQ26 - Specify policies at the KDC to handle member ids that are * REQ26 - Specify policies at the KDC to handle member ids that are
not included in 'get_pub_keys': see Section 10. not included in 'get_pub_keys': see Section 9.3.
* REQ27 - Specify the format of newly-generated individual keying * REQ27 - 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 9. and corresponding CBOR label: see Section 9.2.
* REQ28 - Specify and register the identifier of newly defined * REQ28 - Specify and register the identifier of newly defined
semantics for binary scopes: see Section 25.12. semantics for binary scopes: see Section 16.12.
* REQ29 - Categorize newly defined parameters according to the same * REQ29 - Categorize newly defined parameters according to the same
criteria of Section 8 of [I-D.ietf-ace-key-groupcomm]: see criteria of Section 8 of [I-D.ietf-ace-key-groupcomm]: see
Section 21. Section 12.
* REQ30 - Define whether Clients must, should or may support the * REQ30 - Define whether Clients must, should or may support the
conditional parameters defined in Section 8 of conditional parameters defined in Section 8 of
[I-D.ietf-ace-key-groupcomm], and under which circumstances: see [I-D.ietf-ace-key-groupcomm], and under which circumstances: see
Section 21. Section 12.
A.2. Optional-to-Address Requirements A.2. Optional-to-Address Requirements
* OPT1 (Optional) - If the textual format of 'scope' is used, * OPT1 (Optional) - If the textual format of 'scope' is used,
specify CBOR values to use for abbreviating the role identifiers specify CBOR values to use for abbreviating the role identifiers
in the group: not applicable. in the group: not applicable.
* OPT2 (Optional) - Specify additional parameters used in the * OPT2 (Optional) - Specify additional parameters used in the
exchange of Token Transfer Request and Response: exchange of Token Transfer Request and Response:
- 'ecdh_info', to negotiate the ECDH algorithm, ECDH algorithm - 'ecdh_info', to negotiate the ECDH algorithm, ECDH algorithm
parameters, ECDH key parameters and exact format of parameters, ECDH key parameters and exact format of
authentication credentials used in the group, in case the authentication credentials used in the group, in case the
joining node supports the pairwise mode of Group OSCORE (see joining node supports the pairwise mode of Group OSCORE (see
Section 6.1). Section 5.3).
- 'kdc_dh_creds', to ask for and retrieve the Group Manager's - 'kdc_dh_creds', to ask for and retrieve the Group Manager's
Diffie-Hellman authentication credentials, in case the joining Diffie-Hellman authentication credentials, in case the joining
node supports the pairwise mode of Group OSCORE and the Access node supports the pairwise mode of Group OSCORE and the Access
Token authorizes to join parwise-only groups (see Section 6.1). Token authorizes to join parwise-only groups (see Section 5.3).
* OPT3 (Optional) - Specify the negotiation of parameter values for * OPT3 (Optional) - Specify the negotiation of parameter values for
signature algorithm and signature keys, if 'sign_info' is not signature algorithm and signature keys, if 'sign_info' is not
used: possible early discovery by using the approach based on the used: possible early discovery by using the approach based on the
CoRE Resource Directory described in CoRE Resource Directory described in
[I-D.tiloca-core-oscore-discovery]. [I-D.tiloca-core-oscore-discovery].
* OPT4 (Optional) - Specify possible or required payload formats for * OPT4 (Optional) - Specify possible or required payload formats for
specific error cases: send a 4.00 (Bad Request) error response to specific error cases: send a 4.00 (Bad Request) error response to
a Joining Request (see Section 6.3). a Joining Request (see Section 6.2).
* OPT5 (Optional) - Specify additional identifiers of error types, * OPT5 (Optional) - Specify additional identifiers of error types,
as values of the 'error' field in an error response from the KDC: as values of the 'error' field in an error response from the KDC:
see Section 25.13. see Section 16.13.
* OPT6 (Optional) - Specify the encoding of 'pub_keys_repos' if the * OPT6 (Optional) - Specify the encoding of 'pub_keys_repos' if the
default is not used: no. default is not used: no.
* OPT7 (Optional) - Specify the functionalities implemented at the * OPT7 (Optional) - Specify the functionalities implemented at the
'control_uri' resource hosted at the Client, including message 'control_uri' resource hosted at the Client, including message
exchange encoding and other details (see Section 4.3.1 of exchange encoding and other details (see Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm]): see Section 19 for the eviction of [I-D.ietf-ace-key-groupcomm]): see Section 10 for the eviction of
a group member; see Section 20 for the group rekeying process. a group member; see Section 11 for the group rekeying process.
* OPT8 (Optional) - Specify the behavior of the handler in case of * OPT8 (Optional) - Specify the behavior of the handler in case of
failure to retrieve an authentication credential for the specific failure to retrieve an authentication credential for the specific
node: send a 4.00 (Bad Request) error response to a Joining node: send a 4.00 (Bad Request) error response to a Joining
Request (see Section 6.3). Request (see Section 6.2).
* OPT9 (Optional) - Define a default group rekeying scheme, to refer * OPT9 (Optional) - Define a default group rekeying scheme, to refer
to in case the 'rekeying_scheme' parameter is not included in the to in case the 'rekeying_scheme' parameter is not included in the
Joining Response (see Section 4.3.1.1 of Joining Response (see Section 4.3.1.1 of
[I-D.ietf-ace-key-groupcomm]): the "Point-to-Point" rekeying [I-D.ietf-ace-key-groupcomm]): the "Point-to-Point" rekeying
scheme registered in Section 11.14 of scheme registered in Section 11.14 of
[I-D.ietf-ace-key-groupcomm], whose detailed use for this profile [I-D.ietf-ace-key-groupcomm], whose detailed use for this profile
is defined in Section 20 of this document. is defined in Section 11 of this document.
* OPT10 (Optional) - Specify the functionalities implemented at the * OPT10 (Optional) - Specify the functionalities implemented at the
'control_group_uri' resource hosted at the Client, including 'control_group_uri' resource hosted at the Client, including
message exchange encoding and other details (see Section 4.3.1 of message exchange encoding and other details (see Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm]): see Section 19 for the eviction of [I-D.ietf-ace-key-groupcomm]): see Section 10 for the eviction of
multiple group members. multiple group members.
* OPT11 (Optional) - Specify policies that instruct clients to * OPT11 (Optional) - Specify policies that instruct Clients to
retain unsuccessfully decrypted messages and for how long, so that retain unsuccessfully decrypted messages and for how long, so that
they can be decrypted after getting updated keying material: no. they can be decrypted after getting updated keying material: no.
* OPT12 (Optional) - Specify for the KDC to perform group rekeying * OPT12 (Optional) - Specify for the KDC to perform group rekeying
(together or instead of renewing individual keying material) when (together or instead of renewing individual keying material) when
receiving a Key Renewal Request: the Group Manager SHOULD NOT receiving a Key Renewal Request: the Group Manager SHOULD NOT
perform a group rekeying, unless already scheduled to occur perform a group rekeying, unless already scheduled to occur
shortly (see Section 9). shortly (see Section 9.2).
* OPT13 (Optional) - Specify how the identifier of a group members's * OPT13 (Optional) - Specify how the identifier of a group members's
authentication credential is included in requests sent to other authentication credential is included in requests sent to other
group members: no. group members: no.
* OPT14 (Optional) - Specify additional information to include in * OPT14 (Optional) - Specify additional information to include in
rekeying messages for the "Point-to-Point" group rekeying scheme rekeying messages for the "Point-to-Point" group rekeying scheme
(see Section 6.1 of [I-D.ietf-ace-key-groupcomm]): see (see Section 6.1 of [I-D.ietf-ace-key-groupcomm]): see
Section 20.1. Section 11.1.
* OPT15 (Optional) - Specify if Clients must or should support any * OPT15 (Optional) - Specify if Clients must or should support any
of the parameters defined as optional in Section 8 of of the parameters defined as optional in Section 8 of
[I-D.ietf-ace-key-groupcomm]: no. [I-D.ietf-ace-key-groupcomm]: no.
Appendix B. Extensibility for Future COSE Algorithms Appendix B. Extensibility for Future COSE Algorithms
As defined in Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs], future As defined in Section 8.1 of [I-D.ietf-cose-rfc8152bis-algs], future
algorithms can be registered in the "COSE Algorithms" registry algorithms can be registered in the "COSE Algorithms" registry
[COSE.Algorithms] as specifying none or multiple COSE capabilities. [COSE.Algorithms] as specifying none or multiple COSE capabilities.
To enable the seamless use of such future registered algorithms, this To enable the seamless use of such future registered algorithms, this
section defines a general, agile format for: section defines a general, agile format for:
* Each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token * Each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token
Transfer Response, see Section 6.1 and Section 6.1.1; Transfer Response (see Section 5.3 and Section 5.3.1);
* The 'sign_params' and 'ecdh_params' parameters within the 'key' * The 'sign_params' and 'ecdh_params' parameters within the 'key'
parameter, see Section 6.4, as part of the response payloads used parameter (see Section 6.3), as part of the response payloads used
in Section 6.4, Section 8.1, Section 8.2 and Section 20. in Section 6.3, Section 9.1.1, Section 9.1.2 and Section 11.
Appendix B of [I-D.ietf-ace-key-groupcomm] describes the analogous Appendix B of [I-D.ietf-ace-key-groupcomm] describes the analogous
general format for 'sign_info_entry' of the 'sign_info' parameter in general format for 'sign_info_entry' of the 'sign_info' parameter in
the Token Transfer Response, see Section 6.1. the Token Transfer Response (see Section 5.3 of this document).
If any of the currently registered COSE algorithms is considered, If any of the currently registered COSE algorithms is considered,
using this general format yields the same structure defined in this using this general format yields the same structure defined in this
document for the items above, thus ensuring retro-compatibility. document for the items above, thus ensuring retro-compatibility.
B.1. Format of 'ecdh_info_entry' B.1. Format of 'ecdh_info_entry'
The format of each 'ecdh_info_entry' (see Section 6.1 and The format of each 'ecdh_info_entry' (see Section 5.3 and
Section 6.1.1) is generalized as follows. Given N the number of Section 5.3.1) is generalized as follows. Given N the number of
elements of the 'ecdh_parameters' array, i.e., the number of COSE elements of the 'ecdh_parameters' array, i.e., the number of COSE
capabilities of the ECDH algorithm, then: capabilities of the ECDH algorithm, then:
* 'ecdh_key_parameters' is replaced by N elements 'ecdh_capab_i', * 'ecdh_key_parameters' is replaced by N elements 'ecdh_capab_i',
each of which is a CBOR array. each of which is a CBOR array.
* The i-th array following 'ecdh_parameters', i.e., 'ecdh_capab_i' * The i-th array following 'ecdh_parameters', i.e., 'ecdh_capab_i'
(i = 0, ..., N-1), is the array of COSE capabilities for the (i = 0, ..., N-1), is the array of COSE capabilities for the
algorithm capability specified in 'ecdh_parameters'[i]. algorithm capability specified in 'ecdh_parameters'[i].
skipping to change at page 92, line 4 skipping to change at page 94, line 4
..., ...,
alg_capab_N : any], alg_capab_N : any],
ecdh_capab_1 : [ any ], ecdh_capab_1 : [ any ],
ecdh_capab_2 : [ any ], ecdh_capab_2 : [ any ],
..., ...,
ecdh_capab_N : [ any ], ecdh_capab_N : [ any ],
cred_fmt = int / null cred_fmt = int / null
] ]
gname = tstr gname = tstr
Figure 12: 'ecdh_info_entry' with general format Figure 13: 'ecdh_info_entry' with general format
B.2. Format of 'key' B.2. Format of 'key'
The format of 'key' (see Section 6.4) is generalized as follows. The format of 'key' (see Section 6.3) is generalized as follows.
* The 'sign_params' array includes N+1 elements, whose exact * The 'sign_params' array includes N+1 elements, whose exact
structure and value depend on the value of the signature algorithm structure and value depend on the value of the signature algorithm
specified in 'sign_alg'. specified in 'sign_alg'.
- The first element, i.e., 'sign_params'[0], is the array of the - The first element, i.e., 'sign_params'[0], is the array of the
N COSE capabilities for the signature algorithm, as specified N COSE capabilities for the signature algorithm, as specified
for that algorithm in the "Capabilities" column of the "COSE for that algorithm in the "Capabilities" column of the "COSE
Algorithms" registry [COSE.Algorithms] (see Section 8.1 of Algorithms" registry [COSE.Algorithms] (see Section 8.1 of
[I-D.ietf-cose-rfc8152bis-algs]). [I-D.ietf-cose-rfc8152bis-algs]).
skipping to change at page 93, line 9 skipping to change at page 95, line 9
capability of the algorithm, then 'ecdh_params'[1] is the array of capability of the algorithm, then 'ecdh_params'[1] is the array of
COSE capabilities for the COSE key type associated with the ECDH COSE capabilities for the COSE key type associated with the ECDH
algorithm, as specified for that key type in the "Capabilities" algorithm, as specified for that key type in the "Capabilities"
column of the "COSE Key Types" registry [COSE.Key.Types] (see column of the "COSE Key Types" registry [COSE.Key.Types] (see
Section 8.2 of [I-D.ietf-cose-rfc8152bis-algs]). Section 8.2 of [I-D.ietf-cose-rfc8152bis-algs]).
Appendix C. Document Updates Appendix C. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
C.1. Version -12 to -13 C.1. Version -13 to -14
* Major reordering of the document sections.
* The HKDF Algorithm is specified by the HMAC Algorithm.
* Group communication does not necessarily use IP multicast.
* Generalized AIF data model, also for draft-ace-oscore-gm-admin.
* Clarifications and editorial improvements.
C.2. Version -12 to -13
* Renamed parameters about authentication credentials. * Renamed parameters about authentication credentials.
* It is optional for the Group Manager to reassign Gids by tracking * It is optional for the Group Manager to reassign Gids by tracking
"Birth Gids". "Birth Gids".
* Distinction between authentication credentials and public keys. * Distinction between authentication credentials and public keys.
* Updated IANA considerations related to AIF. * Updated IANA considerations related to AIF.
* Updated textual description of registered ACE Scope Semantics * Updated textual description of registered ACE Scope Semantics
value. value.
C.2. Version -11 to -12 C.3. Version -11 to -12
* Clarified semantics of 'ecdh_info' and 'kdc_dh_creds'. * Clarified semantics of 'ecdh_info' and 'kdc_dh_creds'.
* Definition of /ace-group/GROUPNAME/kdc-pub-key moved to draft- * Definition of /ace-group/GROUPNAME/kdc-pub-key moved to draft-
ietf-ace-key-groupcomm. ietf-ace-key-groupcomm.
* ace-group/ accessible also to non-members that are not Verifiers. * ace-group/ accessible also to non-members that are not Verifiers.
* Clarified what resources are accessible to Verifiers. * Clarified what resources are accessible to Verifiers.
skipping to change at page 94, line 11 skipping to change at page 96, line 23
rekeying messages. rekeying messages.
* Revised names of new IANA registries. * Revised names of new IANA registries.
* Clarified meaning of registered CoRE resource type. * Clarified meaning of registered CoRE resource type.
* Alignment to new requirements from draft-ietf-ace-key-groupcomm. * Alignment to new requirements from draft-ietf-ace-key-groupcomm.
* Fixes and editorial improvements. * Fixes and editorial improvements.
C.3. Version -10 to -11 C.4. Version -10 to -11
* Removed redundancy of key type capabilities, from 'sign_info', * Removed redundancy of key type capabilities, from 'sign_info',
'ecdh_info' and 'key'. 'ecdh_info' and 'key'.
* New resource to retrieve the Group Manager's authentication * New resource to retrieve the Group Manager's authentication
credential. credential.
* New resource to retrieve material for Signature Verifiers. * New resource to retrieve material for Signature Verifiers.
* New parameter 'sign_enc_alg' related to the group mode. * New parameter 'sign_enc_alg' related to the group mode.
skipping to change at page 95, line 10 skipping to change at page 97, line 21
* Added examples of message exchanges. * Added examples of message exchanges.
* Revised default values of group configuration parameters. * Revised default values of group configuration parameters.
* Fixes to IANA registrations. * Fixes to IANA registrations.
* General format of parameters related to COSE capabilities, * General format of parameters related to COSE capabilities,
supporting future registered COSE algorithms (new Appendix). supporting future registered COSE algorithms (new Appendix).
C.4. Version -09 to -10 C.5. Version -09 to -10
* Updated non-recycling policy of Sender IDs. * Updated non-recycling policy of Sender IDs.
* Removed policies about Sender Sequence Number synchronization. * Removed policies about Sender Sequence Number synchronization.
* 'control_path' renamed to 'control_uri'. * 'control_path' renamed to 'control_uri'.
* Format of 'get_pub_keys' aligned with draft-ietf-ace-key- * Format of 'get_pub_keys' aligned with draft-ietf-ace-key-
groupcomm. groupcomm.
* Additional way to inform of group eviction. * Additional way to inform of group eviction.
* Registered semantics identifier for extended scope format. * Registered semantics identifier for extended scope format.
* Extended error handling, with error type specified in some error * Extended error handling, with error type specified in some error
responses. responses.
* Renumbered requirements. * Renumbered requirements.
C.5. Version -08 to -09 C.6. Version -08 to -09
* The url-path "ace-group" is used. * The url-path "ace-group" is used.
* Added overview of admitted methods on the Group Manager resources. * Added overview of admitted methods on the Group Manager resources.
* Added exchange of parameters relevant for the pairwise mode of * Added exchange of parameters relevant for the pairwise mode of
Group OSCORE. Group OSCORE.
* The signed value for 'client_cred_verify' includes also the scope. * The signed value for 'client_cred_verify' includes also the scope.
skipping to change at page 96, line 16 skipping to change at page 98, line 28
* Removed group policy about supporting Group OSCORE in pairwise * Removed group policy about supporting Group OSCORE in pairwise
mode. mode.
* Registration of the resource type rt="core.osc.gm". * Registration of the resource type rt="core.osc.gm".
* Update list of requirements. * Update list of requirements.
* Clarifications and editorial revision. * Clarifications and editorial revision.
C.6. Version -07 to -08 C.7. Version -07 to -08
* AIF specific data model to express scope entries. * AIF specific data model to express scope entries.
* A set of roles is checked as valid when processing the Joining * A set of roles is checked as valid when processing the Joining
Request. Request.
* Updated format of 'get_pub_keys' in the Joining Request. * Updated format of 'get_pub_keys' in the Joining Request.
* Payload format and default values of group policies in the Joining * Payload format and default values of group policies in the Joining
Response. Response.
* Updated payload format of the FETCH request to retrieve * Updated payload format of the FETCH request to retrieve
authentication credentials. authentication credentials.
* Default values for group configuration parameters. * Default values for group configuration parameters.
* IANA registrations to support the AIF specific data model. * IANA registrations to support the AIF specific data model.
C.7. Version -06 to -07 C.8. Version -06 to -07
* Alignments with draft-ietf-core-oscore-groupcomm. * Alignments with draft-ietf-core-oscore-groupcomm.
* New format of 'sign_info', using the COSE capabilities. * New format of 'sign_info', using the COSE capabilities.
* New format of Joining Response parameters, using the COSE * New format of Joining Response parameters, using the COSE
capabilities. capabilities.
* Considerations on group rekeying. * Considerations on group rekeying.
* Editorial revision. * Editorial revision.
C.8. Version -05 to -06 C.9. Version -05 to -06
* Added role of external signature verifier. * Added role of external signature verifier.
* Parameter 'rsnonce' renamed to 'kdcchallenge'. * Parameter 'rsnonce' renamed to 'kdcchallenge'.
* Parameter 'kdcchallenge' may be omitted in some cases. * Parameter 'kdcchallenge' may be omitted in some cases.
* Clarified difference between group name and OSCORE Gid. * Clarified difference between group name and OSCORE Gid.
* Removed the role combination ["requester", "monitor"]. * Removed the role combination ["requester", "monitor"].
skipping to change at page 97, line 29 skipping to change at page 99, line 42
* Possible individual rekeying of a single requesting node combined * Possible individual rekeying of a single requesting node combined
with a group rekeying. with a group rekeying.
* Security considerations on reusage of signature challenges. * Security considerations on reusage of signature challenges.
* Addressing optional requirement OPT12 from draft-ietf-ace-key- * Addressing optional requirement OPT12 from draft-ietf-ace-key-
groupcomm groupcomm
* Editorial improvements. * Editorial improvements.
C.9. Version -04 to -05 C.10. Version -04 to -05
* Nonce N_S also in error responses to the Joining Requests. * Nonce N_S also in error responses to the Joining Requests.
* Supporting single Access Token for multiple groups/topics. * Supporting single Access Token for multiple groups/topics.
* Supporting legal requesters/responders using the 'peer_roles' * Supporting legal requesters/responders using the 'peer_roles'
parameter. parameter.
* Registered and used dedicated label for TLS Exporter. * Registered and used dedicated label for TLS Exporter.
skipping to change at page 98, line 10 skipping to change at page 100, line 24
* Clarification on incrementing version number when rekeying the * Clarification on incrementing version number when rekeying the
group. group.
* Clarification on what is re-distributed with the group rekeying. * Clarification on what is re-distributed with the group rekeying.
* Security considerations on the size of the nonces used for the * Security considerations on the size of the nonces used for the
signature challenge. signature challenge.
* Added CBOR values to abbreviate role identifiers in the group. * Added CBOR values to abbreviate role identifiers in the group.
C.10. Version -03 to -04 C.11. Version -03 to -04
* New abstract. * New abstract.
* Moved general content to draft-ietf-ace-key-groupcomm * Moved general content to draft-ietf-ace-key-groupcomm
* Terminology: node name; node resource. * Terminology: node name; node resource.
* Creation and pointing at node resource. * Creation and pointing at node resource.
* Updated Group Manager API (REST methods and offered services). * Updated Group Manager API (REST methods and offered services).
skipping to change at page 98, line 32 skipping to change at page 100, line 46
* Size of challenges 'cnonce' and 'rsnonce'. * Size of challenges 'cnonce' and 'rsnonce'.
* Value of 'rsnonce' for reused or non-traditionally-posted tokens. * Value of 'rsnonce' for reused or non-traditionally-posted tokens.
* Removed reference to RFC 7390. * Removed reference to RFC 7390.
* New requirements from draft-ietf-ace-key-groupcomm * New requirements from draft-ietf-ace-key-groupcomm
* Editorial improvements. * Editorial improvements.
C.11. Version -02 to -03 C.12. Version -02 to -03
* New sections, aligned with the interface of ace-key-groupcomm . * New sections, aligned with the interface of ace-key-groupcomm .
* Exchange of information on the signature algorithm and related * Exchange of information on the signature algorithm and related
parameters, during the Token POST (Section 4.1). parameters, during the Token POST (Section 4.1).
* Nonce 'rsnonce' from the Group Manager to the Client * Nonce 'rsnonce' from the Group Manager to the Client
(Section 4.1). (Section 4.1).
* Client PoP signature in the Key Distribution Request upon joining * Client PoP signature in the Key Distribution Request upon joining
skipping to change at page 99, line 7 skipping to change at page 101, line 21
* Local actions on the Group Manager, upon a new node's joining * Local actions on the Group Manager, upon a new node's joining
(Section 4.2). (Section 4.2).
* Local actions on the Group Manager, upon a node's leaving * Local actions on the Group Manager, upon a node's leaving
(Section 12). (Section 12).
* IANA registration in ACE Groupcomm Parameters registry. * IANA registration in ACE Groupcomm Parameters registry.
* More fulfilled profile requirements (Appendix A). * More fulfilled profile requirements (Appendix A).
C.12. Version -01 to -02 C.13. Version -01 to -02
* Editorial fixes. * Editorial fixes.
* Changed: "listener" to "responder"; "pure listener" to "monitor". * Changed: "listener" to "responder"; "pure listener" to "monitor".
* Changed profile name to "coap_group_oscore_app", to reflect it is * Changed profile name to "coap_group_oscore_app", to reflect it is
an application profile. an application profile.
* Added the 'type' parameter for all requests to a Join Resource. * Added the 'type' parameter for all requests to a Join Resource.
skipping to change at page 99, line 46 skipping to change at page 102, line 11
* Extended security considerations: proof-of-possession of signature * Extended security considerations: proof-of-possession of signature
keys; collision of OSCORE Group Identifiers (Section 8). keys; collision of OSCORE Group Identifiers (Section 8).
* Registered three entries in the IANA registry "Sequence Number * Registered three entries in the IANA registry "Sequence Number
Synchronization Method" (Section 9). Synchronization Method" (Section 9).
* Registered one public key encoding in the "ACE Public Key * Registered one public key encoding in the "ACE Public Key
Encoding" IANA registry (Section 9). Encoding" IANA registry (Section 9).
C.13. Version -00 to -01 C.14. Version -00 to -01
* Changed name of 'req_aud' to 'audience' in the Authorization * Changed name of 'req_aud' to 'audience' in the Authorization
Request (Section 3.1). Request (Section 3.1).
* Added negotiation of signature algorithm/parameters between Client * Added negotiation of signature algorithm/parameters between Client
and Group Manager (Section 4). and Group Manager (Section 4).
* Updated format of the Key Distribution Response as a whole * Updated format of the Key Distribution Response as a whole
(Section 4.3). (Section 4.3).
 End of changes. 382 change blocks. 
1170 lines changed or deleted 1283 lines changed or added

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