< draft-ietf-ace-key-groupcomm-oscore-12.txt   draft-ietf-ace-key-groupcomm-oscore-13.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: 28 April 2022 Universitaet Duisburg-Essen Expires: 8 September 2022 Universitaet Duisburg-Essen
F. Palombini F. Palombini
Ericsson AB Ericsson AB
25 October 2021 7 March 2022
Key Management for OSCORE Groups in ACE Key Management for OSCORE Groups in ACE
draft-ietf-ace-key-groupcomm-oscore-12 draft-ietf-ace-key-groupcomm-oscore-13
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 secured with Group Object Security for Constrained RESTful
Environments (OSCORE). This application profile delegates the Environments (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 group
through a Resource Server acting as Group Manager for that group. through a Resource Server acting as Group Manager for that group.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 April 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text extracted from this document must include Revised BSD License text as
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 Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Overview of the Joining Process . . . . . . . . . . . . . 7 2.1. Overview of the Joining Process . . . . . . . . . . . . . 7
2.2. Overview of the Group Rekeying Process . . . . . . . . . 7 2.2. Overview of the Group Rekeying Process . . . . . . . . . 7
2.2.1. Stale OSCORE Sender IDs . . . . . . . . . . . . . . . 9 2.2.1. Stale OSCORE Sender IDs . . . . . . . . . . . . . . . 9
3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 10 3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 10
4. Joining Node to Authorization Server . . . . . . . . . . . . 11 4. Joining Node to Authorization Server . . . . . . . . . . . . 11
4.1. Authorization Request . . . . . . . . . . . . . . . . . . 12 4.1. Authorization Request . . . . . . . . . . . . . . . . . . 12
4.2. Authorization Response . . . . . . . . . . . . . . . . . 12 4.2. Authorization Response . . . . . . . . . . . . . . . . . 12
5. Interface at the Group Manager . . . . . . . . . . . . . . . 12 5. Interface at the Group Manager . . . . . . . . . . . . . . . 13
5.1. ace-group/GROUPNAME/active . . . . . . . . . . . . . . . 13 5.1. ace-group/GROUPNAME/active . . . . . . . . . . . . . . . 13
5.1.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 13
5.2. ace-group/GROUPNAME/verif-data . . . . . . . . . . . . . 13 5.2. ace-group/GROUPNAME/verif-data . . . . . . . . . . . . . 14
5.2.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 14 5.2.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 14
5.3. ace-group/GROUPNAME/stale-sids . . . . . . . . . . . . . 14 5.3. ace-group/GROUPNAME/stale-sids . . . . . . . . . . . . . 14
5.3.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 14 5.3.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 15
5.4. Admitted Methods . . . . . . . . . . . . . . . . . . . . 15 5.4. Admitted Methods . . . . . . . . . . . . . . . . . . . . 15
5.5. Operations Supported by Clients . . . . . . . . . . . . . 16 5.5. Operations Supported by Clients . . . . . . . . . . . . . 16
6. Token Transferring and Group Joining . . . . . . . . . . . . 17 6. Token Transferring and Group Joining . . . . . . . . . . . . 17
6.1. Token Transferring . . . . . . . . . . . . . . . . . . . 17 6.1. Token Transferring . . . . . . . . . . . . . . . . . . . 18
6.1.1. 'ecdh_info' Parameter . . . . . . . . . . . . . . . . 20 6.1.1. 'ecdh_info' Parameter . . . . . . . . . . . . . . . . 20
6.1.2. 'gm_dh_pub_keys' Parameter . . . . . . . . . . . . . 22 6.1.2. 'kdc_dh_creds' Parameter . . . . . . . . . . . . . . 23
6.2. Send the Joining Request . . . . . . . . . . . . . . . . 24 6.2. Send the Joining Request . . . . . . . . . . . . . . . . 24
6.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 25 6.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 26
6.3. Receive the Joining Request . . . . . . . . . . . . . . . 26 6.3. Receive the Joining Request . . . . . . . . . . . . . . . 26
6.4. Send the Joining Response . . . . . . . . . . . . . . . . 29 6.4. Send the Joining Response . . . . . . . . . . . . . . . . 30
6.5. Receive the Joining Response . . . . . . . . . . . . . . 35 6.5. Receive the Joining Response . . . . . . . . . . . . . . 36
7. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 37 7. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 38
8. Retrieve of Updated Keying Material . . . . . . . . . . . . . 39 8. Retrieve of Updated Keying Material . . . . . . . . . . . . . 40
8.1. Retrieve of Group Keying Material . . . . . . . . . . . . 39 8.1. Retrieve of Group Keying Material . . . . . . . . . . . . 40
8.2. Retrieve of Group Keying Material and OSCORE Sender ID . 39 8.2. Retrieve of Group Keying Material and OSCORE Sender ID . 41
9. Request to Change Individual Keying Material . . . . . . . . 40 9. Request to Change Individual Keying Material . . . . . . . . 41
10. Retrieve Public Keys of Group Members . . . . . . . . . . . . 42 10. Retrieve Authentication Credentials of Group Members . . . . 43
11. Upload a New Public Key . . . . . . . . . . . . . . . . . . . 42 11. Upload a New Authentication Credential . . . . . . . . . . . 44
12. Retrieve the Group Manager's Public Key . . . . . . . . . . . 44 12. Retrieve the Group Manager's Authentication Credential . . . 45
13. Retrieve Signature Verification Data . . . . . . . . . . . . 44 13. Retrieve Signature Verification Data . . . . . . . . . . . . 46
14. Retrieve the Group Policies . . . . . . . . . . . . . . . . . 46 14. Retrieve the Group Policies . . . . . . . . . . . . . . . . . 48
15. Retrieve the Keying Material Version . . . . . . . . . . . . 47 15. Retrieve the Keying Material Version . . . . . . . . . . . . 49
16. Retrieve the Group Status . . . . . . . . . . . . . . . . . . 47 16. Retrieve the Group Status . . . . . . . . . . . . . . . . . . 49
17. Retrieve Group Names . . . . . . . . . . . . . . . . . . . . 48 17. Retrieve Group Names . . . . . . . . . . . . . . . . . . . . 50
18. Leave the Group . . . . . . . . . . . . . . . . . . . . . . . 51 18. Leave the Group . . . . . . . . . . . . . . . . . . . . . . . 53
19. Removal of a Group Member . . . . . . . . . . . . . . . . . . 51 19. Removal of a Group Member . . . . . . . . . . . . . . . . . . 53
20. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 52 20. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 55
20.1. Sending Rekeying Messages . . . . . . . . . . . . . . . 54 20.1. Sending Rekeying Messages . . . . . . . . . . . . . . . 57
20.2. Receiving Rekeying Messages . . . . . . . . . . . . . . 56 20.2. Receiving Rekeying Messages . . . . . . . . . . . . . . 59
20.3. Missed Rekeying Instances . . . . . . . . . . . . . . . 57 20.3. Missed Rekeying Instances . . . . . . . . . . . . . . . 60
20.3.1. Retrieval of Stale Sender IDs . . . . . . . . . . . 59 20.3.1. Retrieval of Stale Sender IDs . . . . . . . . . . . 62
21. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 61 21. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 64
22. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 63 22. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 66
23. Default Values for Group Configuration Parameters . . . . . . 63 23. Default Values for Group Configuration Parameters . . . . . . 66
23.1. Common . . . . . . . . . . . . . . . . . . . . . . . . . 64 23.1. Common . . . . . . . . . . . . . . . . . . . . . . . . . 67
23.2. Group Mode . . . . . . . . . . . . . . . . . . . . . . . 64 23.2. Group Mode . . . . . . . . . . . . . . . . . . . . . . . 67
23.3. Pairwise Mode . . . . . . . . . . . . . . . . . . . . . 65 23.3. Pairwise Mode . . . . . . . . . . . . . . . . . . . . . 68
24. Security Considerations . . . . . . . . . . . . . . . . . . . 66 24. Security Considerations . . . . . . . . . . . . . . . . . . . 69
24.1. Management of OSCORE Groups . . . . . . . . . . . . . . 66 24.1. Management of OSCORE Groups . . . . . . . . . . . . . . 69
24.2. Size of Nonces as Proof-of-Possesion Challenge . . . . . 67 24.2. Size of Nonces as Proof-of-Possesion Challenge . . . . . 70
24.3. Reusage of Nonces for Proof-of-Possession Input . . . . 68 24.3. Reusage of Nonces for Proof-of-Possession Input . . . . 71
25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
25.1. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 69 25.1. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 72
25.2. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 69 25.2. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 72
25.3. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 70 25.3. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 73
25.4. ACE Groupcomm Key Types . . . . . . . . . . . . . . . . 71 25.4. ACE Groupcomm Key Types . . . . . . . . . . . . . . . . 74
25.5. ACE Groupcomm Profiles . . . . . . . . . . . . . . . . . 71 25.5. ACE Groupcomm Profiles . . . . . . . . . . . . . . . . . 74
25.6. OSCORE Security Context Parameters . . . . . . . . . . . 71 25.6. OSCORE Security Context Parameters . . . . . . . . . . . 74
25.7. TLS Exporter Labels . . . . . . . . . . . . . . . . . . 73 25.7. TLS Exporter Labels . . . . . . . . . . . . . . . . . . 76
25.8. AIF . . . . . . . . . . . . . . . . . . . . . . . . . . 74 25.8. AIF . . . . . . . . . . . . . . . . . . . . . . . . . . 77
25.9. Media Type Registrations . . . . . . . . . . . . . . . . 74 25.9. CoAP Content-Format . . . . . . . . . . . . . . . . . . 77
25.10. CoAP Content-Format . . . . . . . . . . . . . . . . . . 75 25.10. Group OSCORE Roles . . . . . . . . . . . . . . . . . . . 78
25.11. Group OSCORE Roles . . . . . . . . . . . . . . . . . . . 75 25.11. CoRE Resource Type . . . . . . . . . . . . . . . . . . . 78
25.12. CoRE Resource Type . . . . . . . . . . . . . . . . . . . 76 25.12. ACE Scope Semantics . . . . . . . . . . . . . . . . . . 79
25.13. ACE Scope Semantics . . . . . . . . . . . . . . . . . . 76 25.13. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 79
25.14. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 77 25.14. Expert Review Instructions . . . . . . . . . . . . . . . 80
25.15. Expert Review Instructions . . . . . . . . . . . . . . . 77 26. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
26. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 26.1. Normative References . . . . . . . . . . . . . . . . . . 80
26.1. Normative References . . . . . . . . . . . . . . . . . . 78 26.2. Informative References . . . . . . . . . . . . . . . . . 84
26.2. Informative References . . . . . . . . . . . . . . . . . 82 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 86
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 83 A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 86
A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 83 A.2. Optional-to-Address Requirements . . . . . . . . . . . . 89
A.2. Optional-to-Address Requirements . . . . . . . . . . . . 86 Appendix B. Extensibility for Future COSE Algorithms . . . . . . 90
Appendix B. Extensibility for Future COSE Algorithms . . . . . . 88 B.1. Format of 'ecdh_info_entry' . . . . . . . . . . . . . . . 91
B.1. Format of 'ecdh_info_entry' . . . . . . . . . . . . . . . 89 B.2. Format of 'key' . . . . . . . . . . . . . . . . . . . . . 92
B.2. Format of 'key' . . . . . . . . . . . . . . . . . . . . . 89 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 93
Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 90 C.1. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 93
C.1. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 90 C.2. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 93
C.2. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 91 C.3. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 94
C.3. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 92 C.4. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 95
C.4. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 93 C.5. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 95
C.5. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 93 C.6. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 96
C.6. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 94 C.7. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 96
C.7. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 94 C.8. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 96
C.8. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 95 C.9. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 97
C.9. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 95 C.10. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 98
C.10. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 96 C.11. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 98
C.11. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 96 C.12. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 99
C.12. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 97 C.13. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 99
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
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.
skipping to change at page 5, line 34 skipping to change at page 5, line 34
communication for CoAP [I-D.ietf-core-groupcomm-bis]. Unless communication for CoAP [I-D.ietf-core-groupcomm-bis]. Unless
otherwise indicated, the term "endpoint" is used here following otherwise indicated, the term "endpoint" is used here following
its OAuth definition, aimed at denoting resources such as /token its OAuth definition, aimed at denoting resources such as /token
and /introspect at the AS, and /authz-info at the RS. This and /introspect at the AS, and /authz-info at the RS. This
document does not use the CoAP definition of "endpoint", which is document does not use the CoAP definition of "endpoint", which is
"An entity participating in the CoAP protocol". "An entity participating in the CoAP protocol".
* The terms and concepts for protection and processing of CoAP * The terms and concepts for protection and processing of CoAP
messages through OSCORE [RFC8613] and through Group OSCORE messages through OSCORE [RFC8613] and through Group OSCORE
[I-D.ietf-core-oscore-groupcomm] in group communication scenarios. [I-D.ietf-core-oscore-groupcomm] in group communication scenarios.
These include the concept of Group Manager, as the entity These especially include:
responsible for a set of groups where communications are secured
with Group OSCORE. In this document, the Group Manager acts as - Group Manager, as the entity responsible for a set of groups
Resource Server. where communications are secured with Group OSCORE. In this
document, the Group Manager acts as Resource Server.
- Authentication credential, as the set of information associated
with an entity, including that entity's public key and
parameters associated with the public key. Examples of
authentication credentials are CBOR Web Tokens (CWTs) and CWT
Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] and
C509 certificates [I-D.ietf-cose-cbor-encoded-cert].
Additionally, this document makes use of the following terminology. Additionally, this document makes use of the following terminology.
* Requester: member of an OSCORE group that sends request messages * Requester: member of an OSCORE group that sends request messages
to other members of the group. to other members of the group.
* Responder: member of an OSCORE group that receives request * Responder: member of an OSCORE group that receives request
messages from other members of the group. A responder may reply messages from other members of the group. A responder may reply
back, by sending a response message to the requester which has back, by sending a response message to the requester which has
sent the request message. sent the request message.
skipping to change at page 6, line 10 skipping to change at page 6, line 20
* Monitor: member of an OSCORE group that is configured as responder * Monitor: member of an OSCORE group that is configured as responder
and never replies back to requesters after receiving request and never replies back to requesters after receiving request
messages. This corresponds to the term "silent server" used in messages. This corresponds to the term "silent server" used in
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
* Signature verifier: entity external to the OSCORE group and * Signature verifier: entity external to the OSCORE group and
intended to verify the signature of messages exchanged in the intended to verify the signature of messages exchanged in the
group (see Sections 3.1 and 8.5 of group (see Sections 3.1 and 8.5 of
[I-D.ietf-core-oscore-groupcomm]). An authorized signature [I-D.ietf-core-oscore-groupcomm]). An authorized signature
verifier does not join the OSCORE group as an actual member, yet verifier does not join the OSCORE group as an actual member, yet
it can retrieve the public keys of the current group members from it can retrieve the authentication credentials of the current
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 over IP multicast has been enabled in
skipping to change at page 6, line 43 skipping to change at page 7, line 5
is specifically an OSCORE group. is 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 to the Group Manager is the * The Authorization Server associated with the Group Manager is the
AS. AS.
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.
skipping to change at page 8, line 14 skipping to change at page 8, line 19
Note that the Gid differs from the group name also introduced in Note that the Gid differs from the group name also introduced in
[I-D.ietf-ace-key-groupcomm], which is a plain, stable and [I-D.ietf-ace-key-groupcomm], which is a plain, stable and
invariant identifier, with no cryptographic relevance and meaning. invariant identifier, with no cryptographic relevance and meaning.
* A new value for the Master Secret parameter of the Group OSCORE * A new value for the Master Secret parameter of the Group OSCORE
Common Security Context of the group (see Section 2 of Common Security Context of the group (see Section 2 of
[I-D.ietf-core-oscore-groupcomm]). [I-D.ietf-core-oscore-groupcomm]).
* A set of stale Sender IDs, which allows each rekeyed node to purge * A set of stale Sender IDs, which allows each rekeyed node to purge
public keys and Recipient Contexts used in the group and authentication credentials and Recipient Contexts used in the
associated to those Sender IDs. This in turn allows every group group and associated with those Sender IDs. This in turn allows
member to rely on owned public keys to confidently assert the every group member to rely on stored authentication credentials to
group membership of other sender nodes, when receiving protected confidently assert the group membership of other sender nodes,
messages in the group (see Section 3.2 of when receiving protected messages in the group (see Section 3.2 of
[I-D.ietf-core-oscore-groupcomm]). More details on the [I-D.ietf-core-oscore-groupcomm]). More details on the
maintenance of stale Sender IDs are provided in Section 2.2.1. maintenance of stale Sender IDs are provided in Section 2.2.1.
Also, the data distributed through a group rekeying MAY include a new Also, the data distributed through a group rekeying MAY include a new
value for the Master Salt parameter of the Group OSCORE Common value for the Master Salt parameter of the Group OSCORE Common
Security Context of that group. Security Context of that group.
The Group Manager MUST rekeying the group in the following cases. The Group Manager MUST rekeying the group in the following cases.
* The application requires backward security - In this case, the * The application requires backward security - In this case, the
skipping to change at page 8, line 43 skipping to change at page 8, line 48
* One or more nodes leave the group - That is, the group is rekeyed * One or more nodes leave the group - That is, the group is rekeyed
when one or more current members spontaneously request to leave when one or more current members spontaneously request to leave
the group (see Section 18), or when the Group Manager forcibly the group (see Section 18), or when the Group Manager forcibly
evicts them from the group, e.g., due to expired or revoked evicts them from the group, e.g., due to expired or revoked
authorization (see Section 19). Therefore, a leaving node cannot authorization (see Section 19). Therefore, a leaving node cannot
access communications in the group after its leaving, thus access communications in the group after its leaving, thus
ensuring forward security in the group. ensuring forward security in the group.
Due to the set of stale Sender IDs distributed through the Due to the set of stale Sender IDs distributed through the
rekeying, this ensures that a node owning the latest group keying rekeying, this ensures that a node owning the latest group keying
material does not store the public keys of former group members material does not store the authentication credentials of former
(see Sections 3.2 and 10.1 of [I-D.ietf-core-oscore-groupcomm]). 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 * Extension of group lifetime - That is, the group is rekeyed when
the expiration time for the group keying material approaches or the expiration time for the group keying material approaches or
has passed, if it is appropriate to extend the group operation has passed, if it is appropriate to extend the group operation
beyond that. beyond that.
The Group Manager MAY rekey the group for other reasons, e.g., The Group Manager MAY rekey the group for other reasons, e.g.,
according to an application-dependent rekeying period or scheduling. according to an application-dependent rekeying period or scheduling.
2.2.1. Stale OSCORE Sender IDs 2.2.1. Stale OSCORE Sender IDs
Throughout the lifetime of every group, the Group Manager MUST Throughout the lifetime of every group, the Group Manager MUST
maintain a collection of stale Sender IDs for that group. maintain a collection of stale Sender IDs for that group.
The collection associated to a group MUST include up to N > 1 ordered The collection associated with a group MUST include up to N > 1
sets of stale OSCORE Sender IDs. It is up to the application to ordered sets of stale OSCORE Sender IDs. It is up to the application
specify the value of N, possibly on a per-group basis. 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 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 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 refers to the immediately previous version (V - 1) of the group
keying material, and so on. keying material, and so on.
In the following cases, the Group Manager MUST add a new element to In the following cases, the Group Manager MUST add a new element to
the most recent set X, i.e., the set associated to the current the most recent set X, i.e., the set associated with the current
version V of the group keying material. version V of the group keying material.
* When a current group member obtains a new Sender ID, its old * When a current group member obtains a new Sender ID, its old
Sender ID is added to X. This happens when the Group Manager Sender ID is added to X. This happens when the Group Manager
assigns a new Sender ID upon request from the group member (see 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 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. 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 * When a current group member leaves the group, its current Sender
ID is added to X. This happens when a group member requests to ID is added to X. This happens when a group member requests to
skipping to change at page 9, line 44 skipping to change at page 10, line 6
The value of N can change throughout the lifetime of the group. If 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 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 the (up to) N' most recent sets in the collection and MUST delete any
possible older set from the collection. possible older set from the collection.
Finally, the Group Manager MUST perform the following actions, when Finally, the Group Manager MUST perform the following actions, when
the group is rekeyed and the group shifts to the next version V' = (V the group is rekeyed and the group shifts to the next version V' = (V
+ 1) of the group keying material. + 1) of the group keying material.
1. The Group Manager rekeys the group. This includes also 1. The Group Manager rekeys the group. This includes also
distributing the set of stale Sender IDs X associated to the old distributing the set of stale Sender IDs X associated with the
group keying material with version V (see Section 2.2). old group keying material with version V (see Section 2.2).
2. After completing the group rekeying, the Group Manager creates a 2. After completing the group rekeying, the Group Manager creates a
new empty set X' associated to the new version V' of the newly new empty set X' associated with the new version V' of the newly
established group keying material, i.e., V' = (V + 1). established group keying material, i.e., V' = (V + 1).
3. If the current collection of stale Sender IDs has size N, the 3. If the current collection of stale Sender IDs has size N, the
Group Manager deletes the oldest set in the collection. Group Manager deletes the oldest set in the collection.
4. The Group Manager adds the new set X' to the collection of stale 4. The Group Manager adds the new set X' to the collection of stale
Sender IDs, as the most recent set. Sender IDs, as the most recent set.
3. Format of Scope 3. Format of Scope
skipping to change at page 10, line 37 skipping to change at page 10, line 48
* the object identifier ("Toid") is specialized as a CBOR text * the object identifier ("Toid") is specialized as a CBOR text
string, specifying the group name for the scope entry; string, specifying the group name for the scope entry;
* the permission set ("Tperm") is specialized as a CBOR unsigned * the permission set ("Tperm") is specialized as a CBOR unsigned
integer with value R, specifying the role(s) that the client integer with value R, specifying the role(s) that the client
wishes to take in the group (REQ1). The value R is computed as wishes to take in the group (REQ1). The value R is computed as
follows: follows:
- each role in the permission set is converted into the - 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 table in Figure 1. the "Group OSCORE Roles" registry, for which this document
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 each numeric identifier X_1, X_2, ..., X_N to the power
of two, and then computing the inclusive OR of the binary of two, 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 |
skipping to change at page 11, line 24 skipping to change at page 11, line 29
| 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 the OSCORE group
The CDDL [RFC8610] definition of the AIF-OSCORE-GROUPCOMM data model The CDDL [RFC8610] definition of the AIF-OSCORE-GROUPCOMM data model
is as follows: is as follows:
AIF-OSCORE-GROUPCOMM = AIF_Generic<path, permissions> AIF-OSCORE-GROUPCOMM = AIF-Generic<gname, permissions>
path = tstr ; Group name gname = tstr ; Group name
permissions = uint . bits roles permissions = uint . bits roles
roles = &( 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 Future specifications that define new roles MUST register a
corresponding numeric identifier in the "Group OSCORE Roles" registry corresponding numeric identifier in the "Group OSCORE Roles" registry
defined in Section 25.11 of this document. defined in Section 25.10 of this document.
4. Joining Node to Authorization Server 4. Joining Node to Authorization Server
This section describes how the joining node interacts with the AS in This section describes how the joining node interacts with the AS in
order to be authorized to join an OSCORE group under a given Group order to be authorized to join an OSCORE group under a given Group
Manager. In particular, it considers a joining node that intends to Manager. In particular, it considers a joining node that intends to
contact that Group Manager for the first time. contact that Group Manager for the first time.
The message exchange between the joining node and the AS consists of The message exchange between the joining node and the AS consists of
the messages Authorization Request and Authorization Response defined the messages Authorization Request and Authorization Response defined
skipping to change at page 12, line 19 skipping to change at page 12, line 25
* 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, computed as defined in Section 3 from the unsigned integer. This is computed as defined in Section 3,
numerical abbreviations defined in Figure 1 for each from the numerical abbreviations of each requested role
requested role (REQ1). defined in the "Group OSCORE Roles" registry, for which this
document defines the entry in Figure 1 (REQ1).
4.2. Authorization Response 4.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.
skipping to change at page 12, line 43 skipping to change at page 13, line 9
in the Access Token differs from the one specified by the joining in the Access Token differs from the one specified by the joining
node in the request. In such a case, the second element of each node in the request. In such a case, the second element of each
scope entry MUST be present, and specifies the set of roles that scope entry MUST be present, and specifies the set of roles that
the joining node is actually authorized to take in the OSCORE the joining node is actually authorized to take in the OSCORE
group for that scope entry, encoded as specified in Section 4.1. group for that scope entry, encoded as specified in Section 4.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.13 of this document (REQ28). This indicates that the Section 25.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. Interface at the Group Manager
The Group Manager provides the interface defined in Section 4.1 of The Group Manager provides the interface defined in Section 4.1 of
[I-D.ietf-ace-key-groupcomm], with the additional sub-resources [I-D.ietf-ace-key-groupcomm], with the additional sub-resources
defined from Section 5.1 to Section 5.3 of this document. defined from Section 5.1 to Section 5.3 of this document.
Furthermore, Section 5.4 provides a summary of the CoAP methods Furthermore, Section 5.4 provides a summary of the CoAP methods
admitted to access different resources at the Group Manager, for admitted to access different resources at the Group Manager, for
nodes with different roles in the group or as non members (REQ11). 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 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' 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). in Section 3.1 of [I-D.ietf-ace-key-groupcomm]) (REQ7).
The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is
registered in Section 25.12 (REQ10), and can be used to describe registered in Section 25.11 (REQ10), and can be used to describe
group-membership resources and its sub-resources at a Group Manager, group-membership resources and its sub-resources at a Group Manager,
e.g., by using a link-format document [RFC6690]. e.g., by using a link-format document [RFC6690].
Applications can use this common resource type to discover links to Applications can use this common resource type to discover links to
group-membership resources for joining OSCORE groups, e.g., by using group-membership resources for joining OSCORE groups, e.g., by using
the approach described in [I-D.tiloca-core-oscore-discovery]. the approach described in [I-D.tiloca-core-oscore-discovery].
5.1. ace-group/GROUPNAME/active 5.1. ace-group/GROUPNAME/active
This resource implements a GET handler. This resource implements a GET handler.
skipping to change at page 15, line 17 skipping to change at page 15, line 23
requesting client is a current member of the group. If the requesting client is a current member of the group. If the
verification fails, the Group Manager MUST reply with a 4.03 verification fails, the Group Manager MUST reply with a 4.03
(Forbidden) error response. The response MUST have Content-Format (Forbidden) error response. 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 0 ("Operation permitted only to group 'error' field MUST be set to 0 ("Operation permitted only to group
members"). members").
If all verifications succeed, the handler replies with a 2.05 If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allows the requesting client (Content) response, specifying data that allows the requesting client
to delete the Recipient Contexts and public keys associated to former to delete the Recipient Contexts and authentication credentials
members of the group (see Section 3.2 of associated with former members of the group (see Section 3.2 of
[I-D.ietf-core-oscore-groupcomm]. The payload of the response is [I-D.ietf-core-oscore-groupcomm]. The payload of the response is
formatted as defined in Section 20.3.1. formatted as defined in Section 20.3.1.
5.4. Admitted Methods 5.4. Admitted Methods
The table in Figure 2 summarizes the CoAP methods admitted to access The table in Figure 2 summarizes the CoAP methods admitted to access
different resources at the Group Manager, for (non-)members of a different resources at the Group Manager, for (non-)members of a
group with group name GROUPNAME, and considering different roles. group with group name GROUPNAME, and considering different roles.
The last two rows of the table apply to a node with node name The last two rows of the table apply to a node with node name
NODENAME. NODENAME.
skipping to change at page 17, line 14 skipping to change at page 17, line 14
* GET request to ace-group/GROUPNAME/verif-data , in order for a * GET request to ace-group/GROUPNAME/verif-data , in order for a
signature verifier to retrieve data required to verify signatures signature verifier to retrieve data required to verify signatures
of messages protected with the group mode of Group OSCORE and sent of messages protected with the group mode of Group OSCORE and sent
to a group (see Sections 3.1 and 8.5 of to a group (see Sections 3.1 and 8.5 of
[I-D.ietf-core-oscore-groupcomm]). Note that this operation is [I-D.ietf-core-oscore-groupcomm]). Note that this operation is
relevant to support only to signature verifiers. relevant to support only to signature verifiers.
* FETCH request to ace-group/GROUPNAME/stale-sids , in order to * FETCH request to ace-group/GROUPNAME/stale-sids , in order to
retrieve from the Group Manager the data required to delete some retrieve from the Group Manager the data required to delete some
of the stored group members' public keys and Recipient Contexts of the stored group members' authentication credentials and
(see Section 5.3.1). This data is provided as an aggregated set Recipient Contexts (see Section 5.3.1). This data is provided as
of stale Sender IDs, which are used as specified in Section 20.3. an aggregated set of stale Sender IDs, which are used as specified
in Section 20.3.
6. Token Transferring and Group Joining 6. Token Transferring and Group Joining
The rest of this section describes the interactions between the The rest of this section describes the interactions between the
joining node and the Group Manager, i.e., the transferring of the joining node and the Group Manager, i.e., the transferring of the
Access Token to the Group Manager and the Request-Response exchange Access Token to the Group Manager and the Request-Response exchange
to join the OSCORE group. The message exchange between the joining to join the OSCORE group. The message exchange between the joining
node and the Group Manager consists of the messages defined in 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 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 what is defined in [I-D.ietf-ace-key-groupcomm] applies, and only
skipping to change at page 18, line 10 skipping to change at page 18, line 16
The exchange of Token Transfer Request and Response is defined in The exchange of Token Transfer Request and Response is defined in
Section 3.3 of [I-D.ietf-ace-key-groupcomm]. In addition to that, Section 3.3 of [I-D.ietf-ace-key-groupcomm]. In addition to that,
the following applies. 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): (OPT2):
- 'ecdh_info' defined in Section 6.1.1 of this document, with - 'ecdh_info' defined in Section 6.1.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 parameters, the ECDH key parameters and about the exact format
encoding of public keys used in the groups that the client has of authentication credentials used in the groups that the
been authorized to join. This is relevant in case the joining client has been authorized to join. This is relevant in case
node supports the pairwise mode of Group OSCORE the joining node supports the pairwise mode of Group OSCORE
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
- 'gm_dh_pub_keys' defined in Section 6.1.2 of this document, - 'kdc_dh_creds' defined in Section 6.1.2 of this document, with
with value the CBOR simple value 'null' (0xf6) to request the value the CBOR simple value "null" (0xf6) to request the
Diffie-Hellman public keys of the Group Manager in the groups Diffie-Hellman authentication credentials of the Group Manager
that the client has been authorized to join. This is relevant for the groups that the client has been authorized to join.
in case the joining node supports the pairwise mode of Group That is, each of such authentication credentials includes a
OSCORE [I-D.ietf-core-oscore-groupcomm]. Diffie-Hellman public key of the Group Manager. This is
relevant in case the joining node supports the pairwise mode of
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.2).
skipping to change at page 19, line 21 skipping to change at page 19, line 24
- 'sign_key_parameters' is a CBOR array. Its format and value - 'sign_key_parameters' is a CBOR array. Its format and value
are the same of the COSE capabilities array for the COSE key are the same 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
'sign_alg', as specified for that key type in the '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] (REQ5). [COSE.Key.Types] (REQ5).
- 'pub_key_enc' takes value from the "Label" column of the "COSE - 'pub_key_enc' takes value from the "Label" column of the "COSE
Header 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 an [I-D.ietf-core-oscore-groupcomm], acceptable values denote a
encoding that MUST explicitly provide the full set of format of authentication credential that MUST explicitly
provide the public key as well as the comprehensive set of
information related to the public key algorithm, including, information related to the public key algorithm, including,
e.g., the used elliptic curve (when applicable). e.g., the used elliptic curve (when applicable).
At the time of writing this specification, acceptable public At the time of writing this specification, acceptable formats
key encodings are CBOR Web Tokens (CWTs) and CWT Claims Sets of authentication credentials are CBOR Web Tokens (CWTs) and
(CCSs) [RFC8392], X.509 certificates [RFC7925] and C509 CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925]
certificates [I-D.ietf-cose-cbor-encoded-cert]. Further and C509 certificates [I-D.ietf-cose-cbor-encoded-cert].
encodings may be available in the future, and would be Further formats may be available in the future, and would be
acceptable to use as long as they comply with the criteria acceptable to use as long as they comply with the criteria
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. ]
skipping to change at page 20, line 8 skipping to change at page 20, line 12
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 6.1.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 NOT include the 'ecdh_info' parameter As an exception, the KDC MAY omit the 'ecdh_info' parameter in the
in the Token Transfer Response even if 'ecdh_info' is included in Token Transfer Response even if 'ecdh_info' is included in the
the Token Transfer Request, in case all the groups that the Client Token Transfer Request, in case all the groups that the Client is
is authorized to join are signature-only groups. authorized to join are signature-only groups.
* If 'gm_dh_pub_keys' 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
'gm_dh_pub_keys' 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 the format defined in Section 6.1.2. Otherwise, if 'kdc_dh_creds'
'gm_dh_pub_keys' is included in the Token Transfer Request, the is included in the Token Transfer Request, the Group Manager MAY
Group Manager MAY include the 'gm_dh_pub_keys' parameter in the include the 'kdc_dh_creds' parameter in the Token Transfer
Token Transfer Response. Note that the field 'id' specifies the Response. Note that the field 'id' specifies the group name, or
group name, or array of group names, for which the corresponding array of group names, for which the corresponding 'kdc_dh_creds'
'gm_dh_pub_keys' 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 6.1.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 and about public keys to accordingly use for about an ECDH algorithm as well as about the authentication
deriving Diffie-Hellman secrets. Its exact semantics and content are credentials and public keys to accordingly use for deriving Diffie-
application specific. Hellman secrets. Its exact semantics and content are application
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 and about public keys to be used information about the ECDH algorithm as well as about the
with it, in the groups indicated by the transferred Acces Token as authentication credentials and public keys to be used with it, in the
per its 'scope' claim (see Section 3.2 of groups indicated by the transferred Acces Token as per its 'scope'
[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
and about the public keys to be used to compute static-static Diffie- as well as about the authentication credentials and public keys to be
Hellman shared secrets [NIST-800-56A], in the OSCORE groups that the used to compute static-static Diffie-Hellman shared secrets
client has been authorized to join and that use the pairwise mode of [NIST-800-56A], in the OSCORE groups that the client has been
Group OSCORE [I-D.ietf-core-oscore-groupcomm]. authorized to join and that use the pairwise mode of Group OSCORE
[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 and about Each element contains information about ECDH parameters as well as
public keys, for one or more OSCORE groups that use the pairwise mode about authentication credentials and public keys, for one or more
of Group OSCORE and that the client has been authorized to join. OSCORE groups that use the pairwise mode of Group OSCORE and that the
Each element is formatted as follows. client 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 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
of the "COSE Algorithms" registry [COSE.Algorithms]. of the "COSE Algorithms" registry [COSE.Algorithms].
skipping to change at page 21, line 49 skipping to change at page 22, line 8
* The fourth element 'ecdh_key_parameters' is a CBOR array * The fourth element 'ecdh_key_parameters' is a CBOR array
indicating the parameters of the keys used with the ECDH algorithm indicating the parameters of the keys used with the ECDH algorithm
in the OSCORE group identified by 'gname'. Its content depends on in the OSCORE group identified by 'gname'. Its content depends on
the value of 'ecdh_alg'. In particular, its format and value are the value of 'ecdh_alg'. In particular, its format and value are
the same of the COSE capabilities array for the COSE key type of the same of the COSE capabilities array for the COSE key type of
the keys used with the algorithm indicated in 'ecdh_alg', as the keys used with the algorithm indicated in 'ecdh_alg', as
specified for that key type in the "Capabilities" column of the specified for that key type in the "Capabilities" column of the
"COSE Key Types" registry [COSE.Key.Types]. "COSE Key Types" registry [COSE.Key.Types].
* The fifth element 'pub_key_enc' is a CBOR integer indicating the * The fifth element 'cred_fmt' is a CBOR integer indicating the
encoding of public keys used in the OSCORE group identified by format of authentication credentials used in the OSCORE group
'gname'. It takes value from the "Label" column of the "COSE identified by 'gname'. It takes value from the "Label" column of
Header Parameters" registry [COSE.Header.Parameters] (REQ6). the "COSE Header Parameters" registry [COSE.Header.Parameters]
(REQ6). Acceptable values denote a format that MUST provide the
Acceptable values denote an encoding that MUST explicitly provide public key as well as the comprehensive set of information related
the full set of information related to the public key algorithm, to the public key algorithm, including, e.g., the used elliptic
including, e.g., the used elliptic curve (when applicable). The curve (when applicable). The same considerations and guidelines
same considerations and guidelines for the 'pub_key_enc' element for the 'pub_key_enc' element of 'sign_info' (see Section 6.1)
of 'sign_info' (see Section 6.1) apply. apply.
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 = nil ; in the Token Transfer ecdh_info_req = null ; in the Token Transfer
; Request to the KDC ; Request to the KDC
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 KDC
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 ],
pub_key_enc = 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. 'gm_dh_pub_keys' Parameter 6.1.2. 'kdc_dh_creds' Parameter
The 'gm_dh_pub_keys' parameter is an OPTIONAL parameter of the The 'kdc_dh_creds' parameter is an OPTIONAL parameter of the request
request and response messages exchanged between the Client and the and response messages exchanged between the Client and the authz-info
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 public keys of the RS. Hellman authentication credentials of the RS, i.e., authentication
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 public keys to retrieve from the Group Manager its Diffie-Hellman authentication
use, in the OSCORE groups that the client has been authorized to credentials to use, in the OSCORE groups that the client has been
join. The Group Manager has specifically a Diffie-Hellman public key authorized to join. The Group Manager has specifically a Diffie-
in an OSCORE group, if and only if the group is a pairwise-only Hellman authentication credential in an OSCORE group, and thus a
group. In this case, the early retrieval of the Group Manager's Diffie-Hellman public key in that group, if and only if the group is
public key is necessary in order for the joining node to prove the a pairwise-only group. In this case, the early retrieval of the
possession of its own private key, upon joining the group (see Group Manager's authentication credential is necessary in order for
Section 6.2). the joining node to prove the possession of its own private key, upon
joining the group (see Section 6.2).
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 'gm_dh_pub_keys' 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 public keys that (0xf6). This is done to ask for the Diffie-Hellman authentication
the Group Manager uses in the OSCORE groups that the client has been credentials that the Group Manager uses in the OSCORE groups that the
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 'gm_dh_pub_keys' parameter is a CBOR array of one or Manager, the 'kdc_dh_creds' parameter is a CBOR array of one or more
more elements. The number of elements is at most the number of elements. The number of elements is at most the number of OSCORE
OSCORE groups that the client has been authorized to join. groups that the client has been authorized to join.
Each element 'gm_dh_pub_keys_entry' contains information about the Each element 'kdc_dh_creds_entry' contains information about the
Group Manager's Diffie-Hellman public keys, for one or more OSCORE Group Manager's Diffie-Hellman authentication credentials, for one or
groups that are pairwise-only groups and that the client has been more OSCORE groups that are pairwise-only groups and that the client
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 'pub_key_enc' is a CBOR integer indicating the * The second element 'cred_fmt' is a CBOR integer indicating the
encoding of public keys used in the OSCORE group identified by format of authentication credentials used in the OSCORE group
'gname'. It takes value from the "Label" column of the "COSE identified by 'gname'. It takes value from the "Label" column of
Header Parameters" registry [COSE.Header.Parameters] (REQ6). the "COSE Header Parameters" registry [COSE.Header.Parameters]
Acceptable values denote an encoding that MUST explicitly provide (REQ6). Acceptable values denote a format that MUST explicitly
the full set of information related to the public key algorithm, provide the public key as well as comprehensive set of information
including, e.g., the used elliptic curve (when applicable). The related to the public key algorithm, including, e.g., the used
same considerations and guidelines for the 'pub_key_enc' element elliptic curve (when applicable). The same considerations and
of 'sign_info' (see Section 6.1) apply. guidelines for the 'pub_key_enc' element of 'sign_info' (see
Section 6.1) apply.
* The third element 'pub_key' is a CBOR byte string, which encodes * The third element 'cred' is a CBOR byte string, which encodes the
the Group Manager's Diffie-Hellman public key in its original Group Manager's Diffie-Hellman authentication credential in its
binary representation made available to other endpoints in the original binary representation made available to other endpoints
group. In particular, the original binary representation complies in the group. In particular, the original binary representation
with the encoding specified by the 'pub_key_enc' parameter. Note complies with the format specified by the 'cred_fmt' element.
that the public key provides the full set of information related Note that the authentication credential provides the comprehensive
to its public key algorithm, i.e., the ECDH algorithm used in the set of information related to its public key algorithm, i.e., the
OSCORE group as pairwise key agreement algorithm. ECDH algorithm used in the OSCORE group as pairwise key agreement
algorithm.
The CDDL notation [RFC8610] of the 'gm_dh_pub_keys' parameter is The CDDL notation [RFC8610] of the 'kdc_dh_creds' parameter is given
given below. below.
gm_dh_pub_keys = gm_dh_pub_keys_req / gm_dh_pub_keys_resp kdc_dh_creds = kdc_dh_creds_req / kdc_dh_creds_resp
gm_dh_pub_keys_req = nil ; in the Token kdc_dh_creds_req = null ; in the Token Transfer
; Transfer Request to ; Request to the
; the Group Manager ; Group Manager
gm_dh_pub_keys_res = [ + gm_dh_pub_keys_entry ] ; in the Token kdc_dh_creds_res = [ + kdc_dh_creds_entry ] ; in the Token Transfer
; Transfer Response ; Response from the
; from the Group ; Group Manager
; Manager
gm_dh_pub_keys_entry = kdc_dh_creds_entry =
[ [
id : gname / [ + gname ], id : gname / [ + gname ],
pub_key_enc = int, cred_fmt = int,
pub_key = bstr cred = bstr
] ]
gname = tstr gname = tstr
6.2. Send the Joining Request 6.2. 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 defined in Section 4.3.1 of Additionally to what defined in Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm], the following applies. [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 public keys of the group members from the wants to retrieve the authentication credentials of the group
Group Manager during the joining process (see Section 7). members from the Group Manager during the joining process (see
Otherwise, this parameter MUST NOT be present. Section 7). Otherwise, this parameter MUST NOT be present.
If this parameter is present and its value is non-null, each If this parameter is present and its value is not the CBOR simple
element of the inner CBOR array 'role_filter' is encoded as a CBOR value "null" (0xf6), each element of the inner CBOR array
unsigned integer, with the same value of a permission set 'role_filter' is encoded as a CBOR unsigned integer, with the same
("Tperm") indicating that role or combination of roles in a scope value of a permission set ("Tperm") indicating that role or
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.2.1.
skipping to change at page 26, line 48 skipping to change at page 27, line 17
(Service Unavailable) response if there are currently no OSCORE (Service Unavailable) response if there are currently no OSCORE
Sender IDs available to assign in the OSCORE group. The response Sender IDs available to assign in the OSCORE group. The response
MUST have Content-Format set to application/ace-groupcomm+cbor and MUST have Content-Format set to application/ace-groupcomm+cbor and
is formatted as defined in Section 4.1.2 of is 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 4 ("No available node identifiers"). be set to 4 ("No available node identifiers").
* In case the joining node is not going to join the group * In case the joining node is not going to join the group
exclusively as monitor and the Joining Request does not include exclusively as monitor and the Joining Request does not include
the 'client_cred' parameter, the joining process fails if the the 'client_cred' parameter, the joining process fails if the
Group Manager either: i) does not store a public key with an Group Manager either: i) does not store an authentication
accepted format for the joining node; or ii) stores multiple credential with an accepted format for the joining node; or ii)
public keys with an accepted format for the joining node. stores multiple authentication credentials with an accepted format
for the joining node.
* In order to verify the PoP evidence contained in * In order to verify the PoP evidence contained in
'client_cred_verify', the Group Manager proceeds as follows. 'client_cred_verify', the Group Manager proceeds as follows.
- As PoP input, the Group Manager uses the value of the 'scope' - As PoP input, the Group Manager uses the value of the 'scope'
parameter from the Joining Request as a CBOR byte string, parameter from the Joining Request as a CBOR byte string,
concatenated with N_S encoded as a CBOR byte string, concatenated with N_S encoded as a CBOR byte string,
concatenated with N_C encoded as a CBOR byte string. In concatenated with N_C encoded as a CBOR byte string. In
particular, N_S is determined as described in Section 6.2.1, particular, N_S is determined as described in Section 6.2.1,
while N_C is the nonce provided in the 'cnonce' parameter of while N_C is the nonce provided in the 'cnonce' parameter of
the Joining Request; the Joining Request;
- As public key of the joining node, the Group Manager uses - As public key of the joining node, the Group Manager uses
either the one retrieved from the 'client_cred' parameter of either the one included in the authentication credential
the Joining Request, or the one already stored as acquired from retrieved from the 'client_cred' parameter of the Joining
previous interactions with the joining node. 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. - The Group Manager verifies the PoP evidence as defined below.
o If the group is not a pairwise-only group, the PoP evidence o If the group is not a pairwise-only group, the PoP evidence
is a signature. The Group Manager verifies it by using the is a signature. The Group Manager verifies it by using the
public key of the joining node, as well as the signature public key of the joining node, as well as the signature
algorithm used in the OSCORE group and possible algorithm used in the OSCORE group and possible
corresponding parameters. corresponding parameters.
o If the group is a pairwise-only group, the PoP evidence is a o If the group is a pairwise-only group, the PoP evidence is a
skipping to change at page 28, line 14 skipping to change at page 28, line 33
- If the group uses (also) the pairwise mode of Group OSCORE, the - If the group uses (also) the pairwise mode of Group OSCORE, the
CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR
label is defined in Section 25.3. This parameter has the same label is defined in Section 25.3. This parameter has the same
format of 'ecdh_info_res' defined in Section 6.1.1. In format of 'ecdh_info_res' defined in Section 6.1.1. In
particular, it includes a single element 'ecdh_info_entry' particular, it includes a single element 'ecdh_info_entry'
pertaining to the OSCORE group that the joining node has tried pertaining to the OSCORE group that the joining node has tried
to join with the Joining Request. to join with the Joining Request.
- If the group is a pairwise-only group, the CBOR map MUST - If the group is a pairwise-only group, the CBOR map MUST
contain the 'gm_dh_pub_keys' parameter, whose CBOR label is contain the 'kdc_dh_creds' parameter, whose CBOR label is
defined in Section 25.3. This parameter has the same format of defined in Section 25.3. This parameter has the same format of
'gm_dh_pub_keys_res' defined in Section 6.1.2. In particular, 'kdc_dh_creds_res' defined in Section 6.1.2. In particular, it
it includes a single element 'gm_dh_pub_keys_entry' pertaining includes a single element 'kdc_dh_creds_entry' pertaining to
to the OSCORE group that the joining node has tried to join the OSCORE group that the joining node has tried to join with
with the Joining Request. the Joining Request.
- The CBOR map MAY include the 'kdcchallenge' parameter, whose - The CBOR map MAY include the 'kdcchallenge' parameter, whose
CBOR label is defined in Section 8 of CBOR label is defined in Section 8 of
[I-D.ietf-ace-key-groupcomm]. If present, this parameter is a [I-D.ietf-ace-key-groupcomm]. If present, this parameter is a
CBOR byte string, which encodes a newly generated CBOR byte string, which encodes a newly generated
'kdcchallenge' value that the Client can use when preparing a 'kdcchallenge' value that the Client can use when preparing a
Joining Request (see Section 6.2). In such a case the Group Joining Request (see Section 6.2). In such a case the Group
Manager MUST store the newly generated value as the Manager MUST store the newly generated value as the
'kdcchallenge' value associated to the joining node, possibly 'kdcchallenge' value associated with the joining node, possibly
replacing the currently stored value. replacing the currently stored value.
* The Group Manager MUST reply with a 4.00 (Bad Request) error * The Group Manager MUST reply with a 4.00 (Bad Request) error
response in case the 'scope' parameter is not present in the response in case the 'scope' parameter is not present in the
Joining Request, or if it is present and specifies any set of Joining Request, or if it is present and specifies any set of
roles not included in the following list: "requester", roles not included in the following list: "requester",
"responder", "monitor", ("requester", "responder"). Future "responder", "monitor", ("requester", "responder"). Future
specifications that define a new role MUST define possible sets of specifications that define a new role MUST define possible sets of
roles including the new one and existing ones, that are acceptable roles including the new one and existing ones, that are acceptable
to specify in the 'scope' parameter of a Joining Request. to specify in the 'scope' parameter of a Joining Request.
* The Group Manager MUST reply with a 4.00 (Bad Request) error * The Group Manager MUST reply with a 4.00 (Bad Request) error
response in case the Joining Request includes the 'client_cred' response in case the Joining Request includes the 'client_cred'
parameter but does not include both the 'cnonce' and parameter but does not include both the 'cnonce' and
'client_cred_verify' parameters. 'client_cred_verify' parameters.
* The Group Manager MUST reply with a 4.00 (Bad Request) error * The Group Manager MUST reply with a 4.00 (Bad Request) error
response in case an eligible public key for the joining node is response in case an eligible authentication credential for the
neither present in the 'client_cred' parameter nor already stored. 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 Group Manager MAY reply with a 4.00 (Bad Request) error
response in case all the following conditions hold. response in case all the following conditions hold.
- The OSCORE group uses the pairwise mode of Group OSCORE. - The OSCORE group uses the pairwise mode of Group OSCORE.
- The OSCORE group uses EdDSA public keys [RFC8032]. - The OSCORE group uses EdDSA public keys [RFC8032].
- The public key of the joining node from the 'client_cred' - The authentication credential of the joining node from the
parameter: 'client_cred' parameter includes a public key which:
o Is for the elliptic curve Ed25519 and has its Y coordinate o Is for the elliptic curve Ed25519 and has its Y coordinate
equal to -1 or 1 (mod p), with p = (2^255 - 19), see equal to -1 or 1 (mod p), with p = (2^255 - 19), see
Section 4.1 of [RFC7748]; or Section 4.1 of [RFC7748]; or
o Is for the elliptic curve Ed448 and has its Y coordinate o Is for the elliptic curve Ed448 and has its Y coordinate
equal to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see equal to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see
Section 4.2 of [RFC7748]. Section 4.2 of [RFC7748].
This prevents the acceptance of Ed25519 and Ed448 public keys that This prevents the acceptance of Ed25519 and Ed448 public keys that
skipping to change at page 29, line 30 skipping to change at page 30, line 5
thus cannot be used for the derivation of pairwise keys (see thus cannot be used for the derivation of pairwise keys (see
Section 2.4.1 of [I-D.ietf-core-oscore-groupcomm]). Section 2.4.1 of [I-D.ietf-core-oscore-groupcomm]).
* When receiving a 4.00 (Bad Request) error response, the joining * When receiving a 4.00 (Bad Request) error response, the joining
node SHOULD send a new Joining Request to the Group Manager, node SHOULD send a new Joining Request to the Group Manager,
where: where:
- The 'cnonce' parameter MUST include a new dedicated nonce N_C - The 'cnonce' parameter MUST include a new dedicated nonce N_C
generated by the joining node. generated by the joining node.
- The 'client_cred' parameter MUST include a public key - The 'client_cred' parameter MUST include an authentication
compatible with the encoding, signature or ECDH algorithm, and credential in the format indicated by the Group Manager. Also,
possible associated parameters indicated by the Group Manager. 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 - The 'client_cred_verify' parameter MUST include a PoP evidence
computed as described in Section 6.2, by using the public key computed as described in Section 6.2, by using the private key
indicated in the current 'client_cred' parameter, with the associated with the authentication credential specified in the
signature or ECDH algorithm, and possible associated parameters current 'client_cred' parameter, with the signature or ECDH
indicated by the Group Manager. If the error response from the algorithm, and possible associated parameters indicated by the
Group Manager includes the 'kdcchallenge' parameter, the Group Manager. If the error response from the Group Manager
joining node MUST use its content as new N_S challenge to includes the 'kdcchallenge' parameter, the joining node MUST
compute the PoP evidence. use its content as new N_S challenge to compute the PoP
evidence.
6.4. Send the Joining Response 6.4. Send the Joining Response
If the processing of the Joining Request described in Section 6.3 is If the processing of the Joining Request described in Section 6.3 is
successful, the Group Manager updates the group membership by successful, the Group Manager updates the group membership by
registering the joining node NODENAME as a new member of the OSCORE registering the joining node NODENAME as a new member of the OSCORE
group GROUPNAME, as described in Section 4.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,
skipping to change at page 30, line 27 skipping to change at page 31, line 7
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 to the group (see IDs, in the collection associated with the group (see
Section 2.2.1). Section 2.2.1).
* The Group Manager stores the association between i) the public key * The Group Manager stores the association between i) the
of the joining node; and ii) the Group Identifier (Gid), i.e., the authentication credential of the joining node; and ii) the Group
OSCORE ID Context, associated to the OSCORE group together with Identifier (Gid), i.e., the OSCORE ID Context, associated with the
the OSCORE Sender ID assigned to the joining node in the group. OSCORE group together with the OSCORE Sender ID assigned to the
The Group Manager MUST keep this association updated over time. joining node in the group. The Group Manager MUST keep this
association updated over time.
Then, the Group Manager replies to the joining node, providing the Then, the Group Manager replies to the joining node, providing the
updated security parameters and keying meterial necessary to 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 25.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', contains the additional parameters 'group_senderId', 'cred_fmt',
'pub_key_enc', 'sign_enc_alg', 'sign_alg', 'sign_params', 'sign_enc_alg', 'sign_alg', 'sign_params', 'ecdh_alg' and
'ecdh_alg' and 'ecdh_params' defined in Section 25.6 of this 'ecdh_params' defined in Section 25.6 of this document.
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, has as value the HKDF
Algorithm used in the OSCORE group. This parameter MAY be Algorithm used in the OSCORE group. This parameter MAY be
omitted, if the HKDF Algorithm used in the group is HKDF SHA- omitted, if the HKDF Algorithm used in the group is HKDF SHA-
256. Otherwise, this parameter MUST be present. 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
skipping to change at page 31, line 37 skipping to change at page 32, line 17
OSCORE group. This parameter MUST be present. OSCORE group. This parameter MUST be present.
- The 'group_senderId' parameter, if present, has as value the - The 'group_senderId' parameter, if present, has as value the
OSCORE Sender ID assigned to the joining node by the Group OSCORE Sender ID assigned to the joining node by the Group
Manager, as described above. This parameter MUST NOT be Manager, as described above. This parameter MUST NOT be
present if the node joins the OSCORE group exclusively with the present if the node joins the OSCORE group exclusively with the
role of monitor, according to what specified in the Access role of monitor, according to what specified in the Access
Token (see Section 4.2). In any other case, this parameter Token (see Section 4.2). In any other case, this parameter
MUST be present. MUST be present.
- The 'pub_key_enc' parameter MUST be present and specifies the - The 'cred_fmt' parameter MUST be present and specifies the
encoding of public keys used in the OSCORE group. It takes format of authentication credentials used in the OSCORE group.
value from the "Label" column of the "COSE Header Parameters" It takes value from the "Label" column of the "COSE Header
registry [COSE.Header.Parameters] (REQ6). Consistently with Parameters" registry [COSE.Header.Parameters] (REQ6).
Section 2.3 of [I-D.ietf-core-oscore-groupcomm], acceptable Consistently with Section 2.3 of
values denote an encoding that MUST explicitly provide the full [I-D.ietf-core-oscore-groupcomm], acceptable values denote a
set of information related to the public key algorithm, format that MUST explicitly provide the public key as well as
including, e.g., the used elliptic curve (when applicable). the comprehensive set of information related to the public key
algorithm, including, e.g., the used elliptic curve (when
applicable).
At the time of writing this specification, acceptable public At the time of writing this specification, acceptable formats
key encodings are CBOR Web Tokens (CWTs) and CWT Claims Sets of authentication credentials are CBOR Web Tokens (CWTs) and
(CCSs) [RFC8392], X.509 certificates [RFC7925] and C509 CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925]
certificates [I-D.ietf-cose-cbor-encoded-cert]. Further and C509 certificates [I-D.ietf-cose-cbor-encoded-cert].
encodings may be available in the future, and would be Further formats may be available in the future, and would be
acceptable to use as long as they comply with the criteria acceptable to use as long as they comply with the criteria
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. ]
skipping to change at page 33, line 49 skipping to change at page 34, line 26
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.
* 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 25.5 of this document.
* The 'pub_keys' parameter, if present, includes the public keys * The 'pub_keys' parameter, if present, includes the authentication
requested by the joining node by means of the 'get_pub_keys' credentials requested by the joining node by means of the
parameter in the Joining Request. 'get_pub_keys' parameter in the Joining Request.
If the joining node has asked for the public keys of all the group If the joining node has asked for the authentication credentials
members, i.e., 'get_pub_keys' had value the CBOR simple value of all the group members, i.e., 'get_pub_keys' had value the CBOR
'null' (0xf6) in the Joining Request, then the Group Manager simple value "null" (0xf6) in the Joining Request, then the Group
provides only the public keys of the group members that are Manager provides only the authentication credentials of the group
relevant to the joining node. That is, in such a case, 'pub_keys' members that are relevant to the joining node. That is, in such a
includes only: i) the public keys of the responders currently in case, 'pub_keys' includes only: i) the authentication credentials
the OSCORE group, in case the joining node is configured (also) as of the responders currently in the OSCORE group, in case the
requester; and ii) the public keys of the requesters currently in joining node is configured (also) as requester; and ii) the
the OSCORE group, in case the joining node is configured (also) as authentication credentials of the requesters currently in the
OSCORE group, in case the joining node is configured (also) as
responder or monitor. responder or monitor.
* The 'peer_identifiers' parameter includes the OSCORE Sender ID of * The 'peer_identifiers' parameter includes the OSCORE Sender ID of
each group member whose public key is specified in the 'pub_keys' each group member whose authentication credential is specified in
parameter. That is, a group member's Sender ID is used as the 'pub_keys' parameter. That is, a group member's Sender ID is
identifier for that group member (REQ25). used as identifier for that group member (REQ25).
* The 'group_policies' parameter SHOULD be present, and SHOULD * The 'group_policies' parameter SHOULD be present, and SHOULD
include the following elements: include the following elements:
- "Key Update Check Interval" defined in Section 4.3.1 of - "Key Update Check Interval" defined in Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm], with default value 3600; [I-D.ietf-ace-key-groupcomm], with default value 3600;
- "Expiration Delta" defined in Section 4.3.1 of - "Expiration Delta" defined in Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm], with default value 0. [I-D.ietf-ace-key-groupcomm], with default value 0.
* The 'kdc_cred' parameter MUST be present, specifying the Group * The 'kdc_cred' parameter MUST be present, specifying the Group
Manager's public key in its original binary representation (REQ8). Manager's authentication credential in its original binary
The Group Manager's public key MUST be compatible with the representation (REQ8). The Group Manager's authentication
encoding, signature or ECDH algorithm, and possible associated credential MUST be in the format used in the OSCORE group. Also,
parameters used in the OSCORE group. the authentication credential as well as the included public key
MUST be compatible with the signature or ECDH algorithm, and
possible associated parameters used in the OSCORE group.
* The 'kdc_nonce' parameter MUST be present, specifying the * The 'kdc_nonce' parameter MUST be present, specifying the
dedicated nonce N_KDC generated by the Group Manager. For N_KDC, dedicated nonce N_KDC generated by the Group Manager. For N_KDC,
it is RECOMMENDED to use a 8-byte long random nonce. it is RECOMMENDED to use a 8-byte long random nonce.
* The 'kdc_cred_verify' parameter MUST be present, specifying the * The 'kdc_cred_verify' parameter MUST be present, specifying the
proof-of-possession (PoP) evidence computed by the Group Manager. proof-of-possession (PoP) evidence computed by the Group Manager.
The PoP evidence is computed over the nonce N_KDC, which is The PoP evidence is computed over the nonce N_KDC, which is
specified in the 'kdc_nonce' parameter and taken as PoP input. specified in the 'kdc_nonce' parameter and taken as PoP input.
The PoP evidence is computed as defined below (REQ21). The PoP evidence is computed as defined below (REQ21).
- 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 Group Manager computes the signature MUST be a signature. The Group Manager computes the signature
by using the signature algorithm used in the OSCORE group, as by using the signature algorithm used in the OSCORE group, as
well as its own private key associated to the public key well as its own private key associated with the authentication
specified in the 'kdc_cred' parameter. credential specified in the 'kdc_cred' parameter.
- 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].
MAC = HKDF(salt, IKM, info, L) MAC = HKDF(salt, IKM, info, L)
The input parameters of HKDF are as follows. The input parameters of HKDF are as follows.
skipping to change at page 35, line 34 skipping to change at page 36, line 12
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 20 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, the Group Manager MUST store the Gid specified in As a last action, if the Group Manager reassigns Gid values during
the 'contextId' parameter of the 'key' parameter, as the Birth Gid of the group's lifetime (see Section 3.2.1.1 of
the joining node in the joined group (see Section 3 of [I-D.ietf-core-oscore-groupcomm]), the Group Manager MUST store the
[I-D.ietf-core-oscore-groupcomm]). This applies also in case the Gid specified in the 'contextId' parameter of the 'key' parameter, as
the Birth Gid of the joining node in the joined group (see Section 3
of [I-D.ietf-core-oscore-groupcomm]). This applies also in case the
node is in fact re-joining the group; in such a case, the newly node is in fact re-joining the group; in such a case, the newly
determined Birth Gid overwrites the one currently stored. determined Birth Gid overwrites the one currently stored.
6.5. Receive the Joining Response 6.5. 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 public key from the 'kdc_cred' parameter. The Group Manager's authentication credential from the 'kdc_cred'
joining node MUST verify the proof-of-possession (PoP) evidence parameter. The joining node MUST verify the proof-of-possession
specified in the 'kdc_cred_verify' parameter of the Joining Response (PoP) evidence specified in the 'kdc_cred_verify' parameter of the
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, as well as the signature algorithm used in of the Group Manager from the received authentication credential,
the OSCORE group and possible corresponding parameters. as well as the signature algorithm used in the OSCORE group and
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.4), 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. The the Diffie-Hellman public key of the Group Manager from the
verification succeeds if and only if the recomputed MAC is equal received authentication credential. The verification succeeds if
to the MAC conveyed as PoP evidence in the Joining Response. and only if the recomputed MAC is equal to the MAC conveyed as PoP
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.2).
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
skipping to change at page 36, line 39 skipping to change at page 37, line 21
* 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 20 of this document.
In addition, the joining node maintains an association between each In addition, the joining node maintains an association between each
public key retrieved from the 'pub_keys' parameter and the role(s) authentication credential retrieved from the 'pub_keys' parameter and
that the corresponding group member has in the OSCORE group. the role(s) that the corresponding group member has in the OSCORE
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:
* The joining node MUST NOT process an incoming request message, if * The joining node MUST NOT process an incoming request message, if
protected by a group member whose public key is not associated to protected by a group member whose authentication credential is not
the role "Requester". associated with the role "Requester".
* 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 public key is not associated to protected by a group member whose authentication credential is not
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 20). As a consequence, 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. Public Keys of Joining Nodes
Source authentication of a message sent within the group and Source authentication of a message sent within the group and
protected with Group OSCORE is ensured by means of a digital protected with Group OSCORE is ensured by means of a digital
signature embedded in the message (in group mode), or by integrity- signature embedded in the message (in group mode), or by integrity-
protecting the message with pairwise keying material derived from the protecting the message with pairwise keying material derived from the
asymmetric keys of sender and recipient (in pairwise mode). asymmetric keys of sender and recipient (in pairwise mode).
Therefore, group members must be able to retrieve each other's public Therefore, group members must be able to retrieve each other's
key from a trusted key repository, in order to verify source authentication credential from a trusted repository, in order to
authenticity of incoming group messages. verify source authenticity of incoming group messages.
As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group
Manager acts as trusted repository of the public keys of the group Manager acts as trusted repository of the authentication credentials
members, and provides those public keys to group members if requested of the group members, and provides those authentication credentials
to. Upon joining an OSCORE group, a joining node is thus expected to to group members if requested to. Upon joining an OSCORE group, a
provide its own public key to the Group Manager. 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 In particular, one of the following four cases can occur when a new
node joins an OSCORE group. node joins an OSCORE group.
* The joining node is going to join the group exclusively as * 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 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 this case, the joining node is not required to provide its own
public key to the Group Manager, which thus does not have to authentication credential to the Group Manager, which thus does
perform any check related to the public key encoding, to a not have to perform any check related to the format of the
signature or ECDH algorithm, and to possible associated authentication credential, to a signature or ECDH algorithm, and
parameters. In case that joining node still provides a public key to possible parameters associated with the algorithm and the
in the 'client_cred' parameter of the Joining Request (see public key. In case that joining node still provides an
Section 6.2), the Group Manager silently ignores that parameter, authentication credential in the 'client_cred' parameter of the
as well as the related parameters 'cnonce' and Joining Request (see Section 6.2), the Group Manager silently
'client_cred_verify'. ignores that parameter, as well as the related parameters 'cnonce'
and 'client_cred_verify'.
* The Group Manager already acquired the public key of the joining
node during a past joining process. In this case, the joining
node MAY choose not to provide again its own public key to the
Group Manager, in order to limit the size of the Joining Request.
The joining node MUST provide its own public key again if it has * The Group Manager already acquired the authentication credential
provided the Group Manager with multiple public keys during past 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 processes, intended for different OSCORE groups. If the
joining node provides its own public key, the Group Manager joining node provides its own authentication credential, the Group
performs consistency checks as per Section 6.3 and, in case of Manager performs consistency checks as per Section 6.3 and, in
success, considers it as the public key associated to the joining case of success, considers it as the authentication credential
node in the OSCORE group. associated with the joining node in the OSCORE group.
* The joining node and the Group Manager use an asymmetric proof-of- * The joining node and the Group Manager use an asymmetric proof-of-
possession key to establish a secure communication association. possession key to establish a secure communication association.
Then, two cases can occur. Then, two cases can occur.
1. The proof-of-possession key is compatible with the encoding, 1. When establishing the secure communication association, the
as well as with the signature or ECDH algorithm, and with Group Manager obtained from the joining node the joining
possible associated parameters used in the OSCORE group. node's authentication credential, in the format used in the
Then, the Group Manager considers the proof-of-possession key OSCORE group and including the asymmetric proof-of-possession
as the public key associated to the joining node in the OSCORE key as public key. Also, such authentication credential and
group. If the joining node is aware that the proof-of- the proof-of-possession key are compatible with the signature
possession key is also valid for the OSCORE group, it MAY not or ECDH algorithm, and possible associated parameters used in
provide it again as its own public key to the Group Manager. the OSCORE group.
The joining node MUST provide its own public key again if it
has provided the Group Manager with multiple public keys In this case, the Group Manager considers the authentication
during past joining processes, intended for different OSCORE credential as the one associated with the joining node in the
groups. If the joining node provides its own public key in OSCORE group. If the joining node is aware that the
the 'client_cred' parameter of the Joining Request (see 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.2), the Group Manager performs consistency checks as Section 6.2), the Group Manager performs consistency checks as
per Section 6.3 and, in case of success, considers it as the per Section 6.3 and, in case of success, considers it as the
public key associated to the joining node in the OSCORE group. authentication credential associated with the joining node in
the OSCORE group.
2. The proof-of-possession key is not compatible with the 2. The authentication credential is not in the format used in the
encoding, or with the signature or algorithm, and with OSCORE group, or else the authentication credential and the
possible associated parameters used in the OSCORE group. In proof-of-possession key included as public key are not
this case, the joining node MUST provide a different compatible with the signature or ECDH algorithm, and possible
compatible public key to the Group Manager in the associated parameters used in the OSCORE group.
'client_cred' parameter of the Joining Request (see
Section 6.2). Then, the Group Manager performs consistency In this case, the joining node MUST provide a different
checks on this latest provided public key as per Section 6.3 compatible authentication credential and public key included
and, in case of success, considers it as the public key thereof to the Group Manager in the 'client_cred' parameter of
associated to the joining node in the OSCORE group. the Joining Request (see Section 6.2). Then, the Group
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- * The joining node and the Group Manager use a symmetric proof-of-
possession key to establish a secure communication association. possession key to establish a secure communication association.
In this case, upon performing a joining process with that Group In this case, upon performing a joining process with that Group
Manager for the first time, the joining node specifies its own Manager for the first time, the joining node specifies its own
public key in the 'client_cred' parameter of the Joining Request authentication credential in the 'client_cred' parameter of the
targeting the group-membership endpoint (see Section 6.2). Joining Request targeting the group-membership endpoint (see
Section 6.2).
8. Retrieve of Updated Keying Material 8. Retrieve of 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
skipping to change at page 41, line 46 skipping to change at page 43, line 7
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 to the group (see Sender IDs, in the collection associated with the group (see
Section 2.2.1). Section 2.2.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 Public Keys of Group Members 10. 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
public keys of (other) group members. To this end, the group member authentication credentials of (other) group members. To this end,
or signature verifier sends a Public Key Request message to the Group the group member or signature verifier sends a Public Key Request
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 non-null (see Section 6.2). value is not the CBOR simple value "null" (0xf6) (see
Section 6.2).
* 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 public key is requested (REQ25). member for which the associated authentication credential is
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 to 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 Public Key 11. 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
public key to use in the group from then on, hence replacing the authentication credential to use in the group from then on, hence
current one. This can be the case, for instance, if the signature or replacing the current one. This can be the case, for instance, if
ECDH algorithm, and possible associated parameters used in the OSCORE the signature or ECDH algorithm, and possible associated parameters
group have been changed, and the current public key is not compatible used in the OSCORE group have been changed, and the current
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.2 (REQ14).
skipping to change at page 43, line 47 skipping to change at page 45, line 14
* 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 public key of the group member; the association between i) the new authentication credential of
and ii) the Group Identifier (Gid), i.e., the OSCORE ID Context, the group member; and ii) the Group Identifier (Gid), i.e., the
associated to the OSCORE group together with the OSCORE Sender ID OSCORE ID Context, associated with the OSCORE group together with
assigned to the group member in the group. The Group Manager MUST the OSCORE Sender ID assigned to the group member in the group.
keep this association updated over time. The Group Manager MUST keep this association updated over time.
12. Retrieve the Group Manager's Public Key 12. 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
public key of the Group Manager. To this end, the requesting client authentication credential of the Group Manager. To this end, the
sends a KDC Public Key Request message to the Group Manager. requesting client sends a KDC Public Key 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/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 Section 4.1.2 groupcomm+cbor and is formatted as defined in Section 4.1.2 of
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
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.4 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 public key from the requesting client retrieves the Group Manager's authentication
'kdc_cred' parameter, and proceeds as defined in Section 4.5.1.1 of credential from the 'kdc_cred' parameter, and proceeds as defined in
[I-D.ietf-ace-key-groupcomm]. In particular, the requesting client Section 4.5.1.1 of [I-D.ietf-ace-key-groupcomm]. In particular, the
verifies the PoP evidence included in 'kdc_cred_verify' by means of requesting client verifies the PoP evidence included in
the same method used when processing the Joining Response, as defined 'kdc_cred_verify' by means of the same method used when processing
in Section 6.4 of this document (REQ21). the Joining Response, as defined in Section 6.4 of this document
(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 13. 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]).
skipping to change at page 45, line 18 skipping to change at page 46, line 34
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.4, 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', 'pub_key_enc', - The parameters 'hkdf', 'contextId', 'cred_fmt', 'sign_enc_alg',
'sign_enc_alg', 'sign_alg', 'sign_params'. These parameters 'sign_alg', 'sign_params'. These parameters MUST be present.
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 25.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, that can be retrieved as defined in Section 10; messages to verify, retrieved from those members' authentication
and the public key of the Group Manager, which can be retrieved as credentials that can be obtained as defined in Section 10; and the
defined in Section 12. public key of the Group Manager, retrieved from the Group Manager's
authentication credential that can be obtained as defined in
Section 12.
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 46, line 28 skipping to change at page 48, line 26
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': -10, ; HKDF SHA-256
'contextId': h'37fc', 'contextId': h'37fc',
'pub_key_enc': 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
} }
skipping to change at page 47, line 36 skipping to change at page 49, line 31
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 5.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 if the group is currently active, or the CBOR CBOR simple value "true" (0xf5) if the group is currently active, or
simple value False otherwise. The group is considered active if it the CBOR simple value "false" (0xf4) otherwise. The group is
is set to allow new members to join, and if communication within the considered active if it is set to allow new members to join, and if
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
communications within the group, until it becomes active again. communications within the group, until it becomes active again.
Upon learning from a 2.05 (Content) response that the group has Upon learning from a 2.05 (Content) response that the group has
become active again, the group member can resume taking part in become active again, the group member can resume taking part in
communications within the group. communications within the group.
Figure 5 gives an overview of the exchange described above, while Figure 5 gives an overview of the exchange described above, while
skipping to change at page 49, line 7 skipping to change at page 51, line 7
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 20). 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 public keys from the Group Manager (see keying material and authentication credentials from the Group
Section 8.1, Section 8.2 and Section 10). However, such messages Manager (see Section 8.1, Section 8.2 and Section 10). However,
may specify the current Gid of the group, as value of the such messages may specify the current Gid of the group, as value
'kid_context' field of the OSCORE CoAP option (see Section 6.1 of of the 'kid_context' field of the OSCORE CoAP option (see
[RFC8613] and Section 4.2 of [I-D.ietf-core-oscore-groupcomm]). Section 6.1 of [RFC8613] and Section 4.2 of
[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 public keys from the Group Manager (see retrieving the required authentication credentials from the Group
Section 10). As discussed above, intercepted messages do not Manager (see Section 10). As discussed above, intercepted
provide a direct hint to the correct group name, while they may messages do not provide a direct hint to the correct group name,
specify the current Gid of the group, as value of the while they may specify the current Gid of the group, as value of
'kid_context' field of the OSCORE CoAP option. In such a case, the 'kid_context' field of the OSCORE CoAP option. In such a
upon intercepting a message in the group, the node requires to case, upon intercepting a message in the group, the node requires
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
would retain the old Gid value and cannot correctly associate would retain the old Gid value and cannot correctly associate
intercepted messages to the right group, especially if acting as intercepted messages to the right group, especially if acting as
signature verifier in several groups. This in turn prevents the signature verifier in several groups. This in turn prevents the
efficient verification of signatures, and especially the retrieval efficient verification of signatures, and especially the retrieval
of required, new public keys from the Group Manager. of required, new authentication credentials from the Group
Manager.
In either case, the node only knows the current Gid of the group, as In either case, the node only knows the current Gid of the group, as
learned from received or intercepted messages exchanged in the group. learned from received or intercepted messages exchanged in the group.
As detailed below, the node can contact the Group Manager, and As detailed below, the node can contact the Group Manager, and
request the group name and URI to the group-membership resource request the group name and URI to the group-membership resource
corresponding to that Gid. Then, it can use that information to corresponding to that Gid. Then, it can use that information to
either join the group as a candidate group member, get the latest either join the group as a candidate group member, get the latest
keying material as a current group member, or retrieve public keys keying material as a current group member, or retrieve authentication
used in the group as a signature verifier. To this end, the node credentials used in the group as a signature verifier. To this end,
sends a Group Name and URI Retrieval Request, as per Section 4.2.1.1 the node sends a Group Name and URI Retrieval Request, as per
of [I-D.ietf-ace-key-groupcomm]. Section 4.2.1.1 of [I-D.ietf-ace-key-groupcomm].
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 at the Group Manager formatted as defined in Section 4.2.1 /ace-group at the Group Manager formatted as defined in Section 4.2.1
of [I-D.ietf-ace-key-groupcomm]. Each element of the CBOR array of [I-D.ietf-ace-key-groupcomm]. Each element of the CBOR array
'gid' is a CBOR byte string (REQ13), which encodes the Gid of the '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-membership group for which the group name and the URI to the group-membership
resource are requested. resource are requested.
Upon receiving the Group Name and URI Retrieval Request, the Group Upon receiving the Group Name and URI Retrieval Request, the Group
Manager processes it as per Section 4.2.1 of Manager processes it as per Section 4.2.1 of
skipping to change at page 51, line 25 skipping to change at page 54, line 5
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 19.
19. Removal of a Group Member 19. 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 18, 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, the Group Manager "forgets" the Birth Gid currently In either case, if the Group Manager reassigns Gid values during the
associated to the leaving node in the OSCORE group. This was stored group's lifetime (see Section 3.2.1.1 of
following the Joining Response sent to that node, after its latest [I-D.ietf-core-oscore-groupcomm]), the Group Manager "forgets" the
(re-)joining of the OSCORE group (see Section 6.4). Birth Gid currently associated with the leaving node in the OSCORE
group. This was stored following the Joining Response sent to that
node, after its latest (re-)joining of the OSCORE group (see
Section 6.4).
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 only
once, using either of the corresponding methods. once, using either of the corresponding methods.
* If, upon joining the group (see Section 6.2), the leaving node * If, upon joining the group (see Section 6.2), 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
skipping to change at page 52, line 15 skipping to change at page 54, line 46
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 to the group (see Section 2.2.1). collection associated with the group (see Section 2.2.1).
* The Group Manager cancels the association between, on one hand, * The Group Manager cancels the association between, on one hand,
the public key of the leaving node and, on the other hand, the Gid the authentication credential of the leaving node and, on the
associated to the OSCORE group together with the freed Sender ID other hand, the Gid associated with the OSCORE group together with
value. The Group Manager deletes the public key of the leaving the freed Sender ID value. The Group Manager deletes the
node, if that public key has no remaining association with any authentication credential of the leaving node, if that
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 20). 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
skipping to change at page 52, line 43 skipping to change at page 55, line 32
20. Group Rekeying Process 20. 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.
Consistently with Section 3.2 of [I-D.ietf-core-oscore-groupcomm]: 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
* The Group Manager can reassign a Gid to the same group over that lifetime, e.g., once the whole space of Gid values has been used for
group's lifetime, e.g., once the whole space of Gid values has the group in question. If the Group Manager supports reassignment of
been used for the group in question. Gid values and performs it in a group, then the Group Manager
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). If any of such "elder current group members (see Section 6.4).
members" is found in the group, the Group Manager MUST evict them
from the group. That is, the Group Manager MUST terminate their * If any of such "elder members" is found in the group, the Group
membership and MUST rekey the group in such a way that the new Manager MUST evict them from the group. That is, the Group
keying material is not provided to those evicted elder members. Manager MUST terminate their membership and MUST rekey the group
This also includes adding their relinquished Sender IDs to the in such a way that the new keying material is not provided to
most recent set of stale Sender IDs, in the collection associated those evicted elder members. This also includes adding their
to the group (see Section 2.2.1), before rekeying the group. relinquished Sender IDs to the most recent set of stale Sender
IDs, in the collection associated with the group (see
Section 2.2.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 public remain in the group. This avoids affecting the retrieval of
keys from the Group Manager and the verification of group messages. authentication credentials from the Group Manager and the
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 20.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.4).
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 to 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
to the group (see Section 2.2.1). with the group (see Section 2.2.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 to 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 15) and then possibly requesting the current keying material
(see Section 8.1). (see Section 8.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 to 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 to that Group Manager. associated with that Group Manager.
Finally, Section 20.3 discusses how a group member can realize that Finally, Section 20.3 discusses how a group member can realize that
it has missed one or more rekeying instances, and the actions it is it has missed one or more rekeying instances, and the actions it is
accordingly required to take. accordingly required to take.
20.1. Sending Rekeying Messages 20.1. Sending Rekeying Messages
The group rekeying messages MUST have Content-Format set to The group rekeying messages MUST have Content-Format set to
application/ace-groupcomm+cbor and have the same format used for the application/ace-groupcomm+cbor and have the same format used for the
Joining Response message in Section 6.4, with the following Joining Response message in Section 6.4, with the following
skipping to change at page 55, line 17 skipping to change at page 58, line 8
* 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 25.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 to the group (see Section 2.2.1), and takes the most associated with the group (see Section 2.2.1), and takes the
recent set X, i.e., the set associated to the current version most recent set X, i.e., the set associated with the current
of the group keying material about to be relinquished. version 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 join the group. Following
the same semantics used in the Joining Response message (see the same semantics used in the Joining Response message (see
Section 6.4), the three parameters specify the public key, roles Section 6.4), the three parameters specify the authentication
in the group and node identifier of each of the Clients that have credential, roles in the group and node identifier of each of the
requested to join the group. The Group Manager MUST NOT include a Clients that have requested to join the group. The Group Manager
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 channel between the Group Manager and the group member
used during the joining process. In particular, each rekeying used during the joining process. In particular, each rekeying
message can target the 'control_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.2).
skipping to change at page 56, line 29 skipping to change at page 59, line 20
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.
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 group rekeying scheme defined in Section 20.1
is used, the stale Sender IDs are specified by the 'stale_node_ids' is used, the stale Sender IDs are specified by the 'stale_node_ids'
parameter. 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 public key associated to a stale the group member MUST remove every authentication credential
Sender ID from its list of group members' public keys used in the associated with a stale Sender ID from its list of group members'
group, and MUST delete each of its Recipient Contexts used in the authentication credentials used in the group, and MUST delete each of
group whose corresponding Recipient ID is a stale Sender ID. its Recipient Contexts used in the group whose corresponding
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 group rekeying scheme defined in Section 20.1 is
used, this information is specified by the 'num' parameter. 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 owned 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 owned 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 20.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 stored keying material owned by the stored one. That is, the old keying material stored by the group
group member has version number V, while the received keying member has version number V, while the received keying material
material has version number V' < (V + 1). In such a case, the has version number V' < (V + 1). In such a case, the group member
group member MUST ignore the received rekeying messages and MUST MUST ignore the received rekeying messages and MUST NOT install
NOT install the received keying material. the received keying material.
20.3. Missed Rekeying Instances 20.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 20.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 8.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.2). 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 public keys of other group c. The group member has obtained the authentication credentials of
members, through a Public Key Request-Response exchange with the other group members, through a Public Key Request-Response exchange
Group Manager (see Section 10). In particular, V is different than with the Group Manager (see Section 10). In particular, V is
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 15). 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 20.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 public keys from payload, the group member MUST remove all the authentication
its list of group members' public keys used in the group, and credentials from its list of group members' authentication
MUST delete all its Recipient Contexts used in the group. credentials used in the group, and MUST delete all its Recipient
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 public key Manager. Then, the group member MUST remove every authentication
associated to a stale Sender ID from its list of group members' credential associated with a stale Sender ID from its list of
public keys used in the group, and MUST delete each of its group members' authentication credentials used in the group, and
Recipient Contexts used in the group whose corresponding MUST delete each of its Recipient Contexts used in the group
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 20.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 public keys from payload, the group member MUST remove all the authentication
its list of group members' public keys used in the group, and credentials from its list of group members' authentication
MUST delete all its Recipient Contexts used in the group. credentials used in the group, and MUST delete all its Recipient
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 public key Manager. Then, the group member MUST remove every authentication
associated to a stale Sender ID from its list of group members' credential associated with a stale Sender ID from its list of
public keys used in the group, and MUST delete each of its group members' authentication credentials used in the group, and
Recipient Contexts used in the group whose corresponding MUST delete each of its Recipient Contexts used in the group
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 8.1),
or by re-joining the group (see Section 6.2). or by re-joining the group (see Section 6.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.2). 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 public keys of all the current group members. That is, for the authentication credentials of all the current group
the 'get_pub_keys' parameter of the Joining Request MUST be members. That is, the 'get_pub_keys' parameter of the Joining
present and MUST be set to the CBOR simple value 'null' (0xf6). Request MUST be present and MUST be set to the CBOR simple value
"null" (0xf6).
2. When receiving the Joining Response (see Section 6.5 and 2. When receiving the Joining Response (see Section 6.5 and
Section 6.5), the group member retrieves the set Z of public keys Section 6.5), the group member retrieves the set Z of
specified in the 'pub_keys' parameter. authentication credentials specified in the 'pub_keys' parameter.
Then, the group member MUST remove every public key which is not Then, the group member MUST remove every authentication
in Z from its list of group members' public keys used in the credential which is not in Z from its list of group members'
group, and MUST delete each of its Recipient Contexts used in the authentication credentials used in the group, and MUST delete
group that does not include any of the public keys in Z. each of its Recipient Contexts used in the group that does not
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 20.3.1. Retrieval of 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 20.3), a node needs to retrieve from the Group Manager
the data required to delete some of its stored group members' public the data required to delete some of its stored group members'
keys and Recipient Contexts (see Section 5.3.1). This data is authentication credentials and Recipient Contexts (see
provided as an aggregated set of stale Sender IDs, which are used as Section 5.3.1). This data is provided as an aggregated set of stale
specified in Section 20.3. Sender IDs, which are used as specified in Section 20.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 5.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 owned 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 to the latest keying material in the group, i.e., if V >= associated with the latest keying material in the group, i.e., if V
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 to the stored in the collection of stale Sender IDs associated with the
group (see Section 2.2.1). group (see Section 2.2.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.
- The Group Manager creates an empty CBOR array ARRAY and an - The Group Manager creates an empty CBOR array ARRAY and an
empty set X. empty set X.
- The Group Manager considers the SKEW most recent sets stored in - The Group Manager considers the SKEW most recent sets stored in
the collection of stale Sender IDs associated to the group. the collection of stale Sender IDs associated with the group.
Note that the most recent set is the one associate to the Note that the most recent set is the one associate to the
latest version of the group keying material. latest version of the group keying material.
- The Group Manager copies all the Sender IDs from the selected - The Group Manager copies all the Sender IDs from the selected
sets into X. When doing so, the Group Manager MUST discard sets into X. When doing so, the Group Manager MUST discard
duplicates. That is, the same Sender ID MUST NOT be present duplicates. That is, the same Sender ID MUST NOT be present
more than once in the final content of X. more than once in the final content of X.
- 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.
skipping to change at page 61, line 46 skipping to change at page 64, line 46
Clients are required to support the new parameters defined in this Clients are required to support the new parameters defined in this
application profile as specified below (REQ29). 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.
* 'gm_dh_pub_keys' MUST be supported by a Client that intends to * 'kdc_dh_creds' MUST be supported by a Client that intends to join
join a group which uses the pairwise mode of Group OSCORE and that a group which uses the pairwise mode of Group OSCORE and that does
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 public key. 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). Clients 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
a public key to use in a group MUST support these parameters. an own authentication credential to use in a group MUST support
these parameters.
* 'kdcchallenge'. A Client that has a public key to use in a group * 'kdcchallenge'. A Client that has an own authentication
and that provides the Access Token to the Group Manager through a credential to use in a group and that provides the Access Token to
Token Transfer Request (see Section 6.1) MUST support this the Group Manager through a Token Transfer Request (see
parameter. Section 6.1) 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' public keys. 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 this
parameter. 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 to each public key. of the group member associated with each authentication
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 public key is support these parameters, since the Group Manager's authentication
required to process messages protected with Group OSCORE (see credential is required to process messages protected with Group
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 over IP multicast, MUST support this
parameter. parameter.
* 'control_group_uri'. A Client that support the hosting of local * 'control_group_uri'. A Client that support the hosting of local
resources each associated to a group (hence acting as CoAP server) resources each associated with a group (hence acting as CoAP
and the reception of one-to-many requests sent to those resources server) and the reception of one-to-many requests sent to those
by the Group Manager (e.g., over IP multicast) MUST support this resources by the Group Manager (e.g., over IP multicast) MUST
parameter. support this parameter.
22. ACE Groupcomm Error Identifiers 22. ACE Groupcomm Error Identifiers
In addition to what is defined in Section 9 of In addition to what is 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.
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
skipping to change at page 64, line 14 skipping to change at page 67, line 14
23.1. Common 23.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 the
same default value defined in Section 3.2 of [RFC8613], i.e., HKDF same default value defined in Section 3.2 of [RFC8613], i.e., HKDF
SHA-256 (COSE algorithm encoding: -10). SHA-256 (COSE algorithm encoding: -10).
* For the format 'pub_key_enc' used to encode the public keys in the * For the format 'cred_fmt' used for the authentication credentials
group, the Group Manager SHOULD use CBOR Web Token (CWT) or CWT in the group, the Group Manager SHOULD use CBOR Web Token (CWT) or
Claims Set (CCS) [RFC8392], i.e., the COSE Header Parameter 'kcwt' CWT Claims Set (CCS) [RFC8392], i.e., the COSE Header Parameter
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 to the group (see Section 2.2.1). collection associated with the group (see Section 2.2.1).
23.2. Group Mode 23.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 encrypted messages protected with the group mode, the Group
Manager SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10) Manager SHOULD use AES-CCM-16-64-128 (COSE algorithm encoding: 10)
as default value. as default value.
skipping to change at page 66, line 39 skipping to change at page 69, line 39
* 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). According to
the specific application requirements, this can include rekeying the specific application requirements, this can include rekeying
the group upon changes in its membership. In particular, renewing the group upon changes in its membership. In particular, renewing
the group keying material is required upon a new node's joining or the group keying material is required upon a new node's joining or
a current node's leaving, in case backward security and forward a current node's leaving, in case backward security and forward
security have to be preserved, respectively. security have to be preserved, respectively.
* Provisioning and retrieval of public keys (see Section 3 of * Provisioning and retrieval of authentication credentials (see
[I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key Section 3 of [I-D.ietf-core-oscore-groupcomm]). The Group Manager
repository of public keys of group members, and provides them upon acts as repository of authentication credentials of group members,
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. Alternatively, the joining challenge-response defined in Section 6.
node can use its own public key as asymmetric proof-of-possession key
to establish a secure channel with the Group Manager, e.g., as in Alternatively, when establishing a secure communication association
Section 3.2.2 of [I-D.ietf-ace-dtls-authorize]. However, this with the Group Manager, the joining node can provide the Group
requires such proof-of-possession key to be compatible with the Manager with its own authentication credential, and use the public
encoding, as well as with the signature algorithm, and possible key included thereof as asymmetric proof-of-possession key, e.g., as
associated parameters used in the OSCORE group. in Section 3.2.2 of [I-D.ietf-ace-dtls-authorize] in case the joining
node authenticates itself during the DTLS handshake with the the
Group Manager. However, this requires the authentication credential
to be in the format used in the OSCORE group, and that both the
authentication credential and the included public key are compatible
with the 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.
skipping to change at page 68, line 29 skipping to change at page 71, line 34
* 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 24.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 to 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 to by that Client since the latest update to the N_S value associated
the Access Token, the Group Manager can be forced to falsely believe with the Access Token, the Group Manager can be forced to falsely
that the Client possesses its own private key at that point in time, believe that the Client possesses its own private key at that point
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 25. 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.
skipping to change at page 69, line 21 skipping to change at page 72, line 27
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 specification]]
* Parameter name: gm_dh_pub_keys * 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 specification]]
25.2. OAuth Parameters CBOR Mappings 25.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 specification]]
* Name: gm_dh_pub_keys * 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 specification]]
25.3. ACE Groupcomm Parameters 25.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
skipping to change at page 70, line 27 skipping to change at page 73, line 32
* Reference: [[This document]] (Section 9) * Reference: [[This document]] (Section 9)
* 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.3)
* Name: gm_dh_pub_keys * 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.3)
* Name: group_enc_key * Name: group_enc_key
* CBOR Key: TBD * CBOR Key: TBD
skipping to change at page 72, line 4 skipping to change at page 75, line 10
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: bstr
* 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.4)
* Name: pub_key_enc * Name: cred_fmt
* CBOR Label: TBD * CBOR Label: TBD
* CBOR Type: integer * CBOR Type: integer
* Registry: COSE Header Parameters * Registry: COSE Header Parameters
* Description: Encoding of Public Keys to be used in the OSCORE * Description: Format of authentication credentials to be used in
group the OSCORE group
* Reference: [[This document]] (Section 6.4) * Reference: [[This document]] (Section 6.4)
* Name: sign_enc_alg * Name: sign_enc_alg
* CBOR Label: TBD * CBOR Label: TBD
* CBOR Type: tstr / int * CBOR Type: tstr / int
* Registry: COSE Algorithms * Registry: COSE Algorithms
skipping to change at page 74, line 4 skipping to change at page 77, line 8
25.7. TLS Exporter Labels 25.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.2.1)
25.8. AIF 25.8. AIF
IANA is asked to register the following entry to the "Toid" registry For the media-types application/aif+cbor and application/aif+json
within the "AIF" registry group defined in Section 5.2 of defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to
[I-D.ietf-ace-aif]. register the following entries for the two media-type parameters Toid
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"
registry group.
* Name: oscore-group-name * Name: oscore-group-name
* Description/Specification: group name of the OSCORE group, as * Description/Specification: group name of an OSCORE group
specified in [[This document]].
IANA is asked to register the following entry to the "Tperm" registry * Reference: [[This document]]
within the "AIF" registry group defined in Section 5.2 of
[I-D.ietf-ace-aif].
* Name: oscore-group-roles * Name: oscore-group-roles
* Description/Specification: role(s) of the member of the OSCORE * Description/Specification: role(s) in the OSCORE group
group, as specified in [[This document]].
25.9. Media Type Registrations
This document registers the 'application/aif-groupcomm-oscore+cbor'
media type for the AIF specific data model AIF-OSCORE-GROUPCOMM
defined in Section 3 of [[This document]]. This registration follows
the procedures specified in [RFC6838].
These media type has parameters for specifying the object identifier
("Toid") and set of permissions ("Tperm") defined for the AIF-generic
model in [I-D.ietf-ace-aif]; default values are the values "oscore-
group-name" for "Toid" and "oscore-group-roles" for "Tperm".
Type name: application
Subtype name: aif-groupcomm-oscore+cbor
Required parameters: "Toid", "Tperm"
Optional parameters: N/A
Encoding considerations: Must be encoded as a CBOR array, each
element of which is an array [Toid, Tperm] as defined in Section 3 of
[[This document]].
Security considerations: See Section 24 of [[This document]].
Interoperability considerations: N/A
Published specification: [[This document]]
Applications that use this media type: The type is used by
applications that want to express authorization information about
joining OSCORE groups, as specified in [[This document]].
Fragment identifier considerations: N/A
Additional information: N/A
Person & email address to contact for further information:
iesg@ietf.org (mailto:iesg@ietf.org)
Intended usage: COMMON * Reference: [[This document]]
Restrictions on usage: None 25.9. CoAP Content-Format
Author: Marco Tiloca marco.tiloca@ri.se (mailto:marco.tiloca@ri.se) IANA is asked to register the following entries to the "CoAP Content-
Formats" registry within the "Constrained RESTful Environments (CoRE)
Parameters" registry group.
Change controller: IESG * Media Type: application/aif+cbor;Toid="oscore-group-
name",Tperm="oscore-group-roles"
Provisional registration? No * Encoding: -
25.10. CoAP Content-Format * ID: TBD
IANA is asked to register the following entry to the "CoAP Content- * Reference: [[This document]]
Formats" registry within the "Constrained RESTful Environments (CoRE)
Parameters" registry group:
Media Type: application/aif-groupcomm-oscore+cbor;Toid="oscore-group- * Media Type: application/aif+json;Toid="oscore-group-
name",Tperm"oscore-group-roles" name",Tperm="oscore-group-roles"
Encoding: - * Encoding: -
ID: TBD * ID: TBD
Reference: [[This document]] * Reference: [[This document]]
25.11. Group OSCORE Roles 25.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.15. Section 25.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 76, line 31 skipping to change at page 78, 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.12. CoRE Resource Type 25.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.13. ACE Scope Semantics 25.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: Access to OSCORE groups through the ACE Group * Description: Membership and key management operations at the ACE
Manager. Group Manager for Group OSCORE.
* Reference: [[This document]] * Reference: [[This document]]
25.14. ACE Groupcomm Errors 25.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 77, line 36 skipping to change at page 80, 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.15. Expert Review Instructions 25.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.
skipping to change at page 79, line 13 skipping to change at page 81, 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-03, 24 June 2021, ace-aif-06, 4 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-ace-aif- <https://www.ietf.org/archive/id/draft-ietf-ace-aif-
03.txt>. 06.txt>.
[I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", Work in Progress,
Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June
2021, <https://www.ietf.org/archive/id/draft-ietf-ace-
dtls-authorize-18.txt>.
[I-D.ietf-ace-key-groupcomm] [I-D.ietf-ace-key-groupcomm]
Palombini, F. and M. Tiloca, "Key Provisioning for Group Palombini, F. and M. Tiloca, "Key Provisioning for Group
Communication using ACE", Work in Progress, Internet- Communication using ACE", Work in Progress, Internet-
Draft, draft-ietf-ace-key-groupcomm-14, 25 October 2021, Draft, draft-ietf-ace-key-groupcomm-15, 23 December 2021,
<https://www.ietf.org/archive/id/draft-ietf-ace-key- <https://www.ietf.org/archive/id/draft-ietf-ace-key-
groupcomm-14.txt>. groupcomm-15.txt>.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", Work in Progress, Internet-Draft, Framework (ACE-OAuth)", Work in Progress, Internet-Draft,
draft-ietf-ace-oauth-authz-45, 29 August 2021, draft-ietf-ace-oauth-authz-46, 8 November 2021,
<https://www.ietf.org/archive/id/draft-ietf-ace-oauth- <https://www.ietf.org/archive/id/draft-ietf-ace-oauth-
authz-45.txt>. authz-46.txt>.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE Profile of the Authentication and Authorization "OSCORE Profile of the Authentication and Authorization
for Constrained Environments Framework", Work in Progress, for Constrained Environments Framework", Work in Progress,
Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May
2021, <https://www.ietf.org/archive/id/draft-ietf-ace- 2021, <https://www.ietf.org/archive/id/draft-ietf-ace-
oscore-profile-19.txt>. oscore-profile-19.txt>.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
and J. Park, "Group OSCORE - Secure Group Communication and J. Park, "Group OSCORE - Secure Group Communication
for CoAP", Work in Progress, Internet-Draft, draft-ietf- for CoAP", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-groupcomm-13, 25 October 2021, core-oscore-groupcomm-14, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-core-oscore- <https://www.ietf.org/archive/id/draft-ietf-core-oscore-
groupcomm-13.txt>. groupcomm-14.txt>.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", Work in Progress, Internet-Draft, Initial Algorithms", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020,
<https://www.ietf.org/archive/id/draft-ietf-cose- <https://www.ietf.org/archive/id/draft-ietf-cose-
rfc8152bis-algs-12.txt>. rfc8152bis-algs-12.txt>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
skipping to change at page 82, line 12 skipping to change at page 84, line 31
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 26.2. Informative References
[I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", Work in Progress,
Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June
2021, <https://www.ietf.org/archive/id/draft-ietf-ace-
dtls-authorize-18.txt>.
[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-
04, 25 October 2021, <https://www.ietf.org/archive/id/ 05, 7 March 2022, <https://www.ietf.org/archive/id/draft-
draft-ietf-ace-oscore-gm-admin-04.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-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", Work in Progress, Internet-Draft, draft-ietf- (CoAP)", Work in Progress, Internet-Draft, draft-ietf-
core-coap-pubsub-09, 30 September 2019, core-coap-pubsub-09, 30 September 2019,
<https://www.ietf.org/archive/id/draft-ietf-core-coap- <https://www.ietf.org/archive/id/draft-ietf-core-coap-
pubsub-09.txt>. pubsub-09.txt>.
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
05, 25 October 2021, <https://www.ietf.org/archive/id/ 06, 7 March 2022, <https://www.ietf.org/archive/id/draft-
draft-ietf-core-groupcomm-bis-05.txt>. ietf-core-groupcomm-bis-06.txt>.
[I-D.ietf-cose-cbor-encoded-cert] [I-D.ietf-cose-cbor-encoded-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
M. Furuhed, "CBOR Encoded X.509 Certificates (C509 M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft- Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-02, 12 July 2021, ietf-cose-cbor-encoded-cert-03, 10 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-cose-cbor- <https://www.ietf.org/archive/id/draft-ietf-cose-cbor-
encoded-cert-02.txt>. encoded-cert-03.txt>.
[I-D.tiloca-core-oscore-discovery] [I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of
OSCORE Groups with the CoRE Resource Directory", Work in OSCORE Groups with the CoRE Resource Directory", Work in
Progress, Internet-Draft, draft-tiloca-core-oscore- Progress, Internet-Draft, draft-tiloca-core-oscore-
discovery-10, 25 October 2021, discovery-11, 7 March 2022,
<https://www.ietf.org/archive/id/draft-tiloca-core-oscore- <https://www.ietf.org/archive/id/draft-tiloca-core-oscore-
discovery-10.txt>. discovery-11.txt>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
skipping to change at page 84, line 4 skipping to change at page 86, line 11
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
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 4.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 well as the corresponding Media instance of "Toid" and "Tperm" as Media Type parameters and a
Type and Content-Format, as per the guidelines in corresponding Content-Format, as per the guidelines in
[I-D.ietf-ace-aif]: see Section 25.8, Section 25.9 and [I-D.ietf-ace-aif]: see Section 25.8 and Section 25.9.
Section 25.10.
* 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 encoding public keys * REQ6 - Specify the acceptable formats for authentication
and, if used, the acceptable values for 'pub_key_enc': acceptable credentials and, if used, the acceptable values for 'pub_key_enc':
formats explicitly provide the full set of information related to acceptable formats explicitly provide the public key as well as
the public key algorithm (see Section 6.1 and Section 6.4). the comprehensive set of information related to the public key
Consistent acceptable values for 'pub_key_enc' are taken from the algorithm (see Section 6.1 and Section 6.4). Consistent
"Label" column of the "COSE Header Parameters" registry acceptable values for 'pub_key_enc' are taken from the "Label"
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 a public key and if this has to * REQ8 - Define whether the KDC has an authentication credential and
be provided through the 'kdc_cred' parameter, see Section 4.1 of if this has to be provided through the 'kdc_cred' parameter, see
[I-D.ietf-ace-key-groupcomm]: yes, as required by the Group OSCORE Section 4.1 of [I-D.ietf-ace-key-groupcomm]: yes, as required by
protocol [I-D.ietf-core-oscore-groupcomm], see Section 6.4 of this the Group OSCORE protocol [I-D.ietf-core-oscore-groupcomm], see
document. Section 6.4 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.12. Section 25.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 5.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
skipping to change at page 86, line 36 skipping to change at page 88, line 45
Section 10). Section 10).
* 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 10.
* 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.
* 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.13. semantics for binary scopes: see Section 25.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 21.
* 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 21.
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 encoding of public parameters, ECDH key parameters and exact format of
keys used in the group, in case the joining node supports the authentication credentials used in the group, in case the
pairwise mode of Group OSCORE (see Section 6.1). joining node supports the pairwise mode of Group OSCORE (see
Section 6.1).
- 'gm_dh_pub_keys', to ask for and retrieve the Group Manager's - 'kdc_dh_creds', to ask for and retrieve the Group Manager's
Diffie-Hellman public keys, in case the the joining node Diffie-Hellman authentication credentials, in case the joining
supports the pairwise mode of Group OSCORE and the Access Token node supports the pairwise mode of Group OSCORE and the Access
authorizes to join parwise-only groups (see Section 6.1). Token authorizes to join parwise-only groups (see Section 6.1).
* 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.3).
* 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.14. see Section 25.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 19 for the eviction of
a group member; see Section 20 for the group rekeying process. a group member; see Section 20 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 a public key for the specific node: send a failure to retrieve an authentication credential for the specific
4.00 (Bad Request) error response to a Joining Request (see node: send a 4.00 (Bad Request) error response to a Joining
Section 6.3). Request (see Section 6.3).
* 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 20 of this document.
* OPT10 (Optional) - Specify the functionalities implemented at the * OPT10 (Optional) - Specify the functionalities implemented at the
skipping to change at page 88, line 22 skipping to change at page 90, line 35
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).
* OPT13 (Optional) - Specify how the identifier of a group members's * OPT13 (Optional) - Specify how the identifier of a group members's
public key is included in requests sent to other group members: authentication credential is included in requests sent to other
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 20.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.
skipping to change at page 89, line 35 skipping to change at page 91, line 49
id : gname / [ + gname ], id : gname / [ + gname ],
ecdh_alg : int / tstr, ecdh_alg : int / tstr,
ecdh_parameters : [ alg_capab_1 : any, ecdh_parameters : [ alg_capab_1 : any,
alg_capab_2 : any, alg_capab_2 : any,
..., ...,
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 ],
pub_key_enc = int / nil cred_fmt = int / null
] ]
gname = tstr gname = tstr
Figure 12: 'ecdh_info_entry' with general format Figure 12: '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.4) 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'.
skipping to change at page 90, line 17 skipping to change at page 92, line 26
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]).
- Each following element 'sign_params'[i], i.e., with index i > - Each following element 'sign_params'[i], i.e., with index i >
0, is the array of COSE capabilities for the algorithm 0, is the array of COSE capabilities for the algorithm
capability specified in 'sign_params'[0][i-1]. capability specified in 'sign_params'[0][i-1].
For example, if 'sign_params'[0][0] specifies the key type as For example, if 'sign_params'[0][0] specifies the key type as
capability of the algorithm, then 'sign_params'[1] is the array of capability of the algorithm, then 'sign_params'[1] is the array of
COSE capabilities for the COSE key type associated to the COSE capabilities for the COSE key type associated with the
signature algorithm, as specified for that key type in the signature algorithm, 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] (see Section 8.2 of [COSE.Key.Types] (see Section 8.2 of
[I-D.ietf-cose-rfc8152bis-algs]). [I-D.ietf-cose-rfc8152bis-algs]).
* The 'ecdh_params' array includes M+1 elements, whose exact * The 'ecdh_params' array includes M+1 elements, whose exact
structure and value depend on the value of the ECDH algorithm structure and value depend on the value of the ECDH algorithm
specified in 'ecdh_alg'. specified in 'ecdh_alg'.
- The first element, i.e., 'ecdh_params'[0], is the array of the - The first element, i.e., 'ecdh_params'[0], is the array of the
skipping to change at page 90, line 39 skipping to change at page 92, line 48
that algorithm in the "Capabilities" column of the "COSE 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]).
- Each following element 'ecdh_params'[i], i.e., with index i > - Each following element 'ecdh_params'[i], i.e., with index i >
0, is the array of COSE capabilities for the algorithm 0, is the array of COSE capabilities for the algorithm
capability specified in 'ecdh_params'[0][i-1]. capability specified in 'ecdh_params'[0][i-1].
For example, if 'ecdh_params'[0][0] specifies the key type as For example, if 'ecdh_params'[0][0] specifies the key type as
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 to 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 -11 to -12 C.1. Version -12 to -13
* Clarified semantics of 'ecdh_info' and 'gm_dh_pub_keys'. * Renamed parameters about authentication credentials.
* It is optional for the Group Manager to reassign Gids by tracking
"Birth Gids".
* Distinction between authentication credentials and public keys.
* Updated IANA considerations related to AIF.
* Updated textual description of registered ACE Scope Semantics
value.
C.2. Version -11 to -12
* 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.
* Revised error handling for the newly defined resources. * Revised error handling for the newly defined resources.
skipping to change at page 91, line 27 skipping to change at page 93, line 49
* New parameter 'rekeying_scheme'. * New parameter 'rekeying_scheme'.
* Categorization of new parameters and inherited conditional * Categorization of new parameters and inherited conditional
parameters. parameters.
* Clarifications on what to do in case of enhanced error responses. * Clarifications on what to do in case of enhanced error responses.
* Changed UCCS to CCS. * Changed UCCS to CCS.
* Public keys of just joined Clients can be in rekeying messages. * Authentication credentials of just joined Clients can be in
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.2. Version -10 to -11 C.3. 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 public key. * New resource to retrieve the Group Manager's authentication
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.
* 'pub_key_enc' takes value from the COSE Header Parameters * 'cred_fmt' takes value from the COSE Header Parameters registry.
registry.
* Improved alignment of the Joining Response payload with the Group * Improved alignment of the Joining Response payload with the Group
OSCORE Security Context parameters. OSCORE Security Context parameters.
* Recycling Group IDs by tracking "Birth GIDs". * Recycling Group IDs by tracking "Birth GIDs".
* Error handling in case of non available Sender IDs upon joining. * Error handling in case of non available Sender IDs upon joining.
* Error handling in case EdDSA public keys with invalid Y coordinate * Error handling in case EdDSA public keys with invalid Y coordinate
when the pairwise mode of Group OSCORE is supported. when the pairwise mode of Group OSCORE is supported.
skipping to change at page 92, line 35 skipping to change at page 95, line 10
* 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.3. Version -09 to -10 C.4. 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.4. Version -08 to -09 C.5. 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 93, line 41 skipping to change at page 96, line 16
* 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.5. Version -07 to -08 C.6. 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 public * Updated payload format of the FETCH request to retrieve
keys. 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.6. Version -06 to -07 C.7. 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.7. Version -05 to -06 C.8. 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 95, line 7 skipping to change at page 97, line 29
* 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.8. Version -04 to -05 C.9. 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.
* Added method for uploading a new public key to the Group Manager. * Added method for uploading a new authentication credential to the
Group Manager.
* Added resource and method for retrieving the current group status. * Added resource and method for retrieving the current group status.
* Fixed inconsistency in retrieving group keying material only. * Fixed inconsistency in retrieving group keying material only.
* Clarified retrieval of keying material for monitor-only members. * Clarified retrieval of keying material for monitor-only members.
* 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.9. Version -03 to -04 C.10. 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 96, line 9 skipping to change at page 98, line 32
* 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.10. Version -02 to -03 C.11. 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 96, line 32 skipping to change at page 99, line 7
* 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.11. Version -01 to -02 C.12. 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.
* Added parameters to indicate the encoding of public keys. * Added parameters to indicate the encoding of authentication
credentials.
* Challenge-response for proof-of-possession of signature keys * Challenge-response for proof-of-possession of signature keys
(Section 4). (Section 4).
* Renamed 'key_info' parameter to 'sign_info'; updated its format; * Renamed 'key_info' parameter to 'sign_info'; updated its format;
extended to include also parameters of the signature key extended to include also parameters of the signature key
(Section 4.1). (Section 4.1).
* Code 4.00 (Bad request), in responses to joining nodes providing * Code 4.00 (Bad request), in responses to joining nodes providing
an invalid public key (Section 4.3). an invalid authentication credential (Section 4.3).
* Clarifications on provisioning and checking of public keys * Clarifications on provisioning and checking of authentication
(Sections 4 and 6). credentials (Sections 4 and 6).
* Extended discussion on group rekeying and possible different * Extended discussion on group rekeying and possible different
approaches (Section 7). approaches (Section 7).
* 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.12. Version -00 to -01 C.13. 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. 245 change blocks. 
730 lines changed or deleted 792 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/