ACE Working Group M. Tiloca
Internet-Draft RISE SICS
Intended status: Standards Track J. Park
Expires: December 31, 2018 Universitaet Duisburg-Essen
June 29, 2018
Joining OSCORE groups in ACE
draft-tiloca-ace-oscoap-joining-04
Abstract
This document describes a method to join a group where communications
are based on CoAP and secured with Object Security for Constrained
RESTful Environments (OSCORE). The proposed method delegates the
authentication and authorization of client nodes that join an OSCORE
group through a Group Manager server. This approach builds on the
ACE framework for Authentication and Authorization, and leverages
protocol-specific profiles of ACE to achieve communication security,
proof-of-possession and server authentication.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Tiloca & Park Expires December 31, 2018 [Page 1]
Internet-Draft OSCORE group joining in ACE June 2018
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Joining Node to Authorization Server . . . . . . . . . . . . 6
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 6
3.2. Authorization Response . . . . . . . . . . . . . . . . . 7
4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 8
4.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 9
5. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Object Security for Constrained RESTful Environments (OSCORE)
[I-D.ietf-core-object-security] is a method for application-layer
protection of the Constrained Application Protocol (CoAP) [RFC7252],
using CBOR Object Signing and Encryption (COSE) [RFC8152] and
enabling end-to-end security of CoAP payload and options.
As described in [I-D.ietf-core-oscore-groupcomm], OSCORE may be used
also to protect CoAP group communication over IP multicast [RFC7390].
This relies on a Group Manager entity, which is responsible for
managing an OSCORE group, where members exchange CoAP messages
secured with OSCORE. In particular, the Group Manager coordinates
the join process of new group members and can be responsible for
multiple groups.
This specification builds on the ACE framework for Authentication and
Authorization [I-D.ietf-ace-oauth-authz] and defines how a client
joins an OSCORE group through a resource server acting as Group
Manager. The client acting as joining node relies on an Access
Token, which is bound to a proof-of-possession key and authorizes the
access to a specific join resource at the Group Manager. Messages
exchanged among the participants follow the formats defined in
Tiloca & Park Expires December 31, 2018 [Page 2]
Internet-Draft OSCORE group joining in ACE June 2018
[I-D.palombini-ace-key-groupcomm] for provisioning keying material in
group communication scenarios.
In order to achieve communication security, proof-of-possession and
server authentication, the client and the Group Manager leverage
protocol-specific profiles of ACE. These include also possible
forthcoming profiles that comply with the requirements in Appendix C
of [I-D.ietf-ace-oauth-authz].
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers are expected to be familiar with the terms and concepts
described in the ACE framework for authentication and authorization
[I-D.ietf-ace-oauth-authz]. The terminology for entities in the
considered architecture is defined in OAuth 2.0 [RFC6749]. In
particular, this includes Client (C), Resource Server (RS), and
Authorization Server (AS).
Readers are expected to be familiar with the terms and concepts
related to the CoAP protocol described in [RFC7252][RFC7390]. Note
that, unless otherwise indicated, the term "endpoint" is used here
following its OAuth definition, aimed at denoting resources such as
/token and /introspect at the AS and /authz-info at the RS. This
document does not use the CoAP definition of "endpoint", which is "An
entity participating in the CoAP protocol".
Readers are expected to be familiar with the terms and concepts for
protection and processing of CoAP messages through OSCORE
[I-D.ietf-core-object-security] also in group communication scenarios
[I-D.ietf-core-oscore-groupcomm]. These include the concept of Group
Manager, as the entity responsible for a set of groups where
communications are secured with OSCORE. In this specification, the
Group Manager acts as Resource Server.
This document refers also to the following terminology.
o Joining node: a network node intending to join an OSCORE group,
where communication is based on CoAP [RFC7390] and secured with
OSCORE as described in [I-D.ietf-core-oscore-groupcomm].
Tiloca & Park Expires December 31, 2018 [Page 3]
Internet-Draft OSCORE group joining in ACE June 2018
o Join process: the process through which a joining node becomes a
member of an OSCORE group. The join process is enforced and
assisted by the Group Manager responsible for that group.
o Join resource: a resource hosted by the Group Manager, associated
to an OSCORE group under that Group Manager. A join resource is
identifiable with the Group Identifier (Gid) of the respective
group. A joining node accesses a join resource to start the join
process and become a member of that group.
o Join endpoint: an endpoint at the Group Manager associated to a
join resource.
o Requester: member of an OSCORE group that sends request messages
to other members of the group.
o Listener: member of an OSCORE group that receives request messages
from other members of the group. A listener may reply back, by
sending a response message to the requester which has sent the
request message.
o Pure listener: member of a group that is configured as listener
and never replies back to requesters after receiving request
messages. This corresponds to the term "silent server" used in
[I-D.ietf-core-oscore-groupcomm].
2. Protocol Overview
Group communication for CoAP over IP multicast has been enabled in
[RFC7390] and can be secured with Object Security for Constrained
RESTful Environments (OSCORE) [I-D.ietf-core-object-security] as
described in [I-D.ietf-core-oscore-groupcomm]. A network node
explicitly joins an OSCORE group, by interacting with the responsible
Group Manager. Once registered in the group, the new node can
securely exchange messages with other group members.
This specification describes how a network node joins an OSCORE group
by using the ACE framework for authentication and authorization
[I-D.ietf-ace-oauth-authz]. With reference to the ACE framework and
the terminology defined in OAuth 2.0 [RFC6749]:
o The Group Manager acts as Resource Server (RS), and hosts one join
resource for each OSCORE group it manages. Each join resource is
exported by a distinct join endpoint. During the join process,
the Group Manager provides joining nodes with the parameters and
keying material for taking part to secure communications in the
group.
Tiloca & Park Expires December 31, 2018 [Page 4]
Internet-Draft OSCORE group joining in ACE June 2018
o The joining node acts as Client (C), and requests to join an
OSCORE group by accessing the related join endpoint at the Group
Manager.
o The Authorization Server (AS) authorizes joining nodes to join
OSCORE groups under their respective Group Manager. Multiple
Group Managers can be associated to the same AS. The AS MAY
release Access Tokens for other purposes than joining OSCORE
groups under registered Group Managers. For example, the AS may
also release Access Tokens for accessing resources hosted by
members of OSCORE groups.
All communications between the involved entities rely on the CoAP
protocol and must be secured.
In particular, communications between the joining node and the Group
Manager leverage protocol-specific profiles of ACE to achieve
communication security, proof-of-possession and server
authentication. To this end, the AS must signal the specific profile
to use, consistently with requirements and assumptions defined in the
ACE framework [I-D.ietf-ace-oauth-authz].
With reference to the AS, communications between the joining node and
the AS (/token endpoint) as well as between the Group Manager and the
AS (/introspect endpoint) can be secured by different means, for
instance by means of DTLS [RFC6347] or OSCORE
[I-D.ietf-core-object-security]. Further details on how the AS
secures communications (with the joining node and the Group Manager)
depend on the specifically used profile of ACE, and are out of the
scope of this specification.
The following steps are performed for joining an OSCORE group.
Messages exchanged among the participants follow the formats defined
in [I-D.palombini-ace-key-groupcomm], and are further specified in
Section 3 and Section 4 of this document. The Group Manager acts as
the Key Distribution Center (KDC) referred in
[I-D.palombini-ace-key-groupcomm].
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
associated OSCORE group (see Section 3). The joining node will
start or continue using a secure communication channel with the
Group Manager, according to the response from the AS.
2. The joining node transfers authentication and authorization
information to the Group Manager by posting the obtained Access
Token (see Section 4). After that, a joining node must have a
secure communication channel established with the Group Manager,
Tiloca & Park Expires December 31, 2018 [Page 5]
Internet-Draft OSCORE group joining in ACE June 2018
before starting to join an OSCORE group under that Group Manager
(see Section 4). Possible alternatives to provide a secure
communication channel include DTLS [RFC6347] and OSCORE
[I-D.ietf-core-object-security].
3. The joining node starts the join process to become a member of
the OSCORE group, by accessing the related join resource hosted
by the Group Manager (see Section 4).
4. At the end of the join process, the joining node has received
from the Group Manager the parameters and keying material to
securely communicate with the other members of the OSCORE group.
5. The joining node and the Group Manager maintain the secure
channel, to support possible future communications.
3. Joining Node to Authorization Server
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
Manager. In particular, it considers a joining node that intends to
contact that Group Manager for the first time.
The message exchange between the joining node and the AS consists of
the messages Authorization Request and Authorization Response defined
in [I-D.palombini-ace-key-groupcomm].
In case the specific AS associated to the Group Manager is unknown to
the joining node, the latter can rely on mechanisms like the
Unauthorized Resource Request message described in Section 2 of
[I-D.ietf-ace-dtls-authorize] to discover the correct AS to contact.
3.1. Authorization Request
The joining node contacts the AS, in order to request an Access Token
for accessing the join resource hosted by the Group Manager and
associated to the OSCORE group. The Access Token request sent to the
/token endpoint follows the format of the Authorization Request
message defined in Section 3.1 of [I-D.palombini-ace-key-groupcomm].
In particular:
o The 'scope' parameter MUST be present and includes:
* in the first element, the Group Identifier (Gid) of the group
to join under the Group Manager. The value of this identifier
may not fully coincide with the Gid value currently associated
to the group, e.g. if the Gid is composed of a variable part
Tiloca & Park Expires December 31, 2018 [Page 6]
Internet-Draft OSCORE group joining in ACE June 2018
such as a Group Epoch (see Appendix C of
[I-D.ietf-core-oscore-groupcomm]).
* in the second element, which MUST be present, the role(s) that
the joining node intends to have in the group it intends to
join. Possible values are: "requester"; "listener"; and "pure
listener". Possible combinations are: "requester and
listener"; and "requester and pure listener". Multiple roles
are specified in the form of a CBOR array.
o The 'aud' parameter MUST be present and is set to the identifier
of the Group Manager.
3.2. Authorization Response
The AS is responsible for authorizing the joining node to join
specific OSCORE groups, according to join policies enforced on behalf
of the respective Group Manager.
In case of successful authorization, the AS releases an Access Token
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
of an Access Token response, which follows the format of the
Authorization Response message defined in Section 3.2 of
[I-D.palombini-ace-key-groupcomm].
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
specification.
The AS must include the 'scope' parameter in the response when the
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
of 'scope' MUST be present and includes the role(s) that the joining
node is actually authorized to take in the group, encoded as
specified in Section 3.1 of this document.
Also, the 'profile' parameter indicates the specific profile of ACE
to use for securing communications between the joining node and the
Group Manager (see Section 5.6.4.4 of [I-D.ietf-ace-oauth-authz]).
In particular, if symmetric keys are used, the AS generates a proof-
of-possession key, binds it to the Access Token, and provides it to
the joining node in the 'cnf' parameter of the Access Token response.
Instead, if asymmetric keys are used, the joining node provides its
own public key to the AS in the 'cnf' parameter of the Access Token
request. Then, the AS uses it as proof-of-possession key bound to
Tiloca & Park Expires December 31, 2018 [Page 7]
Internet-Draft OSCORE group joining in ACE June 2018
the Access Token, and provides the joining node with the Group
Manager's public key in the 'rs_cnf' parameter of the Access Token
response.
4. Joining Node to Group Manager
First, the joining node posts the Access Token to the /authz-info
endpoint at the Group Manager, in accordance with the Token post
defined in Section 3.3 of [I-D.palombini-ace-key-groupcomm]. Then,
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
Once a secure communication channel with the Group Manager has been
established, the joining node requests to join the OSCORE group, by
accessing the related join resource at the Group Manager.
In particular, the joining node sends to the Group Manager a
confirmable CoAP request, using the method POST and targeting the
join endpoint associated to that group. This join request follows
the format of the Key Distribution Request message defined in
Section 4.1 of [I-D.palombini-ace-key-groupcomm]. In particular:
o The 'get_pub_keys' parameter is present only if the Group Manager
is configured to store the public keys of the group members and,
at the same time, the joining node wants to retrieve such public
keys during the joining process (see Section 5). In any other
case, this parameter MUST NOT be present.
o The 'client_cred' parameter, if present, includes the public key
or certificate of the joining node. Specifically, it includes the
public key of the joining node if the Group Manager is configured
to store the public keys of the group members, or the certificate
of the joining node otherwise. This parameter MAY be omitted if:
i) public keys are used as proof-of-possession keys between the
joining node and the Group Manager; or ii) the joining node is
asking to access the group exclusively as pure listener; or iii)
the Group Manager already acquired this information during a
previous join process. In any other case, this parameter MUST be
present.
o The 'pub_keys_repos' parameter MAY be present if the 'client_cred'
parameter is both present and with value a certificate of the
joining node. If present, this parameter contains the list of
public key repositories storing the certificate of the joining
node. In any other case, this parameter MUST NOT be present.
Tiloca & Park Expires December 31, 2018 [Page 8]
Internet-Draft OSCORE group joining in ACE June 2018
4.2. Join Response
The Group Manager processes the request according to
[I-D.ietf-ace-oauth-authz]. If this yields a positive outcome, 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
information necessary to participate in the group communication.
This join response follows the format of the Key Distribution success
Response message defined in Section 4.2 of
[I-D.palombini-ace-key-groupcomm]. In particular:
o The 'key' parameter includes what the joining node needs in order
to set up the OSCORE Security Context as per Section 2 of
[I-D.ietf-core-oscore-groupcomm]. In particular:
* The 'kty' parameter has value "Symmetric".
* The 'k' parameter includes the OSCORE Master Secret.
* The 'exp' parameter specifies when the OSCORE Master Secret
expires.
* The 'alg' parameter, if present, has as value the AEAD
algorithm used in the group.
* The 'kid' parameter, if present, has as value the identifier of
the key in the parameter 'k'.
* The 'base IV' parameter, if present, has as value the OSCORE
Common IV.
* The 'clientID' parameter, if present, has as value the OSCORE
Endpoint 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 'serverID' parameter MUST be present and has as value the
Group Identifier (Gid) currently associated to the group.
* The 'kdf' parameter, if present, has as value the KDF algorithm
used in the group.
* The 'slt' parameter, if present, has as value the OSCORE Master
Salt.
Tiloca & Park Expires December 31, 2018 [Page 9]
Internet-Draft OSCORE group joining in ACE June 2018
* The 'cs_alg' parameter MUST be present and has as value the
countersignature algorithm used in the group.
o The 'pub_keys' parameter is present only if the 'get_pub_keys'
parameter was present in the join request. If present, this
parameter includes the public keys of the group members that are
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
joining node is configured (also) as requester; and ii) the public
keys of the requesters currently in the group, in case the joining
node is configured (also) as listener or pure listener.
o The 'group_policies' parameter SHOULD be present and includes a
list of parameters indicating particular policies enforced in the
group. For instance, it can indicate the method to achieve
synchronization of sequence numbers among group members (see
Appendix E of [I-D.ietf-core-oscore-groupcomm]), as well as the
rekeying protocol used to renew the keying material in the group
(see Section 2.1 of [I-D.ietf-core-oscore-groupcomm]).
o The 'mgt_key_material' parameter SHOULD be present and includes
the administrative keying material that the joining node requires
to participate in the rekeying process led by the Group Manager.
The exact content and format depend on the specific rekeying
protocol used in the group.
Finally, the joining node uses the information received in the join
response to set up the OSCORE Security Context, as described in
Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the
joining node can exchange group messages secured with OSCORE as
described in Section 4 of [I-D.ietf-core-oscore-groupcomm].
When the OSCORE Master Secret expires, as specified by 'exp' in the
'key' parameter of the join response, the node considers the OSCORE
Security Context also invalid and to be renewed. A possible approach
for the node to renew the OSCORE Security Context through the Group
Manager is described in Section 6 of
[I-D.palombini-ace-key-groupcomm].
5. Public Keys of Joining Nodes
Source authentication of OSCORE messages exchanged within the group
is ensured by means of digital counter signatures
[I-D.ietf-core-oscore-groupcomm]. Therefore, group members must be
able to retrieve each other's public key from a trusted key
repository, in order to verify the source authenticity of incoming
group messages.
Tiloca & Park Expires December 31, 2018 [Page 10]
Internet-Draft OSCORE group joining in ACE June 2018
Upon joining an OSCORE group, a joining node is expected to make its
own public key available to the other group members, either through
the Group Manager or through another trusted, publicly available, key
repository. However, this is not required for a node that joins a
group exclusively as pure listener.
As also discussed in Section 6 of [I-D.ietf-core-oscore-groupcomm],
it is recommended that the Group Manager is configured to store the
public keys of the group members and to provide them upon request.
If so, three cases can occur when a new node joins a group.
o The Group Manager already acquired the public key of the joining
node during a previous join process. In this case, the joining
node may not provide again its own public key to the Group
Manager, in order to limit the size of the join request.
o The joining node and the Group Manager use an asymmetric proof-of-
possession key to establish a secure communication channel. In
this case, the Group Manager stores the proof-of-possession key
conveyed in the Access Token as the public key of the joining
node.
o The joining node and the Group Manager use a symmetric proof-of-
possession key to establish a secure communication channel. In
this case, upon performing a join process with that Group Manager
for the first time, the joining node specifies its own public key
in the 'client_cred' parameter of the join request targeting the
join endpoint (see Section 4.1).
Furthermore, as described in Section 4.1, the joining node may have
explicitly requested the Group Manager to retrieve the public keys of
the current group members, i.e. through the 'get_pub_keys' parameter
in the join request. In this case, the Group Manager includes also
such public keys in the 'pub_keys' parameter of the join response
(see Section 4.2).
Later on as a group member, the node may need to retrieve the public
keys of other group members. A possible approach to do this through
the Group Manager is described in Section 7 of
[I-D.palombini-ace-key-groupcomm].
On the other hand, in case the Group Manager is not configured to
store public keys of group members, the joining node provides the
Group Manager with its own certificate in the 'client_cred' parameter
of the join request targeting the join endpoint (see Section 4.1).
Then, the Group Manager validates and handles the certificate, for
instance as described in Appendix D.2 of
[I-D.ietf-core-oscore-groupcomm].
Tiloca & Park Expires December 31, 2018 [Page 11]
Internet-Draft OSCORE group joining in ACE June 2018
6. Security Considerations
The method described in this document leverages the following
management aspects related to OSCORE groups and discussed in the
sections of [I-D.ietf-core-oscore-groupcomm] referred below.
o Management of group keying material (see Section 2.1 of
[I-D.ietf-core-oscore-groupcomm]). This includes the need to
revoke and renew the keying material currently used in the OSCORE
group, upon changes in the group membership. In particular,
renewing the keying material is required upon a new node joining
the group, in order to preserve backward security. That is, the
Group Manager should renew the keying material before completing
the join process and sending a join response. Such a join
response provides the joining node with the updated keying
material just established in the group. The Group Manager is
responsible to enforce rekeying policies and accordingly update
the keying material in the groups of its competence (see Section 6
of [I-D.ietf-core-oscore-groupcomm]).
o Synchronization of sequence numbers (see Section 5 of
[I-D.ietf-core-oscore-groupcomm]). This concerns how a listener
node that has just joined an OSCORE group can synchronize with the
sequence number of requesters in the same group.
o Provisioning and retrieval of public keys (see Appendix D.2 of
[I-D.ietf-core-oscore-groupcomm]). This provides guidelines about
how to ensure the availability of group members' public keys,
possibly relying on the Group Manager as trusted key repository
(see Section 6 of [I-D.ietf-core-oscore-groupcomm]).
Before sending the join response, the Group Manager should verify
that the joining node actually owns the associated private key, for
instance by performing a proof-of-possession challenge-response,
whose details are out of the scope of this specification.
Further security considerations are inherited from the ACE framework
for Authentication and Authorization [I-D.ietf-ace-oauth-authz], as
well as from the specific profile of ACE signalled by the AS, such as
[I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile].
7. IANA Considerations
This document has no actions for IANA.
Tiloca & Park Expires December 31, 2018 [Page 12]
Internet-Draft OSCORE group joining in ACE June 2018
8. Acknowledgments
The authors sincerely thank Santiago Aragon, Stefan Beck, Martin
Gunnarsson, Francesca Palombini, Jim Schaad, Ludwig Seitz, Goeran
Selander and Peter van der Stok for their comments and feedback.
The work on this document has been partly supported by the EIT-
Digital High Impact Initiative ACTIVE.
9. References
9.1. Normative References
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-12
(work in progress), May 2018.
[I-D.ietf-ace-oscore-profile]
Seitz, L., Palombini, F., Gunnarsson, M., and G. Selander,
"OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-02 (work in progress), June 2018.
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-13 (work in
progress), June 2018.
[I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Secure group communication for CoAP", draft-ietf-core-
oscore-groupcomm-02 (work in progress), June 2018.
[I-D.palombini-ace-key-groupcomm]
Palombini, F. and M. Tiloca, "Key Provisioning for Group
Communication using ACE", draft-palombini-ace-key-
groupcomm-01 (work in progress), June 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
Tiloca & Park Expires December 31, 2018 [Page 13]
Internet-Draft OSCORE group joining in ACE June 2018
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
editor.org/info/rfc7252>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls-
authorize-03 (work in progress), March 2018.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014, <https://www.rfc-
editor.org/info/rfc7390>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
Authors' Addresses
Marco Tiloca
RISE SICS
Isafjordsgatan 22
Kista SE-164 29 Stockholm
Sweden
Email: marco.tiloca@ri.se
Tiloca & Park Expires December 31, 2018 [Page 14]
Internet-Draft OSCORE group joining in ACE June 2018
Jiye Park
Universitaet Duisburg-Essen
Schuetzenbahn 70
Essen 45127
Germany
Email: ji-ye.park@uni-due.de
Tiloca & Park Expires December 31, 2018 [Page 15]