draft-ietf-ace-key-groupcomm-oscore-06.txt   draft-ietf-ace-key-groupcomm-oscore-07.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: November 12, 2020 Universitaet Duisburg-Essen Expires: December 20, 2020 Universitaet Duisburg-Essen
F. Palombini F. Palombini
Ericsson AB Ericsson AB
May 11, 2020 June 18, 2020
Key Management for OSCORE Groups in ACE Key Management for OSCORE Groups in ACE
draft-ietf-ace-key-groupcomm-oscore-06 draft-ietf-ace-key-groupcomm-oscore-07
Abstract Abstract
This specification defines an application profile of the ACE This specification defines an application profile of the ACE
framework for Authentication and Authorization, to request and framework for Authentication and Authorization, to request and
provision keying material in group communication scenarios that are provision keying material in group communication scenarios that are
based on CoAP and secured with Group Object Security for Constrained based on CoAP and secured with Group Object Security for Constrained
RESTful Environments (OSCORE). This application profile delegates RESTful Environments (OSCORE). This application profile delegates
the authentication and authorization of Clients that join an OSCORE the authentication and authorization of Clients that join an OSCORE
group through a Resource Server acting as Group Manager for that group through a Resource Server acting as Group Manager for that
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2020. This Internet-Draft will expire on December 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
5.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Sending the Joining Request . . . . . . . . . . . . . . . 10 5.2. Sending the Joining Request . . . . . . . . . . . . . . . 10
5.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 11 5.2.1. Value of the N_S Challenge . . . . . . . . . . . . . 11
5.3. Processing the Joining Request . . . . . . . . . . . . . 12 5.3. Processing the Joining Request . . . . . . . . . . . . . 12
5.4. Joining Response . . . . . . . . . . . . . . . . . . . . 13 5.4. Joining Response . . . . . . . . . . . . . . . . . . . . 13
5.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode 5.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode
Support . . . . . . . . . . . . . . . . . . . . . . . . . 16 Support . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 16 6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 16
7. Retrieval of Updated Keying Material . . . . . . . . . . . . 18 7. Retrieval of Updated Keying Material . . . . . . . . . . . . 18
7.1. Retrieval of Group Keying Material . . . . . . . . . . . 18 7.1. Retrieval of Group Keying Material . . . . . . . . . . . 18
7.2. Retrieval of Group Keying Material and Sender ID . . . . 18 7.2. Retrieval of Group Keying Material and Sender ID . . . . 19
8. Retrieval of New Keying Material . . . . . . . . . . . . . . 19 8. Retrieval of New Keying Material . . . . . . . . . . . . . . 19
9. Retrieval of Public Keys of Group Members . . . . . . . . . . 20 9. Retrieval of Public Keys of Group Members . . . . . . . . . . 20
10. Update of Public Key . . . . . . . . . . . . . . . . . . . . 20 10. Update of Public Key . . . . . . . . . . . . . . . . . . . . 21
11. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 21 11. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 21
12. Retrieval of Keying Material Version . . . . . . . . . . . . 21 12. Retrieval of Keying Material Version . . . . . . . . . . . . 22
13. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 22 13. Retrieval of Group Status . . . . . . . . . . . . . . . . . . 22
14. Request to Leave the Group . . . . . . . . . . . . . . . . . 22 14. Request to Leave the Group . . . . . . . . . . . . . . . . . 23
15. Removal of a Group Member . . . . . . . . . . . . . . . . . . 23 15. Removal of a Group Member . . . . . . . . . . . . . . . . . . 23
16. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 23 16. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 24
17. Security Considerations . . . . . . . . . . . . . . . . . . . 25 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26
17.1. Management of OSCORE Groups . . . . . . . . . . . . . . 25 17.1. Management of OSCORE Groups . . . . . . . . . . . . . . 26
17.2. Size of Nonces for Signature Challenge . . . . . . . . . 26 17.2. Size of Nonces for Signature Challenge . . . . . . . . . 27
17.3. Reusage of Nonces for Signature Challenge . . . . . . . 27 17.3. Reusage of Nonces for Signature Challenge . . . . . . . 28
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
18.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 28 18.1. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 28
18.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 28 18.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 29
18.3. OSCORE Security Context Parameters Registry . . . . . . 28 18.3. OSCORE Security Context Parameters Registry . . . . . . 29
18.4. Sequence Number Synchronization Method Registry . . . . 29 18.4. Sequence Number Synchronization Method Registry . . . . 30
18.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 30 18.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 31
18.6. ACE Groupcomm Policy Registry . . . . . . . . . . . . . 30 18.6. ACE Groupcomm Policy Registry . . . . . . . . . . . . . 31
18.7. TLS Exporter Label Registry . . . . . . . . . . . . . . 31 18.7. TLS Exporter Label Registry . . . . . . . . . . . . . . 32
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
19.1. Normative References . . . . . . . . . . . . . . . . . . 31 19.1. Normative References . . . . . . . . . . . . . . . . . . 32
19.2. Informative References . . . . . . . . . . . . . . . . . 33 19.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 34 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 35
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 36 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 37
B.1. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 36 B.1. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 37
B.2. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 37 B.2. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 38
B.3. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 37 B.3. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 38
B.4. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 38 B.4. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 39
B.5. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 38 B.5. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 39
B.6. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 39 B.6. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 40
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39 B.7. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
[RFC8613] is a method for application-layer protection of the [RFC8613] is a method for application-layer protection of the
Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object
Signing and Encryption (COSE) [RFC8152] and enabling end-to-end Signing and Encryption (COSE)
security of CoAP payload and options. [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and
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 over IP multicast
[I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which [I-D.ietf-core-groupcomm-bis]. This relies on a Group Manager, which
is responsible for managing an OSCORE group and enables the group is responsible for managing an OSCORE group and enables the group
members to exchange CoAP messages secured with Group OSCORE. The members to exchange CoAP messages secured with Group OSCORE. The
Group Manager can be responsible for multiple groups, coordinates the Group Manager can be responsible for multiple groups, coordinates the
joining process of new group members, and is entrusted with the joining process of new group members, and is entrusted with the
distribution and renewal of group keying material. distribution and renewal of group keying material.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
Group communication for CoAP over IP multicast has been enabled in Group communication for CoAP over IP multicast 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 (OSCORE) [RFC8613] as
described in [I-D.ietf-core-oscore-groupcomm]. A network node joins described in [I-D.ietf-core-oscore-groupcomm]. A network node joins
an OSCORE group by interacting with the responsible Group Manager. an OSCORE group by interacting with the responsible Group Manager.
Once registered in the group, the new node can securely exchange Once registered in the group, the new node can securely exchange
messages with other group members. messages with other group members.
This specification describes how to use [I-D.ietf-ace-key-groupcomm] This specification describes how to use [I-D.ietf-ace-key-groupcomm]
and [I-D.ietf-ace-oauth-authz] to perform a number of authentication, and [I-D.ietf-ace-oauth-authz] to perform a number of authentication,
authorization and key distribution actions, as defined in Section 2. authorization and key distribution actions, as defined in Section 2
of [I-D.ietf-ace-key-groupcomm], for an OSCORE group. of [I-D.ietf-ace-key-groupcomm], for an OSCORE group.
With reference to [I-D.ietf-ace-key-groupcomm]: With reference to [I-D.ietf-ace-key-groupcomm]:
o The node wishing to joining the OSCORE group, i.e. the joining o The node wishing to joining the OSCORE group, i.e. the joining
node, is the Client. node, is the Client.
o The Group Manager is the Key Distribution Center (KDC), acting as o The Group Manager is the Key Distribution Center (KDC), acting as
a Resource Server. a Resource Server.
skipping to change at page 7, line 38 skipping to change at page 7, line 38
* The group name of each OSCORE group to join under the Group * The group name of each OSCORE group to join under the Group
Manager is encoded as a CBOR text string (REQ1). Manager is encoded as a CBOR text string (REQ1).
* Accepted values for role identifiers in the OSCORE group to * Accepted values for role identifiers in the OSCORE group to
join are: "requester", "responder", and "monitor" (REQ2). join are: "requester", "responder", and "monitor" (REQ2).
Possible combinations are: ["requester" , "responder"]. An Possible combinations are: ["requester" , "responder"]. An
additional role identifier is "verifier", denoting an external additional role identifier is "verifier", denoting an external
signature verifier that does not join the OSCORE group. Each signature verifier that does not join the OSCORE group. Each
role identifier MUST be encoded as a CBOR integer (REQ2), by role identifier MUST be encoded as a CBOR integer (REQ2), by
using for abbreviation the values specified in Figure 1 (OPT7). using for abbreviation the values specified in Figure 1 (OPT7)
(see Appendix A).
+-----------+------------+ +-----------+------------+
| Name | CBOR Value | | Name | CBOR Value |
+-----------+------------+ +-----------+------------+
| requester | TBD8 | | requester | TBD8 |
| responder | TBD9 | | responder | TBD9 |
| monitor | TBD10 | | monitor | TBD10 |
| verifier | TBD11 | | verifier | TBD11 |
+-----------+------------+ +-----------+------------+
skipping to change at page 9, line 51 skipping to change at page 9, line 51
The 'kdcchallenge' parameter MAY be omitted from the 2.01 The 'kdcchallenge' parameter MAY be omitted from the 2.01
(Created) response, if the 'scope' of the Access Token includes (Created) response, if the 'scope' of the Access Token includes
only the role "monitor" or only the role "verifier", for each of only the role "monitor" or only the role "verifier", for each of
the specified groups. the specified groups.
o If the 'sign_info' parameter is present in the response, the o 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'.
* In the 'id' element, every group name is encoded as a CBOR text * In the 'id' element, every group name is encoded as a CBOR text
string (REQ1). string (REQ1) (see Appendix A).
* 'sign_alg' takes value from Tables 5 and 6 of [RFC8152], if not
encoding the CBOR simple value Null.
* 'sign_parameters' takes values from the "Counter Signature * 'sign_alg' takes value from the "Value" column of the "COSE
Parameters" Registry (see Section 11.1 of Algorithms" Registry [COSE.Algorithms], if not encoding the
[I-D.ietf-core-oscore-groupcomm]). Its structure depends on
the value of 'sign_alg'. If no parameters of the counter
signature algorithm are specified or if 'sign_alg' encodes the
CBOR simple value Null, 'sign_parameters' MUST be encoding the
CBOR simple value Null. CBOR simple value Null.
* 'sign_key_parameters' takes values from the "Counter Signature * If not encoding the CBOR simple value Null, 'sign_parameters'
Key Parameters" Registry (see Section 11.2 of is a CBOR array including the following two elements:
[I-D.ietf-core-oscore-groupcomm]). Its structure depends on
the value of 'sign_alg'. If no parameters of the key used with + 'sign_alg_capab', encoded as a CBOR array. Its precise
the counter signature algorithm are specified or if 'sign_alg' format and value is the same as the COSE capabilities entry
encodes the CBOR simple value Null, 'sign_key_parameters' MUST in the "Capabilities" column of the "COSE Algorithms"
be encoding the CBOR simple value Null. Registry [COSE.Algorithms], for the algorithm indicated in
'sign_alg' (REQ4).
+ 'sign_key_type_capab', encoded as a CBOR array. Its precise
format and value is the same as the COSE capabilities entry
in the "Capabilities" column of the "COSE Key Types"
Registry [COSE.Key.Types], for the algorithm indicated in
'sign_alg' (REQ4).
* If not encoding the CBOR simple value Null,
'sign_key_parameters' is a CBOR array. Its precise format and
value is the same as the COSE capabilities entry in the
"Capabilities" column of the "COSE Key Types" Registry
[COSE.Key.Types], for the algorithm indicated in 'sign_alg'
(REQ5).
* If 'pub_key_enc_res' is present, it takes value 1 ("COSE_Key") * If 'pub_key_enc_res' is present, it takes value 1 ("COSE_Key")
from the 'Confirmation Key' column of the "CWT Confirmation from the 'Confirmation Key' column of the "CWT Confirmation
Method" Registry defined in [RFC8747], so indicating that Method" Registry defined in [RFC8747], so indicating that
public keys in the OSCORE group are encoded as COSE Keys public keys in the OSCORE group are encoded as COSE Keys
[RFC8152]. Future specifications may define additional values [I-D.ietf-cose-rfc8152bis-struct]. Future specifications may
for this parameter. define additional values for this parameter.
Note that, other than through the above parameters as defined in Note that, other than through the above parameters as defined in
Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY Section 3.3 of [I-D.ietf-ace-key-groupcomm], the joining node MAY
have previously retrieved this information by other means, e.g. by have previously retrieved this information by other means, e.g. by
using the approach described in [I-D.tiloca-core-oscore-discovery]. using the approach described in [I-D.tiloca-core-oscore-discovery].
Additionally, if allowed by the used transport profile of ACE, the Additionally, if allowed by the used transport profile of ACE, the
joining node may instead provide the Access Token to the Group joining node may instead provide the Access Token to the Group
Manager by other means, e.g. during a secure session establishment Manager by other means, e.g. during a secure session establishment
(see Section 3.3.1 of [I-D.ietf-ace-dtls-authorize]). (see Section 3.3.1 of [I-D.ietf-ace-dtls-authorize]).
skipping to change at page 14, line 32 skipping to change at page 14, line 39
* The 'salt' parameter, if present, has as value the OSCORE * The 'salt' parameter, if present, has as value the OSCORE
Master Salt. Master Salt.
* The 'contextId' parameter MUST be present and has as value the * The 'contextId' parameter MUST be present and has as value the
Group Identifier (Gid), i.e. the OSCORE ID Context of the Group Identifier (Gid), i.e. the OSCORE ID Context of the
OSCORE group. OSCORE group.
* The 'cs_alg' parameter MUST be present and specifies the * The 'cs_alg' parameter MUST be present and specifies the
algorithm used to countersign messages in the group. This algorithm used to countersign messages in the group. This
parameter takes values from the "COSE Algorithms" Registry, parameter takes values from the "Value" column of the "COSE
defined in Section 16.4 of [RFC8152]. Algorithms" Registry [COSE.Algorithms].
* The 'cs_params' parameter MAY be present and specifies the * The 'cs_params' parameter MAY be present and specifies the
additional parameters for the counter signature algorithm. parameters for the counter signature algorithm. This parameter
This parameter is a CBOR map whose content depends on the is a CBOR array, which includes the following two elements:
counter signature algorithm, as specified in Section 2 and
Section 11.1 of [I-D.ietf-core-oscore-groupcomm]. + 'sign_alg_capab', with the same encoding as defined in
Section 5.1. The value is the same as in the Token Post
response where the 'sign_parameters' value was non-null.
+ 'sign_key_type_capab', with the same encoding as defined in
Section 5.1. The value is the same as in the Token Post
response where the 'sign_parameters' value was non-null.
* The 'cs_key_params' parameter MAY be present and specifies the * The 'cs_key_params' parameter MAY be present and specifies the
additional parameters for the key used with the counter parameters for the key used with the counter signature
signature algorithm. This parameter is a CBOR map whose algorithm. This parameter is a CBOR array, with the same non-
content depends on the counter signature algorithm, as null encoding and value as 'sign_key_parameters' of the
specified in Section 2 and Section 11.2 of Section 5.1.
[I-D.ietf-core-oscore-groupcomm].
* The 'cs_key_enc' parameter MAY be present and specifies the * The 'cs_key_enc' parameter MAY be present and specifies the
encoding of the public keys of the group members. This encoding of the public keys of the group members. This
parameter is a CBOR integer, whose value is 1 ("COSE_Key") parameter is a CBOR integer, whose value is 1 ("COSE_Key")
taken from the 'Confirmation Key' column of the "CWT taken from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry defined in [RFC8747], so Confirmation Method" Registry defined in [RFC8747], so
indicating that public keys in the OSCORE group are encoded as indicating that public keys in the OSCORE group are encoded as
COSE Keys [RFC8152]. Future specifications may define COSE Keys [I-D.ietf-cose-rfc8152bis-struct]. Future
additional values for this parameter. If this parameter is not specifications may define additional values for this parameter.
present, 1 ("COSE_Key") MUST be assumed as default value. If this parameter is not present, 1 ("COSE_Key") MUST be
assumed as default value.
o The 'num' parameter MUST be present. o The 'num' parameter MUST be present.
o The 'ace-groupcomm-profile' parameter MUST be present and has o The 'ace-groupcomm-profile' parameter MUST be present and has
value coap_group_oscore_app (TBD1), which is defined in value coap_group_oscore_app (TBD1), which is defined in
Section 18.1 of this specification. Section 18.1 of this specification.
o The 'exp' parameter MUST be present. o The 'exp' parameter MUST be present.
o The 'pub_keys' parameter, if present, includes the public keys of o The 'pub_keys' parameter, if present, includes the public keys of
skipping to change at page 16, line 19 skipping to change at page 16, line 27
If the application requires backward security, the Group Manager MUST If the application requires backward security, the Group Manager MUST
generate updated security parameters and group keying material, and generate updated security parameters and group keying material, and
provide it to the current group members upon the new node's joining provide it to the current group members upon the new node's joining
(see Section 16). As a consequence, the joining node is not able to (see Section 16). As a consequence, the joining node is not able to
access secure communication in the group occurred prior its joining. access secure communication in the group occurred prior its joining.
5.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode Support 5.5. ACE Groupcomm Policy for Group OSCORE Pairwise Mode Support
This specifications defines the group policy "Group OSCORE Pairwise This specifications defines the group policy "Group OSCORE Pairwise
Mode Support", for which it registers an entry in the "ACE Groupcomm Mode Support", for which it registers an entry in the "ACE Groupcomm
Policy" IANA Registry defined in Section 8.7 of Policy" IANA Registry defined in Section 8.8 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
The corresponding element in the 'group_policies' parameter of the The corresponding element in the 'group_policies' parameter of the
Joining Response (see Section 5.4) encodes the CBOR simple value Joining Response (see Section 5.4) encodes the CBOR simple value
True, if the OSCORE group supports the pairwise mode of Group OSCORE True, if the OSCORE group supports the pairwise mode of Group OSCORE
[I-D.ietf-core-oscore-groupcomm], or the CBOR simple value False [I-D.ietf-core-oscore-groupcomm], or the CBOR simple value False
otherwise (REQ14). otherwise (REQ14).
6. Public Keys of Joining Nodes 6. Public Keys of Joining Nodes
Source authentication of OSCORE messages exchanged within the group Source authentication of a message sent within the group and
is ensured by means of digital counter signatures (see Sections 2 and protected with Group OSCORE is ensured by means of a digital counter
4 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members signature embedded in the message (in group mode), or by integrity-
must be able to retrieve each other's public key from a trusted key protecting the message with pairwise keying material derived from the
repository, in order to verify source authenticity of incoming group asymmetric keys of sender and recipient (in pairwise mode).
messages.
Therefore, group members must be able to retrieve each other's public
key from a trusted key repository, in order to verify source
authenticity of incoming group messages.
As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group
Manager acts as trusted repository of the public keys of the group Manager acts as trusted repository of the public keys of the group
members, and provides those public keys to group members if requested members, and provides those public keys to group members if requested
to. Upon joining an OSCORE group, a joining node is thus expected to to. Upon joining an OSCORE group, a joining node is thus expected to
provide its own public key to the Group Manager. provide its own public key to the Group Manager.
In particular, one of the following four cases can occur when a new In particular, one of the following four cases can occur when a new
node joins an OSCORE group. node joins an OSCORE group.
skipping to change at page 19, line 29 skipping to change at page 19, line 37
within the 'key' parameter. within the 'key' parameter.
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, use them to set Sender ID, and, if they differ from the current ones, use them to set
up the new OSCORE Security Context as described in Section 2 of up the new OSCORE Security Context as described in Section 2 of
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
8. Retrieval of New Keying Material 8. Retrieval of New Keying Material
As discussed in Section 2.5 of [I-D.ietf-core-oscore-groupcomm], a As discussed in Section 2.4.2 of [I-D.ietf-core-oscore-groupcomm], a
group member may at some point experience a wrap-around of its own group member may at some point exhaust its Sender Sequence Numbers in
Sender Sequence Number in the group. the 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.4 of message to the Group Manager, as per Section 4.4 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 /group-oscore/GROUPNAME/nodes/NODENAME at the request to the endpoint /group-oscore/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.1.6.1 of [I-D.ietf-ace-key-groupcomm], and it as defined in Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm], and
performs one of the following actions. performs one of the following actions.
skipping to change at page 24, line 35 skipping to change at page 24, line 49
communication channel between the Group Manager and the group member communication channel between the Group Manager and the group member
used during the joining process. In particular, each rekeying used during the joining process. In particular, each rekeying
message can target the 'control_path' URI path defined in message can target the 'control_path' URI path defined in
Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm] (OPT9), if provided Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm] (OPT9), if provided
by the intended recipient upon joining the group (see Section 5.2). by the intended recipient upon joining the group (see Section 5.2).
It is RECOMMENDED that the Group Manager gets confirmation of It is RECOMMENDED that the Group Manager gets confirmation of
successful distribution from the group members, and admits a maximum successful distribution from the group members, and admits a maximum
number of individual retransmissions to non-confirming group members. number of individual retransmissions to non-confirming group members.
In case the rekeying terminates and some group members have not
received the new keying material, they will not be able to correctly
process following secured messages exchanged in the group. These
group members will eventually contact the Group Manager, in order to
retrieve the current keying material and its version.
This approach requires group members to act (also) as servers, in This approach requires group members to act (also) as servers, in
order to correctly handle unsolicited group rekeying messages from order to correctly handle unsolicited group rekeying messages from
the Group Manager. In particular, if a group member and the Group the Group Manager. In particular, if a group member and the Group
Manager use OSCORE [RFC8613] to secure their pairwise communications, Manager use OSCORE [RFC8613] to secure their pairwise communications,
the group member MUST create a Replay Window in its own Recipient the group member MUST create a Replay Window in its own Recipient
Context upon establishing the OSCORE Security Context with the Group Context upon establishing the OSCORE Security Context with the Group
Manager, e.g. by means of the OSCORE profile of ACE Manager, e.g. by means of the OSCORE profile of ACE
[I-D.ietf-ace-oscore-profile]. [I-D.ietf-ace-oscore-profile].
Group members and the Group Manager SHOULD additionally support Group members and the Group Manager SHOULD additionally support
alternative rekeying approaches that do not require group members to alternative rekeying approaches that do not require group members to
act (also) as servers. A number of such approaches are defined in act (also) as servers. A number of such approaches are defined in
Section 4.3 of [I-D.ietf-ace-key-groupcomm]. In particular, a group Section 4.3 of [I-D.ietf-ace-key-groupcomm]. In particular, a group
member may subscribe for updates to the group-membership resource of member may subscribe for updates to the group-membership resource of
the group, at the endpoint /group-oscore/GROUPNAME/nodes/NODENAME of the group, at the endpoint /group-oscore/GROUPNAME/nodes/NODENAME of
the Group Manager. This can rely on CoAP Observe [RFC7641] or on a the Group Manager. This can rely on CoAP Observe [RFC7641] or on a
full-fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group full-fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group
Manager acting as Broker. Manager acting as Broker.
In case the rekeying terminates and some group members have not
received the new keying material, they will not be able to correctly
process following secured messages exchanged in the group. These
group members will eventually contact the Group Manager, in order to
retrieve the current keying material and its version.
Some of these group members may be in multiple groups, each
associated to a different Group Manager. When failing to correctly
process messages secured with the new keying material, these group
members may not have sufficient information to determine which exact
Group Manager they should contact, in order to retrieve the current
keying material they are missing.
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
hint to determine the right Group Manager, as long as no collisions
among Group Prefixes are experienced. Otherwise, a group member
needs to contact the Group Manager of each group, e.g. by first
requesting only the version of the current group keying material (see
Section 12) and then possibly requesting the current keying material
(see Section 7.1).
Furthermore, some of these group members can be in multiple groups,
all of which associated to the same Group Manager. In this case,
these group members may also not have sufficient information to
determine which exact group they should refer to, when contacting the
right Group Manager. Hence, they need to contact a Group Manager
multiple times, i.e. separately for each group they belong to and
associated to that Group Manager.
17. Security Considerations 17. 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.
17.1. Management of OSCORE Groups 17.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.
o Management of group keying material (see Section 2.4 of o Management of group keying material (see Section 3.1 of
[I-D.ietf-core-oscore-groupcomm]). The Group Manager is [I-D.ietf-core-oscore-groupcomm]). The Group Manager is
responsible for the renewal and re-distribution of the keying responsible for the renewal and re-distribution of the keying
material in the groups of its competence (rekeying). According to material in the groups of its competence (rekeying). According to
the specific application requirements, this can include rekeying the specific application requirements, this can include rekeying
the group upon changes in its membership. In particular, renewing the group upon changes in its membership. In particular, renewing
the group keying material is required upon a new node's joining or the group keying material is required upon a new node's joining or
a current node's leaving, in case backward security and forward a current node's leaving, in case backward security and forward
security have to be preserved, respectively. security have to be preserved, respectively.
o Provisioning and retrieval of public keys (see Section 2 of o Provisioning and retrieval of public keys (see Section 2 of
skipping to change at page 28, line 8 skipping to change at page 28, line 48
Note to RFC Editor: Please replace all occurrences of "[[This Note to RFC Editor: Please replace all occurrences of "[[This
specification]]" with the RFC number of this specification and delete specification]]" with the RFC number of this specification and delete
this paragraph. this paragraph.
This document has the following actions for IANA. This document has the following actions for IANA.
18.1. ACE Groupcomm Profile Registry 18.1. ACE Groupcomm Profile Registry
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Profile" Registry defined in Section 9.6 of Profile" Registry defined in Section 8.7 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o Name: coap_group_oscore_app o Name: coap_group_oscore_app
o Description: Application profile to provision keying material for o Description: Application profile to provision keying material for
participating in group communication protected with Group OSCORE participating in group communication protected with Group OSCORE
as per [I-D.ietf-core-oscore-groupcomm]. as per [I-D.ietf-core-oscore-groupcomm].
o CBOR Value: TBD1 o CBOR Value: TBD1
o Reference: [[This specification]] (Section 5.4) o Reference: [[This specification]] (Section 5.4)
18.2. ACE Groupcomm Key Registry 18.2. ACE Groupcomm Key Registry
skipping to change at page 28, line 24 skipping to change at page 29, line 15
participating in group communication protected with Group OSCORE participating in group communication protected with Group OSCORE
as per [I-D.ietf-core-oscore-groupcomm]. as per [I-D.ietf-core-oscore-groupcomm].
o CBOR Value: TBD1 o CBOR Value: TBD1
o Reference: [[This specification]] (Section 5.4) o Reference: [[This specification]] (Section 5.4)
18.2. ACE Groupcomm Key Registry 18.2. ACE Groupcomm Key Registry
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Key" Registry defined in Section 9.5 of [I-D.ietf-ace-key-groupcomm]. Key" Registry defined in Section 8.6 of [I-D.ietf-ace-key-groupcomm].
o Name: Group_OSCORE_Security_Context object o Name: Group_OSCORE_Security_Context object
o Key Type Value: TBD2 o Key Type Value: TBD2
o Profile: "coap_group_oscore_app", defined in Section 18.1 of this o Profile: "coap_group_oscore_app", defined in Section 18.1 of this
specification. specification.
o Description: A Group_OSCORE_Security_Context object encoded as o Description: A Group_OSCORE_Security_Context object encoded as
described in Section 5.4 of this specification. described in Section 5.4 of this specification.
skipping to change at page 29, line 4 skipping to change at page 29, line 44
o Name: cs_alg o Name: cs_alg
o CBOR Label: TBD3 o CBOR Label: TBD3
o CBOR Type: tstr / int o CBOR Type: tstr / int
o Registry: COSE Algorithm Values (ECDSA, EdDSA) o Registry: COSE Algorithm Values (ECDSA, EdDSA)
o Description: OSCORE Counter Signature Algorithm Value o Description: OSCORE Counter Signature Algorithm Value
o Reference: [[This specification]] (Section 5.4) o Reference: [[This specification]] (Section 5.4)
o Name: cs_params o Name: cs_params
o CBOR Label: TBD4 o CBOR Label: TBD4
o CBOR Type: array
o CBOR Type: map
o Registry: Counter Signatures Parameters o Registry: Counter Signatures Parameters
o Description: OSCORE Counter Signature Algorithm Additional o Description: OSCORE Counter Signature Algorithm Additional
Parameters Parameters
o Reference: [[This specification]] (Section 5.4) o Reference: [[This specification]] (Section 5.4)
o Name: cs_key_params o Name: cs_key_params
o CBOR Label: TBD5 o CBOR Label: TBD5
o CBOR Type: map o CBOR Type: array
o Registry: Counter Signatures Key Parameters o Registry: Counter Signatures Key Parameters
o Description: OSCORE Counter Signature Key Additional Parameters o Description: OSCORE Counter Signature Key Additional Parameters
o Reference: [[This specification]] (Section 5.4) o Reference: [[This specification]] (Section 5.4)
o Name: cs_key_enc o Name: cs_key_enc
o CBOR Label: TBD6 o CBOR Label: TBD6
skipping to change at page 29, line 47 skipping to change at page 30, line 41
o Registry: ACE Public Key Encoding o Registry: ACE Public Key Encoding
o Description: Encoding of Public Keys to be used with the OSCORE o Description: Encoding of Public Keys to be used with the OSCORE
Counter Signature Algorithm Counter Signature Algorithm
o Reference: [[This specification]] (Section 5.4) o Reference: [[This specification]] (Section 5.4)
18.4. Sequence Number Synchronization Method Registry 18.4. Sequence Number Synchronization Method Registry
IANA is asked to register the following entries in the "Sequence IANA is asked to register the following entries in the "Sequence
Number Synchronization Method" Registry defined in Section 9.8 of Number Synchronization Method" Registry defined in Section 8.9 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o Name: Best effort o Name: Best effort
o Value: 1 o Value: 1
o Description: No action is taken. o Description: No action is taken.
o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1) o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1)
skipping to change at page 30, line 35 skipping to change at page 31, line 29
o Value: 3 o Value: 3
o Description: Challenge response using the Echo Option for CoAP o Description: Challenge response using the Echo Option for CoAP
from [I-D.ietf-core-echo-request-tag]. from [I-D.ietf-core-echo-request-tag].
o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3) o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3)
18.5. ACE Groupcomm Parameters Registry 18.5. ACE Groupcomm Parameters Registry
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Parameters" Registry defined in Section 9.4 of Parameters" Registry defined in Section 8.5 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o Name: clientId o Name: clientId
o CBOR Key: TBD7 o CBOR Key: TBD7
o CBOR Type: Byte string o CBOR Type: Byte string
o Reference: [[This specification]] (Section 8) o Reference: [[This specification]] (Section 8)
18.6. ACE Groupcomm Policy Registry 18.6. ACE Groupcomm Policy Registry
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Policy" Registry defined in Section 8.7 of Policy" Registry defined in Section 8.8 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o Name: Group OSCORE Pairwise Mode Support o Name: Group OSCORE Pairwise Mode Support
o CBOR Key: TBD8 o CBOR Key: TBD8
o CBOR Type: Simple value o CBOR Type: Simple value
o Description: True if the OSCORE group supports the pairwise mode o Description: True if the OSCORE group supports the pairwise mode
of Group OSCORE [I-D.ietf-core-oscore-groupcomm], False otherwise. of Group OSCORE [I-D.ietf-core-oscore-groupcomm], False otherwise.
o Reference: [[This specification]] (Section 5.5) o Reference: [[This specification]] (Section 5.5)
18.7. TLS Exporter Label Registry 18.7. TLS Exporter Label Registry
IANA is asked to register the following entry in the "TLS Exporter IANA is asked to register the following entry in the "TLS Exporter
Label" Registry defined in Section 6 of [RFC5705] and updated in Label" Registry defined in Section 6 of [RFC5705] and updated in
Section 12 of [RFC8447]. Section 12 of [RFC8447].
skipping to change at page 31, line 34 skipping to change at page 32, line 27
o DTLS-OK: Y o DTLS-OK: Y
o Recommended: N o Recommended: N
o Reference: [[This specification]] (Section 5.2.1) o Reference: [[This specification]] (Section 5.2.1)
19. References 19. References
19.1. Normative References 19.1. Normative References
[COSE.Algorithms]
IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>.
[COSE.Key.Types]
IANA, "COSE Key Types",
<https://www.iana.org/assignments/cose/
cose.xhtml#key-type>.
[I-D.ietf-ace-key-groupcomm] [I-D.ietf-ace-key-groupcomm]
Palombini, F. and M. Tiloca, "Key Provisioning for Group Palombini, F. and M. Tiloca, "Key Provisioning for Group
Communication using ACE", draft-ietf-ace-key-groupcomm-06 Communication using ACE", draft-ietf-ace-key-groupcomm-07
(work in progress), May 2020. (work in progress), June 2020.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33
(work in progress), February 2020. (work in progress), February 2020.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE profile of the Authentication and Authorization "OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace- for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-10 (work in progress), March 2020. oscore-profile-10 (work in progress), March 2020.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP",
draft-ietf-core-oscore-groupcomm-08 (work in progress), draft-ietf-core-oscore-groupcomm-08 (work in progress),
April 2020. April 2020.
[I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-09
(work in progress), June 2020.
[I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", draft-ietf-cose-rfc8152bis-
struct-10 (work in progress), June 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
skipping to change at page 33, line 12 skipping to change at page 34, line 22
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>. 2020, <https://www.rfc-editor.org/info/rfc8747>.
19.2. Informative References 19.2. Informative References
[I-D.ietf-ace-dtls-authorize] [I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS) L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls- Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-09 (work in progress), December 2019. authorize-10 (work in progress), May 2020.
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-09 (work in (CoAP)", draft-ietf-core-coap-pubsub-09 (work in
progress), September 2019. progress), September 2019.
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", draft-ietf-core-echo- Request-Tag, and Token Processing", draft-ietf-core-echo-
skipping to change at page 34, line 18 skipping to change at page 35, line 31
ACE, based on the requiremens defined in Appendix A of ACE, based on the requiremens defined in Appendix A of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
o REQ1 - Specify the encoding and value of the identifier of group, o REQ1 - Specify the encoding and value of the identifier of group,
for scope entries of 'scope': see Section 3.1 and Section 5.1. for scope entries of 'scope': see Section 3.1 and Section 5.1.
o REQ2 - Specify the encoding and value of roles, for scope entries o REQ2 - Specify the encoding and value of roles, for scope entries
of 'scope': see Section 3.1. of 'scope': see Section 3.1.
o REQ3 - if used, specify the acceptable values for 'sign_alg': o REQ3 - if used, specify the acceptable values for 'sign_alg':
values from Tables 5 and 6 of [RFC8152]. values from the "Value" column of the "COSE Algorithms" Registry
[COSE.Algorithms].
o REQ4 - If used, specify the acceptable values for o REQ4 - If used, specify the acceptable values for
'sign_parameters': values from the "Counter Signature Parameters" 'sign_parameters': values from the COSE capabilities in the "COSE
Registry (see Section 11.1 of [I-D.ietf-core-oscore-groupcomm]). Algorithms" Registry [COSE.Algorithms] and from the COSE
capabilities in the "COSE Key Types" Registry [COSE.Key.Types].
o REQ5 - If used, specify the acceptable values for o REQ5 - If used, specify the acceptable values for
'sign_key_parameters': values from the "Counter Signature Key 'sign_key_parameters': values from the COSE capabilities in the
Parameters" Registry (see Section 11.2 of "COSE Key Types" Registry [COSE.Key.Types].
[I-D.ietf-core-oscore-groupcomm]).
o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1 o REQ6 - If used, specify the acceptable values for 'pub_key_enc': 1
("COSE_Key") from the 'Confirmation Key' column of the "CWT ("COSE_Key") from the 'Confirmation Key' column of the "CWT
Confirmation Method" Registry defined in [RFC8747]. Future Confirmation Method" Registry defined in [RFC8747]. Future
specifications may define additional values for this parameter. specifications may define additional values for this parameter.
o REQ7 - Format of the 'key' value: see Section 5.4. o REQ7 - Format of the 'key' value: see Section 5.4.
o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Security_Context o REQ8 - Acceptable values of 'gkty': Group_OSCORE_Security_Context
object (see Section 5.4). object (see Section 5.4).
skipping to change at page 36, line 24 skipping to change at page 37, line 39
[I-D.ietf-ace-key-groupcomm]): see Section 15 for the eviction of [I-D.ietf-ace-key-groupcomm]): see Section 15 for the eviction of
a group member; see Section 16 for the group rekeying process. a group member; see Section 16 for the group rekeying process.
o OPT10 (Optional) - Specify how the identifier of the sender's o OPT10 (Optional) - Specify how the identifier of the sender's
public key is included in the group request: no. public key is included in the group request: no.
Appendix B. Document Updates Appendix B. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
B.1. Version -05 to -06 B.1. Version -06 to -07
o Alignments with draft-ietf-core-oscore-groupcomm.
o New format of 'sign_info', using the COSE capabilities.
o New format of Joining Response parameters, using the COSE
capabilities.
o Considerations on group rekeying.
o Editorial revision.
B.2. Version -05 to -06
o Added role of external signature verifier. o Added role of external signature verifier.
o Parameter 'rsnonce' renamed to 'kdcchallenge'. o Parameter 'rsnonce' renamed to 'kdcchallenge'.
o Parameter 'kdcchallenge' may be omitted in some cases. o Parameter 'kdcchallenge' may be omitted in some cases.
o Clarified difference between group name and OSCORE Gid. o Clarified difference between group name and OSCORE Gid.
o Removed the role combination ["requester", "monitor"]. o Removed the role combination ["requester", "monitor"].
skipping to change at page 37, line 5 skipping to change at page 38, line 35
o Possible individual rekeying of a single requesting node combined o Possible individual rekeying of a single requesting node combined
with a group rekeying. with a group rekeying.
o Security considerations on reusage of signature challenges. o Security considerations on reusage of signature challenges.
o Addressing optional requirement OPT9 from draft-ietf-ace-key- o Addressing optional requirement OPT9 from draft-ietf-ace-key-
groupcomm groupcomm
o Editorial improvements. o Editorial improvements.
B.2. Version -04 to -05 B.3. Version -04 to -05
o Nonce N_S also in error responses to the Joining Requests. o Nonce N_S also in error responses to the Joining Requests.
o Supporting single Access Token for multiple groups/topics. o Supporting single Access Token for multiple groups/topics.
o Supporting legal requesters/responders using the 'peer_roles' o Supporting legal requesters/responders using the 'peer_roles'
parameter. parameter.
o Registered and used dedicated label for TLS Exporter. o Registered and used dedicated label for TLS Exporter.
skipping to change at page 37, line 34 skipping to change at page 39, line 15
o Clarification on incrementing version number when rekeying the o Clarification on incrementing version number when rekeying the
group. group.
o Clarification on what is re-distributed with the group rekeying. o Clarification on what is re-distributed with the group rekeying.
o Security considerations on the size of the nonces used for the o Security considerations on the size of the nonces used for the
signature challenge. signature challenge.
o Added CBOR values to abbreviate role identifiers in the group. o Added CBOR values to abbreviate role identifiers in the group.
B.3. Version -03 to -04 B.4. Version -03 to -04
o New abstract. o New abstract.
o Moved general content to draft-ietf-ace-key-groupcomm o Moved general content to draft-ietf-ace-key-groupcomm
o Terminology: node name; node resource. o Terminology: node name; node resource.
o Creation and pointing at node resource. o Creation and pointing at node resource.
o Updated Group Manager API (REST methods and offered services). o Updated Group Manager API (REST methods and offered services).
skipping to change at page 38, line 4 skipping to change at page 39, line 34
o Updated Group Manager API (REST methods and offered services). o Updated Group Manager API (REST methods and offered services).
o Size of challenges 'cnonce' and 'rsnonce'. o Size of challenges 'cnonce' and 'rsnonce'.
o Value of 'rsnonce' for reused or non-traditionally-posted tokens. o Value of 'rsnonce' for reused or non-traditionally-posted tokens.
o Removed reference to RFC 7390. o Removed reference to RFC 7390.
o New requirements from draft-ietf-ace-key-groupcomm o New requirements from draft-ietf-ace-key-groupcomm
o Editorial improvements. o Editorial improvements.
B.4. Version -02 to -03 B.5. Version -02 to -03
o New sections, aligned with the interface of ace-key-groupcomm . o New sections, aligned with the interface of ace-key-groupcomm .
o Exchange of information on the countersignature algorithm and o Exchange of information on the countersignature algorithm and
related parameters, during the Token POST (Section 4.1). related parameters, during the Token POST (Section 4.1).
o Nonce 'rsnonce' from the Group Manager to the Client o Nonce 'rsnonce' from the Group Manager to the Client
(Section 4.1). (Section 4.1).
o Client PoP signature in the Key Distribution Request upon joining o Client PoP signature in the Key Distribution Request upon joining
skipping to change at page 38, line 29 skipping to change at page 40, line 12
o Local actions on the Group Manager, upon a new node's joining o Local actions on the Group Manager, upon a new node's joining
(Section 4.2). (Section 4.2).
o Local actions on the Group Manager, upon a node's leaving o Local actions on the Group Manager, upon a node's leaving
(Section 12). (Section 12).
o IANA registration in ACE Groupcomm Parameters Registry. o IANA registration in ACE Groupcomm Parameters Registry.
o More fulfilled profile requirements (Appendix A). o More fulfilled profile requirements (Appendix A).
B.5. Version -01 to -02 B.6. Version -01 to -02
o Editorial fixes. o Editorial fixes.
o Changed: "listener" to "responder"; "pure listener" to "monitor". o Changed: "listener" to "responder"; "pure listener" to "monitor".
o Changed profile name to "coap_group_oscore_app", to reflect it is o Changed profile name to "coap_group_oscore_app", to reflect it is
an application profile. an application profile.
o Added the 'type' parameter for all requests to a Join Resource. o Added the 'type' parameter for all requests to a Join Resource.
skipping to change at page 39, line 20 skipping to change at page 41, line 5
o Extended security considerations: proof-of-possession of signature o Extended security considerations: proof-of-possession of signature
keys; collision of OSCORE Group Identifiers (Section 8). keys; collision of OSCORE Group Identifiers (Section 8).
o Registered three entries in the IANA Registry "Sequence Number o Registered three entries in the IANA Registry "Sequence Number
Synchronization Method Registry" (Section 9). Synchronization Method Registry" (Section 9).
o Registered one public key encoding in the "ACE Public Key o Registered one public key encoding in the "ACE Public Key
Encoding" IANA Registry (Section 9). Encoding" IANA Registry (Section 9).
B.6. Version -00 to -01 B.7. Version -00 to -01
o Changed name of 'req_aud' to 'audience' in the Authorization o Changed name of 'req_aud' to 'audience' in the Authorization
Request (Section 3.1). Request (Section 3.1).
o Added negotiation of countersignature algorithm/parameters between o Added negotiation of countersignature algorithm/parameters between
Client and Group Manager (Section 4). Client and Group Manager (Section 4).
o Updated format of the Key Distribution Response as a whole o Updated format of the Key Distribution Response as a whole
(Section 4.3). (Section 4.3).
 End of changes. 52 change blocks. 
116 lines changed or deleted 188 lines changed or added

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