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