draft-ietf-ace-key-groupcomm-oscore-00.txt   draft-ietf-ace-key-groupcomm-oscore-01.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: June 23, 2019 Universitaet Duisburg-Essen Expires: September 9, 2019 Universitaet Duisburg-Essen
F. Palombini F. Palombini
Ericsson AB Ericsson AB
December 20, 2018 March 08, 2019
Key Management for OSCORE Groups in ACE Key Management for OSCORE Groups in ACE
draft-ietf-ace-key-groupcomm-oscore-00 draft-ietf-ace-key-groupcomm-oscore-01
Abstract Abstract
This document describes a method to request and provision keying This document describes a method to request and provision keying
material in group communication scenarios where communications are material in group communication scenarios where communications are
based on CoAP and secured with Object Security for Constrained based on CoAP and secured with Object Security for Constrained
RESTful Environments (OSCORE). The proposed method delegates the RESTful Environments (OSCORE). The proposed method delegates the
authentication and authorization of new client nodes that join an authentication and authorization of new client nodes that join an
OSCORE group through a Group Manager server. This approach builds on OSCORE group through a Group Manager server. This approach builds on
the ACE framework for Authentication and Authorization, and leverages the ACE framework for Authentication and Authorization, and leverages
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 June 23, 2019. This Internet-Draft will expire on September 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Relation to Other Documents . . . . . . . . . . . . . . . 5 1.2. Relation to Other Documents . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Overview of the Join Process . . . . . . . . . . . . . . 7 2.1. Overview of the Join Process . . . . . . . . . . . . . . 7
2.2. Overview of the Group Rekeying Process . . . . . . . . . 7 2.2. Overview of the Group Rekeying Process . . . . . . . . . 8
3. Joining Node to Authorization Server . . . . . . . . . . . . 8 3. Joining Node to Authorization Server . . . . . . . . . . . . 8
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 8 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 8
3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 3.2. Authorization Response . . . . . . . . . . . . . . . . . 9
4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 10 4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 10
4.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. 'key info' Parameter . . . . . . . . . . . . . . . . 11
5. Leaving of a Group Member . . . . . . . . . . . . . . . . . . 12 4.2. Join Request . . . . . . . . . . . . . . . . . . . . . . 11
6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 12 4.3. Join Response . . . . . . . . . . . . . . . . . . . . . . 12
7. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 14 5. Leaving of a Group Member . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 16 9.1. ACE Authorization Server Request Creation Hints Registry 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 9.3. OSCORE Security Context Parameters Registry . . . . . . . 18
9.4. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Document Updates . . . . . . . . . . . . . . . . . . 20
A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
[I-D.ietf-core-object-security] is a method for application-layer [I-D.ietf-core-object-security] is a method for application-layer
protection of the Constrained Application Protocol (CoAP) [RFC7252], protection of the Constrained Application Protocol (CoAP) [RFC7252],
using CBOR Object Signing and Encryption (COSE) [RFC8152] and using CBOR Object Signing and Encryption (COSE) [RFC8152] 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], OSCORE may be used As described in [I-D.ietf-core-oscore-groupcomm], OSCORE may be used
skipping to change at page 3, line 23 skipping to change at page 3, line 31
o Renew the group keying material and distribute it to the OSCORE o Renew the group keying material and distribute it to the OSCORE
group (rekeying) upon changes in the group membership. group (rekeying) upon changes in the group membership.
A client node joins an OSCORE group through a resource server acting A client node joins an OSCORE group through a resource server acting
as Group Manager for that group. The join process relies on an as Group Manager for that group. The join process relies on an
Access Token, which is bound to a proof-of-possession key and Access Token, which is bound to a proof-of-possession key and
authorizes the client to access a specific join resource at the Group authorizes the client to access a specific join resource at the Group
Manager. Manager.
Messages exchanged among the participants follow the formats defined Messages exchanged among the participants follow the formats defined
in [I-D.palombini-ace-key-groupcomm] for provisioning and renewing in [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying
keying material in group communication scenarios. material in group communication scenarios.
In order to achieve communication security, proof-of-possession and In order to achieve communication security, proof-of-possession and
server authentication, the client and the Group Manager leverage server authentication, the client and the Group Manager leverage
protocol-specific profiles of ACE. These include also possible protocol-specific profiles of ACE. These include also possible
forthcoming profiles that comply with the requirements in Appendix C forthcoming profiles that comply with the requirements in Appendix C
of [I-D.ietf-ace-oauth-authz]. of [I-D.ietf-ace-oauth-authz].
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",
skipping to change at page 5, line 17 skipping to change at page 5, line 23
Figure 1 overviews the main documents related to this specification. Figure 1 overviews the main documents related to this specification.
Arrows and asterisk-arrows denote normative references and Arrows and asterisk-arrows denote normative references and
informative refences, respectively. informative refences, respectively.
+---------------------------------------+ +---------------------------------------+
| | | |
+----------------|--------------+ | +----------------|--------------+ |
| | | | | | | |
| v v Key Management | v v Key Management
Pub-sub ---> Key Groupcomm ---> ACE Framework <--- for OSCORE Groups Pub-sub ---> Key Groupcomm ---> ACE Framework <--- for OSCORE Groups
profile * * [[WG]] [[This document]] profile * [[WG]] [[WG]] [[This document]]
| * * ^ ^ | | | * * ^ ^ | |
| * * * * | | | * * * * | |
| * * * *************** | | | * * * *************** | |
| ************ * * * | | | *********** * * * | |
| * * * * +--------------+ | | * * * * +--------------+ |
ACE | * * * * | | ACE | * * * * | |
-----|-*--------------*--------------*-*-|--------------------|------- -----|-*--------------*--------------*-*-|--------------------|-------
CoRE | * * * * | | CoRE | * * * * | |
v v v * * v v v v v * * v v
CoRE CoRE OSCORE -------------> OSCORE CoRE CoRE OSCORE -------------> OSCORE
Pubsub Groupcomm <*** Groupcomm <************* [[WG]] Pubsub Groupcomm <*** Groupcomm <************* [[WG]]
[[WG]] [[RFC7390]] [[WG]] [[WG]] [[RFC7390]] [[WG]]
Figure 1: Related Documents Figure 1: Related Documents
skipping to change at page 7, line 9 skipping to change at page 7, line 14
instance using DTLS [RFC6347] or OSCORE instance using DTLS [RFC6347] or OSCORE
[I-D.ietf-core-object-security]. Further details on how the AS [I-D.ietf-core-object-security]. Further details on how the AS
secures communications (with the joining node and the Group Manager) secures communications (with the joining node and the Group Manager)
depend on the specifically used profile of ACE, and are out of the depend on the specifically used profile of ACE, and are out of the
scope of this specification. scope of this specification.
2.1. Overview of the Join Process 2.1. Overview of the Join Process
A node performs the following steps in order to join an OSCORE group. A node performs the following steps in order to join an OSCORE group.
Messages exchanged among the participants follow the formats defined Messages exchanged among the participants follow the formats defined
in [I-D.palombini-ace-key-groupcomm], and are further specified in in [I-D.ietf-ace-key-groupcomm], and are further specified in
Section 3 and Section 4 of this document. The Group Manager acts as Section 3 and Section 4 of this document. The Group Manager acts as
the Key Distribution Center (KDC) defined in the Key Distribution Center (KDC) defined in
[I-D.palombini-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
1. The joining node requests an Access Token from the AS, in order 1. The joining node requests an Access Token from the AS, in order
to access a join resource on the Group Manager and hence join the to access a join resource on the Group Manager and hence join the
associated OSCORE group (see Section 3). The joining node will associated OSCORE group (see Section 3). The joining node will
start or continue using a secure communication channel with the start or continue using a secure communication channel with the
Group Manager, according to the response from the AS. Group Manager, according to the response from the AS.
2. The joining node transfers authentication and authorization 2. The joining node transfers authentication and authorization
information to the Group Manager by posting the obtained Access information to the Group Manager by posting the obtained Access
Token (see Section 4). After that, a joining node must have a Token (see Section 4). After that, a joining node must have a
skipping to change at page 8, line 26 skipping to change at page 8, line 36
3. Joining Node to Authorization Server 3. Joining Node to Authorization Server
This section describes how the joining node interacts with the AS in This section describes how the joining node interacts with the AS in
order to be authorized to join an OSCORE group under a given Group order to be authorized to join an OSCORE group under a given Group
Manager. In particular, it considers a joining node that intends to Manager. In particular, it considers a joining node that intends to
contact that Group Manager for the first time. contact that Group Manager for the first time.
The message exchange between the joining node and the AS consists of The message exchange between the joining node and the AS consists of
the messages Authorization Request and Authorization Response defined the messages Authorization Request and Authorization Response defined
in Section 3 of [I-D.palombini-ace-key-groupcomm]. in Section 3 of [I-D.ietf-ace-key-groupcomm].
In case the specific AS associated to the Group Manager is unknown to In case the specific AS associated to the Group Manager is unknown to
the joining node, the latter can rely on mechanisms like the the joining node, the latter can rely on mechanisms like the
Unauthorized Resource Request message described in Section 5.1.1 of Unauthorized Resource Request message described in Section 5.1.1 of
[I-D.ietf-ace-oauth-authz] to discover the correct AS to contact. [I-D.ietf-ace-oauth-authz] to discover the correct AS to contact.
3.1. Authorization Request 3.1. Authorization Request
The joining node contacts the AS, in order to request an Access Token The joining node contacts the AS, in order to request an Access Token
for accessing the join resource hosted by the Group Manager and for accessing the join resource hosted by the Group Manager and
associated to the OSCORE group. The Access Token request sent to the associated to the OSCORE group. The Access Token request sent to the
/token endpoint follows the format of the Authorization Request /token endpoint follows the format of the Authorization Request
message defined in Section 3.1 of [I-D.palombini-ace-key-groupcomm]. message defined in Section 3.1 of [I-D.ietf-ace-key-groupcomm]. In
In particular: particular:
o The 'scope' parameter MUST be present and MUST include: o The 'scope' parameter MUST be present and MUST include:
* in the first element, either the Group Identifier (Gid) of the * in the first element, either the Group Identifier (Gid) of the
group to join under the Group Manager, or a value from which group to join under the Group Manager, or a value from which
the Group Manager can derive the Gid of the group to join. It the Group Manager can derive the Gid of the group to join. It
is up to the application to define how the Group Manager is up to the application to define how the Group Manager
possibly performs the derivation of the full Gid. Appendix C of possibly performs the derivation of the full Gid. Appendix C of
[I-D.ietf-core-oscore-groupcomm] provides an example of [I-D.ietf-core-oscore-groupcomm] provides an example of
structured Gid, composed of a fixed part, namely Group Prefix, structured Gid, composed of a fixed part, namely Group Prefix,
and a variable part, namely Group Epoch. and a variable part, namely Group Epoch.
* in the second element, the role(s) that the joining node * in the second element, the role(s) that the joining node
intends to have in the group it intends to join. Possible intends to have in the group it intends to join. Possible
values are: "requester"; "listener"; and "pure listener". values are: "requester"; "listener"; and "pure listener".
Possible combinations are: ["requester" , "listener"]; Possible combinations are: ["requester" , "listener"];
["requester" , "pure listener"]. ["requester" , "pure listener"].
o The 'req_aud' parameter MUST be present and is set to the o The 'audience' parameter MUST be present and is set to the
identifier of the Group Manager. identifier of the Group Manager.
3.2. Authorization Response 3.2. Authorization Response
The AS is responsible for authorizing the joining node to join The AS is responsible for authorizing the joining node to join
specific OSCORE groups, according to join policies enforced on behalf specific OSCORE groups, according to join policies enforced on behalf
of the respective Group Manager. of the respective Group Manager.
In case of successful authorization, the AS releases an Access Token In case of successful authorization, the AS releases an Access Token
bound to a proof-of-possession key associated to the joining node. bound to a proof-of-possession key associated to the joining node.
Then, the AS provides the joining node with the Access Token as part Then, the AS provides the joining node with the Access Token as part
of an Access Token response, which follows the format of the of an Access Token response, which follows the format of the
Authorization Response message defined in Section 3.2 of Authorization Response message defined in Section 3.2 of
[I-D.palombini-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
The 'exp' parameter MUST be present. Other means for the AS to The 'exp' parameter MUST be present. Other means for the AS to
specify the lifetime of Access Tokens are out of the scope of this specify the lifetime of Access Tokens are out of the scope of this
specification. specification.
The AS must include the 'scope' parameter in the response when the The AS must include the 'scope' parameter in the response when the
value included in the Access Token differs from the one specified by value included in the Access Token differs from the one specified by
the joining node in the request. In such a case, the second element the joining node in the request. In such a case, the second element
of 'scope' MUST be present and includes the role(s) that the joining of 'scope' MUST be present and includes the role(s) that the joining
node is actually authorized to take in the group, encoded as node is actually authorized to take in the group, encoded as
skipping to change at page 10, line 7 skipping to change at page 10, line 17
the joining node in the 'cnf' parameter of the Access Token response. the joining node in the 'cnf' parameter of the Access Token response.
Instead, if asymmetric keys are used, the joining node provides its Instead, if asymmetric keys are used, the joining node provides its
own public key to the AS in the 'req_cnf' parameter of the Access own public key to the AS in the 'req_cnf' parameter of the Access
Token request. Then, the AS uses it as proof-of-possession key bound Token request. Then, the AS uses it as proof-of-possession key bound
to the Access Token, and provides the joining node with the Group to the Access Token, and provides the joining node with the Group
Manager's public key in the 'rs_cnf' parameter of the Access Token Manager's public key in the 'rs_cnf' parameter of the Access Token
response. response.
4. Joining Node to Group Manager 4. Joining Node to Group Manager
First, the joining node posts the Access Token to the /authz-info The following subsections describe the interactions between the
endpoint at the Group Manager, in accordance with the Token post joining node and the Group Manager, i.e. the Access Token post and
defined in Section 3.3 of [I-D.palombini-ace-key-groupcomm]. Then, the Request-Response exchange to join the OSCORE group.
the joining node establishes a secure channel with the Group Manager,
according to what is specified in the Access Token response and to
the signalled profile of ACE.
4.1. Join Request 4.1. Token Post
The joining node posts the Access Token to the /authz-info endpoint
at the Group Manager, according to the Token post defined in
Section 3.3 of [I-D.ietf-ace-key-groupcomm].
If the joining node is not aware of the countersignature algorithm
and related parameters used in the OSCORE group, it may want to get
that information from the Group Manager. In such a case, the CoAP
POST request uses the Content-Format "application/ace+cbor" defined
in Section 8.14 of [I-D.ietf-ace-oauth-authz], and includes also the
parameter 'key info' defined in Section 4.1.1 and registered in
Section 9.1, encoding the CBOR simple value Null. Alternatively, the
joining node may retrieve that information by other means, e.g. by
using the approach described in [I-D.tiloca-core-oscore-discovery].
If the Access Token is valid, the Group Manager responds to the POST
request with a 2.01 (Created) response, according to what is
specified in the signalled profile of ACE.
The payload of the 2.01 (Created) response MAY be a CBOR map
including a 'key info' parameter, which MUST be present if the POST
request included the 'key info' parameter with value Null. If
present, the 'key info' parameter of the 2.01 (Created) response is a
CBOR array formatted as follows:
o The first element is an integer or a text string, indicating the
counter signature algorithm used in the OSCORE group. This
parameter takes values from Tables 5 and 6 of [RFC8152].
o The second element indicates the parameters of the counter
signature algorithm. Its structure depends on the value of the
first element, and is defined in the Counter Signature Parameters
Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]).
This parameter MUST be omitted if there are no parameters for that
algorithm value.
The CDDL notation of the 'key info' parameter is given below.
key_info = [
sign_alg : int / tstr,
? sign_parameters : any
]
Finally, the joining node establishes a secure channel with the Group
Manager, according to what is specified in the Access Token response
and the signalled profile of ACE.
4.1.1. 'key info' Parameter
The 'key info' parameter is an OPTIONAL parameter of the AS Request
Creation Hints message defined in Section 5.1.2. of
[I-D.ietf-ace-oauth-authz]. This parameter contains information
about the key to be used in the security association between the
Client and the RS. Its format is application specific.
4.2. Join Request
Once a secure communication channel with the Group Manager has been Once a secure communication channel with the Group Manager has been
established, the joining node requests to join the OSCORE group, by established, the joining node requests to join the OSCORE group, by
accessing the related join resource at the Group Manager. accessing the related join resource at the Group Manager.
In particular, the joining node sends to the Group Manager a In particular, the joining node sends to the Group Manager a
confirmable CoAP request, using the method POST and targeting the confirmable CoAP request, using the method POST and targeting the
join endpoint associated to that group. This join request follows join endpoint associated to that group. This join request follows
the format and processing of the Key Distribution Request message the format and processing of the Key Distribution Request message
defined in Section 4.1 of [I-D.palombini-ace-key-groupcomm]. In defined in Section 4.1 of [I-D.ietf-ace-key-groupcomm]. In
particular: particular:
o The 'get_pub_keys' parameter is present only if the joining node o The 'get_pub_keys' parameter is present only if the joining node
wants to retrieve the public keys of the group members from the wants to retrieve the public keys of the group members from the
Group Manager during the join process (see Section 6). Otherwise, Group Manager during the join process (see Section 6). Otherwise,
this parameter MUST NOT be present. this parameter MUST NOT be present.
o The 'client_cred' parameter, if present, includes the public key o The 'client_cred' parameter, if present, includes the public key
of the joining node. This parameter MAY be omitted if: i) public of the joining node. In case the joining node knows the
keys are used as proof-of-possession keys between the joining node countersignature algorithm and possible associated parameters used
and the Group Manager; or ii) the joining node is asking to access in the OSCORE group, the included public key MUST be in a
the group exclusively as pure listener; or iii) the Group Manager consistent format. This parameter MAY be omitted if: i) the
already acquired this information during a previous join process. joining node is asking to access the group exclusively as pure
In any other case, this parameter MUST be present. listener; or ii) the Group Manager already acquired this
information, for instance during a previous join process. In any
other case, this parameter MUST be present.
4.2. Join Response 4.3. Join Response
The Group Manager processes the request according to The Group Manager processes the request according to
[I-D.ietf-ace-oauth-authz]. If this yields a positive outcome, the [I-D.ietf-ace-oauth-authz] and Section 4.2 of
Group Manager updates the group membership by registering the joining [I-D.ietf-ace-key-groupcomm]. If this yields a positive outcome, the
node as a new member of the OSCORE group. Group Manager performs the following check. In case the Join Request
included the 'client_cred' parameter, the Group Manager checks that
the public key of the joining node is consistent with the counter
signature algorithm and possible associated parameters used in the
OSCORE group.
The Group Manager replies to the joining node providing the updated If the public key of the joining node does not have an accepted
security parameters and keying meterial necessary to participate in format, the Group Manager MUST reply to the joining node with a 2.01
the group communication. This join response follows the format and (Created) response. The payload of this response is a CBOR map,
processing of the Key Distribution success Response message defined which includes a 'key info' parameter formatted as in the Token POST
in Section 4.2 of [I-D.palombini-ace-key-groupcomm]. In particular: response in Section 4.1. Upon receiving this response, the joining
node SHOULD send a new Join Request to the Group Manager, with the
'client_cred' parameter including its own public key in a format
consistent with the countersignature algorithm and possible
associated parameters indicated by the Group Manager.
Otherwise, the Group Manager updates the group membership by
registering the joining node as a new member of the OSCORE group.
Then, the Group Manager replies to the joining node providing the
updated security parameters and keying meterial necessary to
participate in the group communication. This join response follows
the format and processing of the Key Distribution success Response
message defined in Section 4.2 of [I-D.ietf-ace-key-groupcomm]. In
particular:
o The 'kty' parameter identifies a key of type
"Group_OSCORE_Security_Context object", defined in Section 9.2 of
this specification.
o The 'key' parameter includes what the joining node needs in order o The 'key' parameter includes what the joining node needs in order
to set up the OSCORE Security Context as per Section 2 of to set up the OSCORE Security Context as per Section 2 of
[I-D.ietf-core-oscore-groupcomm]. In particular: [I-D.ietf-core-oscore-groupcomm]. This parameter includes a
Group_OSCORE_Security_Context object, which is defined in this
specification and extends the OSCORE_Security_Context object
encoded in CBOR as defined in Section 3.2.1 of
[I-D.ietf-ace-oscore-profile]. In particular, it contains the
additional parameters 'cs_alg' and 'cs_params' defined in
Section 9.3 of this specification. More specifically, the 'key'
parameter is composed as follows.
* The 'kty' parameter has value "Symmetric". * The 'ms' parameter MUST be present and includes the OSCORE
Master Secret value.
* The 'k' parameter includes the OSCORE Master Secret. * The 'clientId' parameter, if present, has as value the OSCORE
Sender ID assigned to the joining node by the Group Manager.
This parameter is not present if the node joins the group
exclusively as pure listener, according to what specified in
the Access Token (see Section 3.2). In any other case, this
parameter MUST be present.
* The 'exp' parameter specifies when the OSCORE Security Context * The 'hkdf' parameter, if present, has as value the KDF
derived from these parameters expires. algorithm used in the group.
* The 'alg' parameter, if present, has as value the AEAD * The 'alg' parameter, if present, has as value the AEAD
algorithm used in the group. algorithm used in the group.
* The 'kid' parameter, if present, has as value the identifier of * The 'salt' parameter, if present, has as value the OSCORE
the key in the parameter 'k'. Master Salt.
* The 'base IV' parameter, if present, has as value the OSCORE * The 'contextId' parameter MUST be present and has as value the
Common IV. Group Identifier (Gid) associated to the OSCORE group.
* The 'clientID' parameter, if present, has as value the OSCORE * The 'rpl' parameter, if present, specifies the OSCORE Replay
Sender ID assigned to the joining node by the Group Manager. Window Size and Type value.
This parameter is not present if the node joins the group
exclusively as pure listener, according to what specified in
the Access Token (see Section 3.2). In any other case, this
parameter MUST be present.
* The 'serverID' parameter MUST be present and has as value the * The 'cs_alg' parameter MUST be present and specifies the
Group Identifier (Gid) associated to the group. algorithm used to countersign messages in the group. This
parameter takes values from Tables 5 and 6 of [RFC8152].
* The 'kdf' parameter, if present, has as value the KDF algorithm * The 'cs_params' parameter MAY be present and specifies the
used in the group. additional parameters for the counter signature algorithm.
This parameter is encoded as specified in Section 2 of
[I-D.ietf-core-oscore-groupcomm].
* The 'slt' parameter, if present, has as value the OSCORE Master o The 'profile' parameter MUST be present and has value
Salt. "coap_group_oscore", which is defined in Section 9.4 of this
specification.
* The 'cs_alg' parameter MUST be present and has as value the o The 'exp' parameter MUST be present and specifies the expiration
countersignature algorithm used in the group. time in seconds after which the OSCORE Security Context derived
from the 'key' parameter is not valid anymore.
o The 'pub_keys' parameter is present only if the 'get_pub_keys' o The 'pub_keys' parameter is present only if the 'get_pub_keys'
parameter was present in the join request. If present, this parameter was present in the join request. If present, this
parameter includes the public keys of the group members that are parameter includes the public keys of the group members that are
relevant to the joining node. That is, it includes: i) the public relevant to the joining node. That is, it includes: i) the public
keys of the non-pure listeners currently in the group, in case the keys of the non-pure listeners currently in the group, in case the
joining node is configured (also) as requester; and ii) the public joining node is configured (also) as requester; and ii) the public
keys of the requesters currently in the group, in case the joining keys of the requesters currently in the group, in case the joining
node is configured (also) as listener or pure listener. node is configured (also) as listener or pure listener.
skipping to change at page 12, line 21 skipping to change at page 14, line 26
Finally, the joining node uses the information received in the join Finally, the joining node uses the information received in the join
response to set up the OSCORE Security Context, as described in response to set up the OSCORE Security Context, as described in
Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the
joining node can exchange group messages secured with OSCORE as joining node can exchange group messages secured with OSCORE as
described in [I-D.ietf-core-oscore-groupcomm]. described in [I-D.ietf-core-oscore-groupcomm].
If the application requires backward security, the Group Manager If the application requires backward security, the Group Manager
SHALL generate updated security parameters and group keying material, SHALL generate updated security parameters and group keying material,
and provide it to all the current group members (see Section 7). and provide it to all the current group members (see Section 7).
When the OSCORE Master Secret expires, as specified by 'exp' in the When the OSCORE Security Context expires, as specified by the 'exp'
'key' parameter of the join response, the node considers the OSCORE parameter of the join response, the node considers it invalid and to
Security Context also invalid and to be renewed. Then, the node be renewed. Then, the node retrieves updated security parameters and
retrieves updated security parameters and keying material, by keying material, by exchanging shortened Join Request and Join
exchanging shortened Join Request and Join Response messages with the Response messages with the Group Manager, according to the approach
Group Manager, according to the approach defined in Section 6 of defined in Section 6 of [I-D.ietf-ace-key-groupcomm]. Finally, the
[I-D.palombini-ace-key-groupcomm]. Finally, the node uses the node uses the updated security parameters and keying material to set
updated security parameters and keying material to set up the new up the new OSCORE Security Context as described in Section 2 of
OSCORE Security Context as described in Section 2 of
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
5. Leaving of a Group Member 5. Leaving of a Group Member
A node may be removed from the OSCORE group, due to expired or A node may be removed from the OSCORE group, due to expired or
revoked authorization, or after its own request to the Group Manager. revoked authorization, or after its own request to the Group Manager.
If the application requires forward security, the Group Manager SHALL If the application requires forward security, the Group Manager SHALL
generate updated security parameters and group keying material, and generate updated security parameters and group keying material, and
provide it to the remaining group members (see Section 7). The provide it to the remaining group members (see Section 7). The
leaving node must not be able to acquire the new security parameters leaving node must not be able to acquire the new security parameters
and group keying material distributed after its leaving. and group keying material distributed after its leaving.
Same considerations in Section 5 of [I-D.palombini-ace-key-groupcomm] Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm]
apply here as well, considering the Group Manager acting as KDC. In apply here as well, considering the Group Manager acting as KDC. In
particular, a node requests to leave the OSCORE group as described in particular, a node requests to leave the OSCORE group as described in
Section 5.2 of [I-D.palombini-ace-key-groupcomm]. Section 5.2 of [I-D.ietf-ace-key-groupcomm].
6. Public Keys of Joining Nodes 6. Public Keys of Joining Nodes
Source authentication of OSCORE messages exchanged within the group Source authentication of OSCORE messages exchanged within the group
is ensured by means of digital counter signatures (see Sections 2 and is ensured by means of digital counter signatures (see Sections 2 and
3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members 3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members
must be able to retrieve each other's public key from a trusted key must be able to retrieve each other's public key from a trusted key
repository, in order to verify source authenticity of incoming group repository, in order to verify source authenticity of incoming group
messages. messages.
skipping to change at page 13, line 38 skipping to change at page 15, line 44
possession key to establish a secure communication channel. In possession key to establish a secure communication channel. In
this case, the Group Manager stores the proof-of-possession key this case, the Group Manager stores the proof-of-possession key
conveyed in the Access Token as the public key of the joining conveyed in the Access Token as the public key of the joining
node. node.
o The joining node and the Group Manager use a symmetric proof-of- o The joining node and the Group Manager use a symmetric proof-of-
possession key to establish a secure communication channel. In possession key to establish a secure communication channel. In
this case, upon performing a join process with that Group Manager this case, upon performing a join process with that Group Manager
for the first time, the joining node specifies its own public key for the first time, the joining node specifies its own public key
in the 'client_cred' parameter of the join request targeting the in the 'client_cred' parameter of the join request targeting the
join endpoint (see Section 4.1). join endpoint (see Section 4.2).
Furthermore, as described in Section 4.1, the joining node may have Furthermore, as described in Section 4.2, the joining node may have
explicitly requested the Group Manager to retrieve the public keys of explicitly requested the Group Manager to retrieve the public keys of
the current group members, i.e. through the 'get_pub_keys' parameter the current group members, i.e. through the 'get_pub_keys' parameter
in the join request. In this case, the Group Manager includes also in the join request. In this case, the Group Manager includes also
such public keys in the 'pub_keys' parameter of the join response such public keys in the 'pub_keys' parameter of the join response
(see Section 4.2). (see Section 4.3).
Later on as a group member, the node may need to retrieve the public Later on as a group member, the node may need to retrieve the public
keys of other group members. The node can do that by exchanging keys of other group members. The node can do that by exchanging
shortened Join Request and Join Response messages with the Group shortened Join Request and Join Response messages with the Group
Manager, according to the approach defined in Section 7 of Manager, according to the approach defined in Section 7 of
[I-D.palombini-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
7. Group Rekeying Process 7. 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 ID of the group and a new OSCORE Master Secret for that new Group ID of the group and a new OSCORE Master Secret for that
group. To this end, the Group Manager MUST support at least the group. To this end, the Group Manager MUST support at least the
following group rekeying scheme. Future application profiles may following group rekeying scheme. Future application profiles may
define alternative message formats and distribution schemes. define alternative message formats and distribution schemes.
The Group Manager uses the same format of the Join Response message The Group Manager uses the same format of the Join Response message
in Section 4.2. In particular: in Section 4.3. In particular:
o Only the 'key' parameter is present. o Only the parameters 'kty', 'key', 'profile' and 'exp' are present.
o The 'k' parameter of the 'key' parameter includes the new OSCORE o The 'ms' parameter of the 'key' parameter specifies the new OSCORE
Master Secret. Master Secret value.
o The 'serverID' parameter of the 'key' parameter includes the new o The 'contextId' parameter of the 'key' parameter specifies the new
Group ID. Group ID.
The Group Manager separately sends a group rekeying message to each The Group Manager separately sends a group rekeying message to each
group member to be rekeyed. Each rekeying message MUST be secured group member to be rekeyed. Each rekeying message MUST be secured
with the pairwise secure communication channel between the Group with the pairwise secure communication channel between the Group
Manager and the group member used during the join process. Manager and the group member used during the join process.
8. Security Considerations 8. Security Considerations
The method described in this document leverages the following The method described in this document leverages the following
skipping to change at page 15, line 13 skipping to change at page 17, line 18
[I-D.ietf-core-oscore-groupcomm]). This concerns how a listener [I-D.ietf-core-oscore-groupcomm]). This concerns how a listener
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 join response, the Group Manager should verify Before sending the join response, the Group Manager should verify
that the joining node actually owns the associated private key, for that the joining node actually owns the associated private key, for
instance by performing a proof-of-possession challenge-response, instance by performing a proof-of-possession challenge-response,
whose details are out of the scope of this specification. whose details are out of the scope of this specification.
Further security considerations are inherited from Further security considerations are inherited from
[I-D.palombini-ace-key-groupcomm], the ACE framework for [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication
Authentication and Authorization [I-D.ietf-ace-oauth-authz], and the and Authorization [I-D.ietf-ace-oauth-authz], and the specific
specific profile of ACE signalled by the AS, such as 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].
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. Note to RFC Editor: Please replace all occurrences of "[[This
specification]]" with the RFC number of this specification and delete
this paragraph.
This document has the following actions for IANA.
9.1. ACE Authorization Server Request Creation Hints Registry
IANA is asked to register the following entry in the "ACE
Authorization Server Request Creation Hints" Registry defined in
Section 8.1 of [I-D.ietf-ace-oauth-authz].
o Name: key info
o CBOR Key: TBD (range -256 to 255)
o Value Type: any
o Reference: [[This specification]]
9.2. ACE Groupcomm Key Registry
IANA is asked to register the following entry in the "ACE Groupcomm
Key" Registry defined in Section 9.1 of [I-D.ietf-ace-key-groupcomm].
o Name: Group_OSCORE_Security_Context object
o Key Type Value: TBD
o Profile: "coap_group_oscore", defined in Section 9.4 of this
specification.
o Description: A Group_OSCORE_Security_Context object encoded as
described in Section 4.3 of this specification.
o Reference: [[This specification]]
9.3. OSCORE Security Context Parameters Registry
IANA is asked to register the following entries in the "OSCORE
Security Context Parameters" Registry defined in Section 9.2 of
[I-D.ietf-ace-oscore-profile].
o Name: cs_alg
o CBOR Label: TBD
o CBOR Type: tstr / int
o Registry: COSE Algorithm Values (ECDSA, EdDSA)
o Description: OSCORE Counter Signature Algorithm Value
o Reference: [[This specification]]
o Name: cs_params
o CBOR Label: TBD
o CBOR Type: bstr
o Registry: Counter Signatures Parameters
o Description: OSCORE Counter Signature Algorithm Additional
Parameters
o Reference: [[This specification]]
9.4. ACE Groupcomm Profile Registry
IANA is asked to register the following entry in the "ACE Groupcomm
Profile" Registry defined in Section 9.2 of
[I-D.ietf-ace-key-groupcomm].
o Name: coap_group_oscore
o Description: Profile to provision keying material for
participating in group communication protected with Group OSCORE
as per [I-D.ietf-core-oscore-groupcomm].
o CBOR Value: TBD
o Reference: [[This specification]]
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-key-groupcomm]
Palombini, F. and M. Tiloca, "Key Provisioning for Group
Communication using ACE", draft-ietf-ace-key-groupcomm-00
(work in progress), December 2018.
[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-17 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22
(work in progress), November 2018. (work in progress), March 2019.
[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-05 (work in progress), November 2018. oscore-profile-07 (work in progress), February 2019.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-15 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), August 2018. progress), March 2019.
[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-03 (work in progress), draft-ietf-core-oscore-groupcomm-03 (work in progress),
October 2018. October 2018.
[I-D.palombini-ace-key-groupcomm]
Palombini, F. and M. Tiloca, "Key Provisioning for Group
Communication using ACE", draft-palombini-ace-key-
groupcomm-02 (work in progress), October 2018.
[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>.
[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>.
skipping to change at page 16, line 31 skipping to change at page 20, line 21
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>.
10.2. Informative References 10.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-05 (work in progress), October 2018. authorize-06 (work in progress), February 2019.
[I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE
Groups with the CoRE Resource Directory", draft-tiloca-
core-oscore-discovery-01 (work in progress), January 2019.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390, the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014, DOI 10.17487/RFC7390, October 2014,
<https://www.rfc-editor.org/info/rfc7390>. <https://www.rfc-editor.org/info/rfc7390>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
Appendix A. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION.
A.1. Version -00 to -01
o Changed name of 'req_aud' to 'audience' in the Authorization
Request (Section 3.1).
o Added negotiation of countersignature algorithm/parameters between
Client and Group Manager (Section 4).
o Updated format of the Key Distribution Response as a whole
(Section 4.3).
o Added parameter 'cs_params' in the 'key' parameter of the Key
Distribution Response (Section 4.3).
o New IANA registrations in the "ACE Authorization Server Request
Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE
Security Context Parameters" Registry and "ACE Groupcomm Profile"
Registry (Section 9).
Acknowledgments Acknowledgments
The authors sincerely thank Santiago Aragon, Stefan Beck, Martin The authors sincerely thank Santiago Aragon, Stefan Beck, Martin
Gunnarsson, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van Gunnarsson, Rikard Hoeglund, Jim Schaad, Ludwig Seitz, Goeran
der Stok for their comments and feedback. Selander and Peter van der Stok for their comments and feedback.
The work on this document has been partly supported by the EIT- The work on this document has been partly supported by VINNOVA and
Digital High Impact Initiative ACTIVE. the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact
Initiative ACTIVE.
Authors' Addresses Authors' Addresses
Marco Tiloca Marco Tiloca
RISE AB RISE AB
Isafjordsgatan 22 Isafjordsgatan 22
Kista SE-164 29 Stockholm Kista SE-164 29 Stockholm
Sweden Sweden
Email: marco.tiloca@ri.se Email: marco.tiloca@ri.se
 End of changes. 55 change blocks. 
117 lines changed or deleted 324 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/