draft-ietf-core-oscore-groupcomm-02.txt   draft-ietf-core-oscore-groupcomm-03.txt 
CoRE Working Group M. Tiloca CoRE Working Group M. Tiloca
Internet-Draft RISE SICS Internet-Draft RISE AB
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: December 30, 2018 F. Palombini Expires: April 25, 2019 F. Palombini
Ericsson AB Ericsson AB
J. Park J. Park
Universitaet Duisburg-Essen Universitaet Duisburg-Essen
June 28, 2018 October 22, 2018
Secure group communication for CoAP Group OSCORE - Secure Group Communication for CoAP
draft-ietf-core-oscore-groupcomm-02 draft-ietf-core-oscore-groupcomm-03
Abstract Abstract
This document describes a mode for protecting group communication This document describes a mode for protecting group communication
over the Constrained Application Protocol (CoAP). The proposed mode over the Constrained Application Protocol (CoAP). The proposed mode
relies on Object Security for Constrained RESTful Environments relies on Object Security for Constrained RESTful Environments
(OSCORE) and the CBOR Object Signing and Encryption (COSE) format. (OSCORE) and the CBOR Object Signing and Encryption (COSE) format.
In particular, it is defined how OSCORE should be used in a group In particular, it defines how OSCORE is used in a group communication
communication setting, while fulfilling the same security setting, while fulfilling the same security requirements for group
requirements for request messages and related response messages. requests and responses. Source authentication of all messages
Source authentication of all messages exchanged within the group is exchanged within the group is provided by means of digital signatures
ensured, by means of digital signatures produced through private keys produced by the sender and embedded in the protected CoAP messages.
of sender endpoints and embedded in the protected CoAP messages.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 30, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. OSCORE Security Context . . . . . . . . . . . . . . . . . . . 5 2. OSCORE Security Context . . . . . . . . . . . . . . . . . . . 5
2.1. Management of Group Keying Material . . . . . . . . . . . 7 2.1. Management of Group Keying Material . . . . . . . . . . . 7
3. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Wrap-Around of Partial IVs . . . . . . . . . . . . . . . 8
3.1. Example: Request . . . . . . . . . . . . . . . . . . . . 9 3. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Example: Response . . . . . . . . . . . . . . . . . . . . 10 4. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 9
4. Message Processing . . . . . . . . . . . . . . . . . . . . . 10 4.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 9
4.1. Protecting the Request . . . . . . . . . . . . . . . . . 10 4.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 10
4.2. Verifying the Request . . . . . . . . . . . . . . . . . . 11 4.3. Examples of Compressed COSE Objects . . . . . . . . . . . 10
4.3. Protecting the Response . . . . . . . . . . . . . . . . . 11 5. Message Binding, Sequence Numbers, Freshness and Replay
4.4. Verifying the Response . . . . . . . . . . . . . . . . . 11 Protection . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Synchronization of Sequence Numbers . . . . . . . . . . . . . 12 5.1. Synchronization of Sender Sequence Numbers . . . . . . . 12
6. Responsibilities of the Group Manager . . . . . . . . . . . . 12 6. Message Processing . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.1. Protecting the Request . . . . . . . . . . . . . . . . . 13
7.1. Group-level Security . . . . . . . . . . . . . . . . . . 14 6.2. Verifying the Request . . . . . . . . . . . . . . . . . . 13
7.2. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 14 6.3. Protecting the Response . . . . . . . . . . . . . . . . . 13
7.3. Collision of Group Identifiers . . . . . . . . . . . . . 14 6.4. Verifying the Response . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Responsibilities of the Group Manager . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Group-level Security . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.2. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 8.3. Management of Group Keying Material . . . . . . . . . . . 16
Appendix A. Assumptions and Security Objectives . . . . . . . . 18 8.4. Update of Security Context and Key Rotation . . . . . . . 17
A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 18 8.5. Collision of Group Identifiers . . . . . . . . . . . . . 17
A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 21 9.1. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . . 18
Appendix C. Example of Group Identifier Format . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
D.1. Join Process . . . . . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 19
D.2. Provisioning and Retrieval of Public Keys . . . . . . . . 27 Appendix A. Assumptions and Security Objectives . . . . . . . . 20
D.3. Group Joining Based on the ACE Framework . . . . . . . . 29 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix E. Examples of Synchronization Approaches . . . . . . . 29 A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 21
E.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 29 Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 22
E.2. Baseline Synchronization . . . . . . . . . . . . . . . . 30 Appendix C. Example of Group Identifier Format . . . . . . . . . 24
E.3. Challenge-Response Synchronization . . . . . . . . . . . 30 Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 25
Appendix E. Examples of Synchronization Approaches . . . . . . . 26
Appendix F. No Verification of Signatures . . . . . . . . . . . 32 E.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 26
Appendix G. Document Updates . . . . . . . . . . . . . . . . . . 32 E.2. Baseline Synchronization . . . . . . . . . . . . . . . . 26
G.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 32 E.3. Challenge-Response Synchronization . . . . . . . . . . . 27
G.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 33 Appendix F. No Verification of Signatures . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix G. Document Updates . . . . . . . . . . . . . . . . . . 29
G.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 29
G.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 30
G.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] is a web The Constrained Application Protocol (CoAP) [RFC7252] is a web
transfer protocol specifically designed for constrained devices and transfer protocol specifically designed for constrained devices and
networks [RFC7228]. networks [RFC7228].
Group communication for CoAP [RFC7390] addresses use cases where Group communication for CoAP [RFC7390] addresses use cases where
deployed devices benefit from a group communication model, for deployed devices benefit from a group communication model, for
example to reduce latencies and improve performance. Use cases example to reduce latencies, improve performance and reduce bandwidth
include lighting control, integrated building control, software and utilisation. Use cases include lighting control, integrated building
firmware updates, parameter and configuration updates, commissioning control, software and firmware updates, parameter and configuration
of constrained networks, and emergency multicast (see Appendix B). updates, commissioning of constrained networks, and emergency
Furthermore, [RFC7390] recognizes the importance to introduce a multicast (see Appendix B). Furthermore, [RFC7390] recognizes the
secure mode for CoAP group communication. This specification defines importance to introduce a secure mode for CoAP group communication.
such a mode. This specification defines such a mode.
Object Security for Constrained RESTful Environments Object Security for Constrained RESTful Environments
(OSCORE)[I-D.ietf-core-object-security] describes a security protocol (OSCORE)[I-D.ietf-core-object-security] describes a security protocol
based on the exchange of protected CoAP messages. OSCORE builds on based on the exchange of protected CoAP messages. OSCORE builds on
CBOR Object Signing and Encryption (COSE) [RFC8152] and provides end- CBOR Object Signing and Encryption (COSE) [RFC8152] and provides end-
to-end encryption, integrity, and replay protection between a sending to-end encryption, integrity, replay protection and binding of
endpoint and a receiving endpoint possibly involving intermediary response to request between a sender and a receipient, also in the
endpoints. To this end, a CoAP message is protected by including its presence of intermediaries. To this end, a CoAP message is protected
payload (if any), certain options, and header fields in a COSE by including its payload (if any), certain options, and header fields
object, which finally replaces the authenticated and encrypted fields in a COSE object, which replaces the authenticated and encrypted
in the protected message. fields in the protected message.
This document describes group OSCORE, providing end-to-end security This document defines Group OSCORE, providing end-to-end security of
of CoAP messages exchanged between members of a group. In CoAP messages exchanged between members of a group, and preserving
particular, the described approach defines how OSCORE should be used independence of transport layer. In particular, the described
in a group communication setting, so that end-to-end security is approach defines how OSCORE should be used in a group communication
assured by using the same security method. That is, end-to-end setting, so that end-to-end security is assured in the same way as
security is assured for (multicast) CoAP requests sent by client OSCORE for unicast communication. That is, end-to-end security is
endpoints to the group and for related CoAP responses sent as reply provided for CoAP multicast requests sent by a client to the group,
by multiple server endpoints. Group OSCORE provides source and for related CoAP responses sent by multiple servers. Group
authentication of all CoAP messages exchanged within the group, by OSCORE provides source authentication of all CoAP messages exchanged
means of digital signatures produced through private keys of sender within the group, by means of digital signatures produced through
devices and embedded in the protected CoAP messages. As in OSCORE, private keys of sender devices and embedded in the protected CoAP
it is still possible to simultaneously rely on DTLS to protect hop- messages.
by-hop communication between a sender endpoint and a proxy (and vice
versa), and between a proxy and a recipient endpoint (and vice As in OSCORE, it is still possible to simultaneously rely on DTLS
versa). [RFC6347] to protect hop-by-hop communication between a sender and a
proxy (and vice versa), and between a proxy and a recipient (and vice
versa). Note that DTLS cannot be used to secure messages sent over
multicast.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
skipping to change at page 4, line 33 skipping to change at page 4, line 42
Terminology for constrained environments, such as "constrained Terminology for constrained environments, such as "constrained
device", "constrained-node network", is defined in [RFC7228]. device", "constrained-node network", is defined in [RFC7228].
This document refers also to the following terminology. This document refers also to the following terminology.
o Keying material: data that is necessary to establish and maintain o Keying material: data that is necessary to establish and maintain
secure communication among endpoints. This includes, for secure communication among endpoints. This includes, for
instance, keys and IVs [RFC4949]. instance, keys and IVs [RFC4949].
o Group: a set of endpoints that share group keying material and o Group: a set of endpoints that share group keying material and
parameters (Common Context of the group's Security Context, see security parameters (Common Context, see Section 2). The term
Section 2). That is, the term group used in this specification group used in this specification refers thus to a "security
refers to a "security group", not to be confused with network/ group", not to be confused with network/multicast group or
multicast groups or application groups. application group.
o Group Manager (GM): entity responsible for a set of OSCORE groups.
Each endpoint in a group securely communicates with the respective
GM, which is not required to be an actual group member and to take
part in the group communication. The full list of
responsibilities of the Group Manager is provided in Section 6.
o Silent server: member of a group that never replies back after o Group Manager (GM): entity responsible for a group. Each endpoint
receiving request messages. in a group communicates securely with the respective GM, which is
neither required to be an actual group member nor to take part in
the group communication. The full list of responsibilities of the
Group Manager is provided in Section 7.
o Group ID: group identifier assigned to the group. Group IDs are o Silent server: member of a group that never responds to requests.
unique within the set of groups of a same Group Manager. Note that a silent server can act as a client, the two roles are
independent.
o Endpoint ID: Sender ID of the endpoint, as defined in o Group Identifier (Gid): identifier assigned to the group. Group
[I-D.ietf-core-object-security]. An Endpoint ID is provided to an Identifiers should be unique within the set of groups of a given
endpoint upon joining a group, is valid only within that group, Group Manager, in order to avoid collisions. In case they are
and is unique within the same group. Endpoints which are not, the considerations in Section 8.5 apply.
configured only as silent servers do not have an Endpoint ID.
o Group request: CoAP request message sent by a client endpoint in o Group request: CoAP request message sent by a client in the group
the group to all server endpoints in that group. to all servers in that group.
o Source authentication: evidence that a received message in the o Source authentication: evidence that a received message in the
group originated from a specifically identified group member. group originated from a specific identified group member. This
This also provides assurances that the message was not tampered also provides assurance that the message was not tampered with by
with by a different group member or by a non-group member. anyone, be it a different legitimate group member or an endpoint
which is not a group member.
2. OSCORE Security Context 2. OSCORE Security Context
To support group communication secured with OSCORE, each endpoint To support group communication secured with OSCORE, each endpoint
registered as member of a group maintains a Security Context as registered as member of a group maintains a Security Context as
defined in Section 3 of [I-D.ietf-core-object-security]. Each defined in Section 3 of [I-D.ietf-core-object-security], extended as
endpoint in a group stores: defined below. Each endpoint in a group makes use of:
1. one Common Context, shared by all the endpoints in the group. In
particular:
* All the endpoints in the group agree on the same COSE AEAD 1. one Common Context, shared by all the endpoints in a given group.
algorithm. In particular:
* The ID Context parameter stores the Group ID of the group, * The ID Context parameter contains the Gid of the group, which
which is used to retrieve the Security Context for processing is used to retrieve the Security Context for processing
messages intended to the group's endpoints (see Section 4). messages intended to the endpoints of the group (see
The choice of the Group ID for a given group's Security Section 6). The choice of the Gid is application specific.
Context is application specific. An example of specific An example of specific formatting of the Gid is given in
formatting of the Group ID that would follow this Appendix C. The application needs to specify how to handle
specification is given in Appendix C. It is the role of the possible collisions between Gids, see Section 8.5.
application to specify how to handle possible collisions.
* A new parameter Counter Signature Algorithm is included, and * A new parameter Counter Signature Algorithm is included. Its
its value identifies the algorithm used for source value identifies the digital signature algorithm used to
authenticating messages sent within the group, by means of a compute a counter signature on the COSE object (see
counter signature (see Section 4.5 of [RFC8152]). Its value Section 4.5 of [RFC8152]) which provides source authentication
is immutable once the Common Context is established. All the within the group. Its value is immutable once the Common
endpoints in the group agree on the same counter signature Context is established. The EdDSA signature algorithm ed25519
algorithm. The list of supported signature algorithms is part [RFC8032] is mandatory to implement.
of the group communication policy and MUST include the EdDSA
signature algorithm ed25519 [RFC8032].
2. one Sender Context, unless the endpoint is configured exclusively 2. one Sender Context, unless the endpoint is configured exclusively
as silent server. The Sender Context is used to secure outgoing as silent server. The Sender Context is used to secure outgoing
group messages and is initialized according to Section 3 of messages and is initialized according to Section 3 of
[I-D.ietf-core-object-security], once the endpoint has joined the [I-D.ietf-core-object-security], once the endpoint has joined the
group. In practice, the symmetric keying material in the Sender group. The Sender Context of a given endpoint matches the
Context of the sender endpoint is shared with all the recipient corresponding Recipient Context in all the endpoints receiving a
endpoints that have received group messages from that same sender protected message from that endpoint. Besides, in addition to
endpoint. Besides, in addition to what is defined in what is defined in [I-D.ietf-core-object-security], the Sender
[I-D.ietf-core-object-security], the Sender Context stores also Context stores also the endpoint's private key.
the endpoint's public-private key pair.
3. one Recipient Context for each distinct endpoint from which group 3. one Recipient Context for each distinct endpoint from which
messages are received, used to process such incoming messages. messages are received, used to process incoming messages. The
The recipient endpoint creates a new Recipient Context upon recipient may generate the Recipient Context upon receiving an
receiving an incoming message from another endpoint in the group incoming message from another endpoint in the group for the first
for the first time (see Section 4.2 and Section 4.4). In time (see Section 6.2 and Section 6.4). Each Recipient Context
practice, the symmetric keying material in a given Recipient matches the Sender Context of the endpoint from which protected
Context of the recipient endpoint is shared with the associated messages are received. Besides, in addition to what is defined
sender endpoint from which group messages are received. Besides, in [I-D.ietf-core-object-security], each Recipient Context stores
in addition to what is defined in
[I-D.ietf-core-object-security], each Recipient Context stores
also the public key of the associated other endpoint from which also the public key of the associated other endpoint from which
group messages are received. messages are received.
The table in Figure 1 overviews the new information included in the The table in Figure 1 overviews the new information included in the
OSCORE Security Context, with respect to what defined in Section 3 of OSCORE Security Context, with respect to what defined in Section 3 of
[I-D.ietf-core-object-security]. [I-D.ietf-core-object-security].
+---------------------------+-----------------------------+ +---------------------------+-----------------------------+
| Context portion | New information | | Context portion | New information |
+---------------------------+-----------------------------+ +---------------------------+-----------------------------+
| | | | | |
| Common Context | Counter signature algorithm | | Common Context | Counter signature algorithm |
| | | | | |
| Sender Context | Endpoint's own private key | | Sender Context | Endpoint's own private key |
| | | | | |
| Sender Context | Endpoint's own public key |
| | |
| Each Recipient Context | Public key of the | | Each Recipient Context | Public key of the |
| | associated other endpoint | | | associated other endpoint |
| | | | | |
+---------------------------+-----------------------------+ +---------------------------+-----------------------------+
Figure 1: Additions to the OSCORE Security Context Figure 1: Additions to the OSCORE Security Context
Upon receiving a secure CoAP message, a recipient endpoint relies on Upon receiving a secure CoAP message, a recipient uses the sender's
the sender endpoint's public key, in order to verify the counter public key, in order to verify the counter signature of the COSE
signature conveyed in the COSE Object. Object (see Section 3).
If not already stored in the Recipient Context associated to the If not already stored in the Recipient Context associated to the
sender endpoint, the recipient endpoint retrieves the public key from sender, the recipient retrieves the public key from the Group
a trusted key repository. In such a case, the correct binding Manager, which collects public keys upon endpoints' joining, acts as
between the sender endpoint and the retrieved public key must be trusted key repository and ensures the correct association between
assured, for instance by means of public key certificates. Further the public key and the identifier of the sender, for instance by
discussion about how public keys can be handled and retrieved in the means of public key certificates.
group is provided in Appendix D.2.
The Sender Key/IV stored in the Sender Context and the Recipient It is RECOMMENDED that the Group Manager collects public keys and
Keys/IVs stored in the Recipient Contexts are derived according to provides them to group members upon request as described in
the same scheme defined in Section 3.2 of [I-D.tiloca-ace-oscoap-joining], where the join process is based on
the ACE framework for Authentication and Authorization in constrained
environments [I-D.ietf-ace-oauth-authz]. Further details about how
public keys can be handled and retrieved in the group is out of the
scope of this document.
An endpoint receives its own Sender ID from the Group Manager upon
joining the group. That Sender ID is valid only within that group,
and is unique within the group. An endpoint uses its own Sender ID
(together with other data) to generate unique AEAD nonces for
outgoing messages, as in [I-D.ietf-core-object-security]. Endpoints
which are configured only as silent servers do not have a Sender ID.
The Sender/Recipient Keys and the Common IV are derived according to
the same scheme defined in Sections 3.2 and 5.2 of
[I-D.ietf-core-object-security]. The mandatory-to-implement HKDF and
AEAD algorithms for Group OSCORE are the same as in
[I-D.ietf-core-object-security]. [I-D.ietf-core-object-security].
2.1. Management of Group Keying Material 2.1. Management of Group Keying Material
The approach described in this specification should take into account In order to establish a new Security Context in a group, a new Group
the risk of compromise of group members. In particular, the adoption Identifier (Gid) for that group and a new value for the Master Secret
of key management schemes for secure revocation and renewal of parameter MUST be distributed. An example of Gid format supporting
Security Contexts and group keying material should be considered. this operation is provided in Appendix C. Then, each group member
re-derives the keying material stored in its own Sender Context and
Recipient Contexts as described in Section 2, using the updated Gid.
Consistently with the security assumptions in Appendix A.1, it is Consistently with the security assumptions in Appendix A.1, it is
RECOMMENDED to adopt a group key management scheme, and securely RECOMMENDED to adopt a group key management scheme, and securely
distribute a new value for the Master Secret parameter of the group's distribute a new value for the Gid and for the Master Secret
Security Context, before a new joining endpoint is added to the group parameter of the group's Security Context, before a new joining
or after a currently present endpoint leaves the group. This is endpoint is added to the group or after a currently present endpoint
necessary in order to preserve backward security and forward security leaves the group. This is necessary to preserve backward security
in the group. and forward security in the group, if the application requires it.
In particular, a new Group Identifier (Gid) for that group and a new The specific approach used to distribute the new Gid and Master
value for the Master Secret parameter must also be distributed. An Secret parameter to the group is out of the scope of this document.
example of Group Identifier format supporting this operation is However, it is RECOMMENDED that the Group Manager supports the
provided in Appendix C. Then, each group member re-derives the distribution of the new Gid and Master Secret parameter to the group
keying material stored in its own Sender Context and Recipient according to the Group Rekeying Process described in
Contexts as described in Section 2, using the updated Group [I-D.tiloca-ace-oscoap-joining].
Identifier.
Especially in dynamic, large-scale, groups where endpoints can join 2.2. Wrap-Around of Partial IVs
and leave at any time, it is important that the considered group key
management scheme is efficient and highly scalable with the group A client can eventually experience a wrap-around of its own Sender
size, in order to limit the impact on performance due to the Security Sequence Number, which is used as Partial IV in outgoing requests and
Context and keying material update. incremented after each request. When this happens, the OSCORE
Security Context MUST be renewed in the group, in order to avoid
reusing nonces with the same keys.
Therefore, when experiencing a wrap-around of its own Sender Sequence
Number, a group member MUST NOT transmit further group requests until
a new OSCORE Security Context has been derived. In particular, the
endpoint SHOULD inform the Group Manager of the occurred wrap-around,
in order to trigger a prompt renewal of the OSCORE Security Context.
3. The COSE Object 3. The COSE Object
When creating a protected CoAP message, an endpoint in the group Building on Section 5 of [I-D.ietf-core-object-security], this
computes the COSE object using the untagged COSE_Encrypt0 structure section defines how to use COSE [RFC8152] to wrap and protect data in
[RFC8152] as defined in Section 5 of [I-D.ietf-core-object-security], the original message. OSCORE uses the untagged COSE_Encrypt0
with the following modifications. structure with an Authenticated Encryption with Additional Data
(AEAD) algorithm. For Group OSCORE, the following modifications
apply:
o The external_aad in the Additional Authenticated Data (AAD) is
extended with the counter signature algorithm used to sign
messages. In particular, compared with Section 5.4 of
[I-D.ietf-core-object-security], the 'algorithms' array in the
aad_array MUST also include 'alg_countersign', which contains the
Counter Signature Algorithm from the Common Context (see
Section 2). This external_aad structure is used both for the
encryption process producing the ciphertext (see Section 5.3 of
[RFC8152]) and for the signing process producing the counter
signature, as defined below.
external_aad = bstr .cbor aad_array
aad_array = [
oscore_version : uint,
algorithms : [alg_aead : int / tstr , alg_countersign : int / tstr],
request_kid : bstr,
request_piv : bstr,
options : bstr
]
o The value of the 'kid' parameter in the 'unprotected' field of o The value of the 'kid' parameter in the 'unprotected' field of
response messagess SHALL be set to the Endpoint ID of the endpoint response messages MUST be set to the Sender ID of the endpoint
transmitting the message, i.e. the Sender ID. transmitting the message. That is, unlike in
o The 'unprotected' field SHALL additionally include the following [I-D.ietf-core-object-security], the 'kid' parameter is always
present in all messages, i.e. both requests and responses.
o The 'unprotected' field MUST additionally include the following
parameter: parameter:
* CounterSignature0 : its value is set to the counter signature * CounterSignature0 : its value is set to the counter signature
of the COSE object, computed by the endpoint by means of its of the COSE object, computed by the sender using its own
own private key as described in Section 4.5 of [RFC8152]. The private key as described in Appendix A.2 of [RFC8152]. In
presence of this parameter is explicitly signaled, by using the particular, the Sig_structure contains the external_aad as
reserved sixth least significant bit of the first byte of flag defined above and the ciphertext of the COSE_Encrypt0 object as
bits in the value of the OSCORE Option (see Section 6.1 of payload.
[I-D.ietf-core-object-security]).
o The Additional Authenticated Data (AAD) considered to compute the 4. OSCORE Header Compression
COSE object is extended with the counter signature algorithm used
to protect group messages. In particular, with reference to
Section 5.4 of [I-D.ietf-core-object-security], the 'algorithms'
array in the external_aad SHALL also include 'alg_countersign',
which contains the Counter Signature Algorithm from the Common
Context (see Section 2).
external_aad = [ The OSCORE compression defined in Section 6 of
... [I-D.ietf-core-object-security] is used, with the following additions
algorithms : [alg_aead : int / tstr , alg_countersign : int / tstr], for the encoding of the OSCORE Option and the OSCORE Payload.
...
]
o The OSCORE compression defined in Section 6 of 4.1. Encoding of the OSCORE Option Value
[I-D.ietf-core-object-security] is used, with the following
additions for the encoding of the OSCORE Option.
* The fourth least significant bit of the first byte of flag bits Analogously to [I-D.ietf-core-object-security], the value of the
SHALL be set to 1, to indicate the presence of the 'kid' OSCORE option SHALL contain the OSCORE flag bits, the Partial IV
parameter for both group requests and responses. parameter, the kid context parameter (length and value), and the kid
parameter, with the following modifications:
* The fifth least significant bit of the first byte of flag bits o The first byte, containing the OSCORE flag bits, has the following
MUST be set to 1 for group requests, to indicate the presence encoding modifications:
of the 'kid context' parameter in the OSCORE payload. The kid
context flag MAY be set to 1 for responses.
* The sixth least significant bit of the first byte of flag bits * The fourth least significant bit MUST be set to 1 in every
is originally marked as reserved in message, to indicate the presence of the 'kid' parameter for
[I-D.ietf-core-object-security] and its usage is defined in all group requests and responses. That is, unlike in
this specification. This bit is set to 1 if the [I-D.ietf-core-object-security], the 'kid' parameter is always
present in all messages.
* The fifth least significant bit MUST be set to 1 for group
requests, to indicate the presence of the 'kid context'
parameter in the compressed COSE object. The 'kid context' MAY
be present in responses if the application requires it. In
such a case, the kid context flag MUST be set to 1.
* The sixth least significant bit is set to 1 if the
'CounterSignature0' parameter is present, or to 0 otherwise. 'CounterSignature0' parameter is present, or to 0 otherwise.
In order to ensure source authentication of group messages as In order to ensure source authentication of messages as
described in this specification, this bit SHALL be set to 1. described in this specification, this bit MUST be set to 1.
* The 'kid context' value encodes the Group Identifier value The flag bits are registered in the OSCORE Flag Bits registry
(Gid) of the group's Security Context. specified in Section 13.7 of [I-D.ietf-core-object-security] and in
Section 9.1 of this Specification.
* The following q bytes (q given by the Counter Signature o The 'kid context' value encodes the Group Identifier value (Gid)
Algorithm specified in the Security Context) encode the value of the group's Security Context.
of the 'CounterSignature0' parameter including the counter
signature of the COSE object.
* The remaining bytes in the OSCORE Option value encode the value o The remaining bytes in the OSCORE Option value encode the value of
of the 'kid' parameter, which is always present both in group the 'kid' parameter, which is always present both in group
requests and in responses. requests and in responses.
0 1 2 3 4 5 6 7 <----------- n bytes -----------> <-- 1 byte --> 0 1 2 3 4 5 6 7 <----------- n bytes ------------>
+-+-+-+-+-+-+-+-+---------------------------------+--------------+ +-+-+-+-+-+-+-+-+----------------------------------+
|0 0|1|h|1| n | Partial IV (if any) | s (if any) | |0 0|1|h|1| n | Partial IV (if any) |
+-+-+-+-+-+-+-+-+---------------------------------+--------------+ +-+-+-+-+-+-+-+-+----------------------------------+
<------ s bytes ------> <--------- q bytes ---------> <-- 1 byte --> <------ s bytes ------>
-----------------------+-----------------------------+-----------+ +--------------+-----------------------+-----------+
kid context = Gid | CounterSignature0 | kid | | s (if any) | kid context = Gid | kid |
-----------------------+-----------------------------+-----------+ +--------------+-----------------------+-----------+
Figure 2: OSCORE Option Value Figure 2: OSCORE Option Value
3.1. Example: Request 4.2. Encoding of the OSCORE Payload
Request with kid = 0x25, Partial IV = 5 and kid context = 0x44616c, The payload of the OSCORE message SHALL encode the ciphertext of the
assuming the label for the new kid context defined in COSE object concatenated with the value of the CounterSignature0 (if
present) of the COSE object, computed as in Appendix A.2 of
[RFC8152].
4.3. Examples of Compressed COSE Objects
This section covers a list of OSCORE Header Compression examples for
group requests and responses. The examples assume that the
COSE_Encrypt0 object is set (which means the CoAP message and
cryptographic material is known). Note that the examples do not
include the full CoAP unprotected message or the full security
context, but only the input necessary to the compression mechanism,
i.e. the COSE_Encrypt0 object. The output is the compressed COSE
object as defined in Section 4 and divided into two parts, since the
object is transported in two CoAP fields: OSCORE option and payload.
The examples assume that the label for the new kid context defined in
[I-D.ietf-core-object-security] has value 10. COUNTERSIGN is the [I-D.ietf-core-object-security] has value 10. COUNTERSIGN is the
CounterSignature0 byte string as described in Section 3 and is 64 CounterSignature0 byte string as described in Section 3 and is 64
bytes long in this example. The ciphertext in this example is 14
bytes long. bytes long.
1. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid =
0x25, Partial IV = 5 and kid context = 0x44616c
Before compression (96 bytes): Before compression (96 bytes):
[ [
h'', h'',
{ 4:h'25', 6:h'05', 10:h'44616c', 9:COUNTERSIGN }, { 4:h'25', 6:h'05', 10:h'44616c', 9:COUNTERSIGN },
h'aea0155667924dff8a24e4cb35b9' h'aea0155667924dff8a24e4cb35b9'
] ]
After compression (85 bytes): After compression (85 bytes):
Flag byte: 0b00111001 = 0x39 Flag byte: 0b00111001 = 0x39
Option Value: 39 05 03 44 61 6c COUNTERSIGN 25 (7 bytes + size of Option Value: 39 05 03 44 61 6c 25 (7 bytes)
COUNTERSIGN)
Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes)
3.2. Example: Response Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 COUNTERSIGN
(14 bytes + size of COUNTERSIGN)
Response with kid = 0x52. COUNTERSIGN is the CounterSignature0 byte 1. Response with ciphertext = 60b035059d9ef5667c5a0710823b, kid =
string as described in Section 3 and is 64 bytes long in this 0x52 and no Partial IV.
example. The ciphertext in this example is 14 bytes long.
Before compression (88 bytes): Before compression (88 bytes):
[ [
h'', h'',
{ 4:h'52', 9:COUNTERSIGN }, { 4:h'52', 9:COUNTERSIGN },
h'60b035059d9ef5667c5a0710823b' h'60b035059d9ef5667c5a0710823b'
] ]
After compression (80 bytes): After compression (80 bytes):
Flag byte: 0b00101000 = 0x28 Flag byte: 0b00101000 = 0x28
Option Value: 28 COUNTERSIGN 52 (2 bytes + size of COUNTERSIGN) Option Value: 28 52 (2 bytes)
Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b (14 bytes) Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b COUNTERSIGN
(14 bytes + size of COUNTERSIGN)
4. Message Processing 5. Message Binding, Sequence Numbers, Freshness and Replay Protection
The requirements and properties described in Section 7 of
[I-D.ietf-core-object-security] also apply to OSCORE used in group
communication. In particular, group OSCORE provides message binding
of responses to requests, which provides relative freshness of
responses, and replay protection of requests. More details about
error processing for replay detection in group OSCORE are specified
in Section 6 of this specification. The mechanisms describing replay
protection and freshness of Observe notifications do not apply to
group OSCORE, as Observe is not defined for group settings.
5.1. Synchronization of Sender Sequence Numbers
Upon joining the group, new servers are not aware of the Sender
Sequence Number values currently used by different clients to
transmit group requests. This means that, when such servers receive
a secure group request from a given client for the first time, they
are not able to verify if that request is fresh and has not been
replayed or (purposely) delayed. The same holds when a server loses
synchronization with Sender Sequence Numbers of clients, for instance
after a device reboot.
The exact way to address this issue is application specific, and
depends on the particular use case and its synchronization
requirements. The list of methods to handle synchronization of
Sender Sequence Numbers is part of the group communication policy,
and different servers can use different methods.
Requests sent over Multicast must be Non-Confirmable (Section 8.1 of
[RFC7252]), as overall most of the messages sent within a group.
Thus, senders should store their outgoing messages for an amount of
time defined by the application and sufficient to correctly handle
possible retransmissions.
Appendix E describes three possible approaches that can be considered
for synchronization of sequence numbers.
6. Message Processing
Each request message and response message is protected and processed Each request message and response message is protected and processed
as specified in [I-D.ietf-core-object-security], with the as specified in [I-D.ietf-core-object-security], with the
modifications described in the following sections. The following modifications described in the following sections. The following
security objectives are fulfilled, as further discussed in security objectives are fulfilled, as further discussed in
Appendix A.2: data replay protection, group-level data Appendix A.2: data replay protection, group-level data
confidentiality, source authentication, message integrity, and confidentiality, source authentication, message integrity, and
message ordering. message ordering.
Furthermore, endpoints in the group locally perform error handling Furthermore, endpoints in the group locally perform error handling
and processing of invalid messages according to the same principles and processing of invalid messages according to the same principles
adopted in [I-D.ietf-core-object-security]. However, a receiver adopted in [I-D.ietf-core-object-security]. However, a recipient
endpoint MUST stop processing and silently reject any message which MUST stop processing and silently reject any message which is
is malformed and does not follow the format specified in Section 3, malformed and does not follow the format specified in Section 3, or
without sending back any error message. This prevents servers from which is not cryptographically validated in a successful way. Either
replying with multiple error messages to a client sending a group case, the recipient MUST NOT send back any error message. This
request, so avoiding the risk of flooding and possibly congesting the prevents servers from replying with multiple error messages to a
group. client sending a group request, so avoiding the risk of flooding and
possibly congesting the group.
4.1. Protecting the Request As per [RFC7252][RFC7390], group requests sent over multicast must be
Non-confirmable. However, this does not prevent the acknowledgment
of Confirmable group requests in non-multicast environments.
6.1. Protecting the Request
A client transmits a secure group request as described in Section 8.1 A client transmits a secure group request as described in Section 8.1
of [I-D.ietf-core-object-security], with the following modifications. of [I-D.ietf-core-object-security], with the following modifications.
o In step 2, the 'algorithms' array in the Additional Authenticated o In step 2, the 'algorithms' array in the Additional Authenticated
Data is modified as described in Section 3. Data is modified as described in Section 3.
o In step 4, the encoding of the compressed COSE object is modified o In step 4, the encryption of the COSE object is modified as
as described in Section 3. described in Section 3. The encoding of the compressed COSE
object is modified as described in Section 4.
4.2. Verifying the Request 6.2. Verifying the Request
Upon receiving a secure group request, a server proceeds as described Upon receiving a secure group request, a server proceeds as described
in Section 8.2 of [I-D.ietf-core-object-security], with the following in Section 8.2 of [I-D.ietf-core-object-security], with the following
modifications. modifications.
o In step 2, the decoding of the compressed COSE object is modified o In step 2, the decoding of the compressed COSE object follows
as described in Section 3. If the received Recipient ID ('kid') Section 4. If the received Recipient ID ('kid') does not match
does not match with any Recipient Context for the retrieved Group with any Recipient Context for the retrieved Gid ('kid context'),
ID ('kid context'), then the server creates a new Recipient then the server creates a new Recipient Context, initializes it
Context, initializes it according to Section 3 of according to Section 3 of [I-D.ietf-core-object-security], also
[I-D.ietf-core-object-security], and includes the client's public retrieving the client's public key.
key.
o In step 4, the 'algorithms' array in the Additional Authenticated o In step 4, the 'algorithms' array in the Additional Authenticated
Data is modified as described in Section 3. Data is modified as described in Section 3.
o In step 6, the server also verifies the counter signature using o In step 6, the server also verifies the counter signature using
the public key of the client from the associated Recipient the public key of the client from the associated Recipient
Context. Context.
4.3. Protecting the Response 6.3. Protecting the Response
A server that has received a secure group request may reply with a A server that has received a secure group request may reply with a
secure response, which is protected as described in Section 8.3 of secure response, which is protected as described in Section 8.3 of
[I-D.ietf-core-object-security], with the following modifications. [I-D.ietf-core-object-security], with the following modifications.
o In step 2, the 'algorithms' array in the Additional Authenticated o In step 2, the 'algorithms' array in the Additional Authenticated
Data is modified as described in Section 3. Data is modified as described in Section 3.
o In step 4, the encoding of the compressed COSE object is modified o In step 4, the encryption of the COSE object is modified as
as described in Section 3. described in Section 3. The encoding of the compressed COSE
object is modified as described in Section 4.
4.4. Verifying the Response 6.4. Verifying the Response
Upon receiving a secure response message, the client proceeds as Upon receiving a secure response message, the client proceeds as
described in Section 8.4 of [I-D.ietf-core-object-security], with the described in Section 8.4 of [I-D.ietf-core-object-security], with the
following modifications. following modifications.
o In step 2, the decoding of the compressed COSE object is modified o In step 2, the decoding of the compressed COSE object is modified
as described in Section 3. If the received Recipient ID ('kid') as described in Section 3. If the received Recipient ID ('kid')
does not match with any Recipient Context for the retrieved Group does not match with any Recipient Context for the retrieved Gid
ID ('kid context'), then the client creates a new Recipient ('kid context'), then the client creates a new Recipient Context,
Context, initializes it according to Section 3 of initializes it according to Section 3 of
[I-D.ietf-core-object-security], and includes the server's public [I-D.ietf-core-object-security], also retrieving the server's
key. public key.
o In step 3, the 'algorithms' array in the Additional Authenticated o In step 3, the 'algorithms' array in the Additional Authenticated
Data is modified as described in Section 3. Data is modified as described in Section 3.
o In step 5, the client also verifies the counter signature using o In step 5, the client also verifies the counter signature using
the public key of the server from the associated Recipient the public key of the server from the associated Recipient
Context. Context.
5. Synchronization of Sequence Numbers 7. Responsibilities of the Group Manager
Upon joining the group, new servers are not aware of the sequence
number values currently used by different clients to transmit group
requests. This means that, when such servers receive a secure group
request from a given client for the first time, they are not able to
verify if that request is fresh and has not been replayed. The same
holds when a server loses synchronization with sequence numbers of
clients, for instance after a device reboot.
The exact way to address this issue depends on the specific use case
and its synchronization requirements. The list of methods to handle
synchronization of sequence numbers is part of the group
communication policy, and different servers can use different
methods. Appendix E describes three possible approaches that can be
considered.
6. Responsibilities of the Group Manager
The Group Manager is responsible for performing the following tasks: The Group Manager is responsible for performing the following tasks:
o Creating and managing OSCORE groups. This includes the assignment 1. Creating and managing OSCORE groups. This includes the
of a Group ID to every newly created group, as well as ensuring assignment of a Gid to every newly created group, as well as
uniqueness of Group IDs within the set of its OSCORE groups. ensuring uniqueness of Gids within the set of its OSCORE groups.
o Defining policies for authorizing the joining of its OSCORE
groups. Such policies can be enforced by a third party, which is
in a trust relation with the Group Manager and enforces join
policies on behalf of the Group Manager.
o Driving the join process to add new endpoints as group members.
o Establishing Security Common Contexts and providing them to
authorized group members during the join process, together with a
corresponding Security Sender Context.
o Generating and managing Endpoint IDs within its OSCORE groups, as
well as assigning and providing them to new endpoints during the
join process. This includes ensuring uniqueness of Endpoints IDs
within each of its OSCORE groups.
o Defining a set of supported signature algorithms as part of the 2. Defining policies for authorizing the joining of its OSCORE
communication policy of each of its OSCORE groups, and signalling groups. Such policies can be enforced locally by the Group
it to new endpoints during the join process. Manager, or by a third party in a trust relation with the Group
Manager and entrusted to enforce join policies on behalf of the
Group Manager.
o Defining the methods to handle loss of synchronization with 3. Driving the join process to add new endpoints as group members.
sequence numbers as part of the communication policy of each of
its OSCORE groups, and signaling the one(s) to use to new
endpoints during the join process.
o Renewing the Security Context of an OSCORE group upon membership 4. Establishing Security Common Contexts and providing them to
change, by revoking and renewing common security parameters and authorized group members during the join process, together with
keying material (rekeying). a corresponding Security Sender Context.
o Providing the management keying material that a new endpoint 5. Generating and managing Sender IDs within its OSCORE groups, as
requires to participate in the rekeying process, consistently with well as assigning and providing them to new endpoints during the
the key management scheme used in the group joined by the new join process. This includes ensuring uniqueness of Sender IDs
endpoint. within each of its OSCORE groups.
o Updating the Group ID of its OSCORE groups, upon renewing the 6. Defining a communication policy for each of its OSCORE groups,
respective Security Context. and signalling it to new endpoints during the join process.
The Group Manager may additionally be responsible for the following 7. Renewing the Security Context of an OSCORE group upon membership
tasks: change, by revoking and renewing common security parameters and
keying material (rekeying).
o Acting as trusted key repository, in order to store the public 8. Providing the management keying material that a new endpoint
keys of the members of its OSCORE groups, and provide such public requires to participate in the rekeying process, consistent with
keys to other members of the same group upon request. This the key management scheme used in the group joined by the new
specification recommends that the Group Manager is entrusted to endpoint.
perform this task.
o Acting as network router device where endpoints register to 9. Updating the Gid of its OSCORE groups, upon renewing the
correctly receive group messages sent to the multicast IP address respective Security Context.
of that group.
o Autonomously and locally enforcing access policies to authorize 10. Acting as key repository, in order to handle the public keys of
new endpoints to join its OSCORE groups. the members of its OSCORE groups, and providing such public keys
to other members of the same group upon request. The actual
storage of public keys may be entrusted to a separate secure
storage device.
7. Security Considerations 8. Security Considerations
The same security considerations from OSCORE (Section 11 of The same security considerations from OSCORE (Section 11 of
[I-D.ietf-core-object-security]) apply to this specification. [I-D.ietf-core-object-security]) apply to this specification.
Additional security aspects to be taken into account are discussed Additional security aspects to be taken into account are discussed
below. below.
7.1. Group-level Security 8.1. Group-level Security
The approach described in this document relies on commonly shared The approach described in this document relies on commonly shared
group keying material to protect communication within a group. This group keying material to protect communication within a group. This
means that messages are encrypted at a group level (group-level data has the following implications.
confidentiality), i.e. they can be decrypted by any member of the
group, but not by an external adversary or other external entities.
In addition, it is required that all group members are trusted, i.e. o Messages are encrypted at a group level (group-level data
they do not forward the content of group messages to unauthorized confidentiality), i.e. they can be decrypted by any member of the
entities. However, in many use cases, the devices in the group group, but not by an external adversary or other external
belong to a common authority and are configured by a commissioner entities.
(see Appendix B).
7.2. Uniqueness of (key, nonce) o The AEAD algorithm provides only group authentication, i.e. it
ensures that a message sent to a group has been sent by a member
of that group, but not by the alleged sender. This is why source
authentication of messages sent to a group is ensured through a
counter signature, which is computed by the sender using its own
private key and then appended to the message payload.
Note that, even if an endpoint is authorized to be a group member and
to take part in group communications, there is a risk that it behaves
inappropriately. For instance, it can forward the content of
messages in the group to unauthorized entities. However, in many use
cases, the devices in the group belong to a common authority and are
configured by a commissioner (see Appendix B), which results in a
practically limited risk and enables a prompt detection/reaction in
case of misbehaving.
8.2. Uniqueness of (key, nonce)
The proof for uniqueness of (key, nonce) pairs in Appendix D.3 of The proof for uniqueness of (key, nonce) pairs in Appendix D.3 of
[I-D.ietf-core-object-security] is also valid in group communication [I-D.ietf-core-object-security] is also valid in group communication
scenarios. That is, given an OSCORE group: scenarios. That is, given an OSCORE group:
o Uniqueness of Sender IDs within the group is enforced by the Group o Uniqueness of Sender IDs within the group is enforced by the Group
Manager. Manager.
o Case A is limited to requests, and same considerations hold. o The case A in Appendix D.3 of [I-D.ietf-core-object-security] for
messages including a Partial IV concerns only group requests, and
same considerations from [I-D.ietf-core-object-security] apply
here as well.
o Case B applies to all responses, and same considerations hold. o The case B in Appendix D.3 of [I-D.ietf-core-object-security] for
messages not including a Partial IV concerns all group responses,
and same considerations from [I-D.ietf-core-object-security] apply
here as well.
It follows that each message encrypted/decrypted with the same Sender As a consequence, each message encrypted/decrypted with the same
Key is processed by using a different (ID_PIV, PIV) pair. This means Sender Key is processed by using a different (ID_PIV, PIV) pair.
that nonces used by any fixed encrypting endpoint are unique. Thus, This means that nonces used by any fixed encrypting endpoint are
each message is processed with a different (key, nonce) pair. unique. Thus, each message is processed with a different (key,
nonce) pair.
7.3. Collision of Group Identifiers 8.3. Management of Group Keying Material
The approach described in this specification should take into account
the risk of compromise of group members. In particular, this
document specifies that a key management scheme for secure revocation
and renewal of Security Contexts and group keying material should be
adopted.
Especially in dynamic, large-scale, groups where endpoints can join
and leave at any time, it is important that the considered group key
management scheme is efficient and highly scalable with the group
size, in order to limit the impact on performance due to the Security
Context and keying material update.
8.4. Update of Security Context and Key Rotation
A group member can receive a message shortly after the group has been
rekeyed, and new security parameters and keying material have been
distributed by the Group Manager. In the following two cases, this
may result in misaligned Security Contexts between the sender and the
recipient.
In the first case, the sender protects a message using the old
Security Context, i.e. before having installed the new Security
Context. However, the recipient receives the message after having
installed the new Security Context, hence not being able to correctly
process it. A possible way to ameliorate this issue is to preserve
the old, recent, Security Context for a maximum amount of time
defined by the application. By doing so, the recipient can still try
to process the received message using the old retained Security
Context as second attempt. Note that a former (compromised) group
member can take advantage of this by sending messages protected with
the old retained Security Context. Therefore, a conservative
application policy should not admit the storage of old Security
Contexts.
In the second case, the sender protects a message using the new
Security Context, but the recipient receives that request before
having installed the new Security Context. Therefore, the recipient
would not be able to correctly process the request and hence discards
it. If the recipient receives the new Security Context shortly after
that and the sender endpoint uses CoAP retransmissions, the former
will still be able to receive and correctly process the message. In
any case, the recipient should actively ask the Group Manager for an
updated Security Context according to an application-defined policy,
for instance after a given number of unsuccessfully decrypted
incoming messages.
8.5. Collision of Group Identifiers
In case endpoints are deployed in multiple groups managed by In case endpoints are deployed in multiple groups managed by
different non-synchronized Group Managers, it is possible for Group different non-synchronized Group Managers, it is possible for Group
Identifiers of different groups to coincide. However, this does not Identifiers of different groups to coincide. That can also happen if
impair the security of the AEAD algorithm. the application can not guarantee unique Group Identifiers within a
given Group Manager. However, this does not impair the security of
the AEAD algorithm.
In fact, as long as the Master Secret is different for different In fact, as long as the Master Secret is different for different
groups and this condition holds over time, and as long as the Sender groups and this condition holds over time, and as long as the Sender
IDs within a group are unique, it follows that AEAD keys and nonces IDs within a group are unique, AEAD keys are different among
are different among different groups. different groups.
8. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. Note to RFC Editor: Please replace all occurrences of "[[this
document]]" with the RFC number of this specification.
9. Acknowledgments 9.1. OSCORE Flag Bits Registry
The authors sincerely thank Stefan Beck, Rolf Blom, Carsten Bormann, The entry with Bit Position TBD is added to the "OSCORE Flag Bits"
Esko Dijk, Klaus Hartke, Richard Kelsey, John Mattsson, Jim Schaad, registry.
Ludwig Seitz and Peter van der Stok for their feedback and comments.
The work on this document has been partly supported by the EIT- +--------------+-------------+---------------------+-------------------+
Digital High Impact Initiative ACTIVE. | Bit Position | Name | Description | Specification |
+--------------+-------------+---------------------+-------------------+
| TBD | Counter | Set to 1 if counter | [[this document]] |
| | Signature | signature present | |
| | | in the compressed | |
| | | COSE object | |
+--------------+-------------+---------------------+-------------------+
10. References 10. References
10.1. Normative References 10.1. Normative References
[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-13 (work in (OSCORE)", draft-ietf-core-object-security-15 (work in
progress), June 2018. progress), August 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 7 skipping to change at page 19, line 11
[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>.
[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>.
10.2. Informative References 10.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.
[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-12 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16
(work in progress), May 2018. (work in progress), October 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-01 (work in progress), March 2018.
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "Echo and Amsuess, C., Mattsson, J., and G. Selander, "Echo and
Request-Tag", draft-ietf-core-echo-request-tag-01 (work in Request-Tag", draft-ietf-core-echo-request-tag-02 (work in
progress), March 2018. 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.
[I-D.somaraju-ace-multicast] [I-D.somaraju-ace-multicast]
Somaraju, A., Kumar, S., Tschofenig, H., and W. Werner, Somaraju, A., Kumar, S., Tschofenig, H., and W. Werner,
"Security for Low-Latency Group Communication", draft- "Security for Low-Latency Group Communication", draft-
somaraju-ace-multicast-02 (work in progress), October somaraju-ace-multicast-02 (work in progress), October
2016. 2016.
[I-D.tiloca-ace-oscoap-joining] [I-D.tiloca-ace-oscoap-joining]
Tiloca, M. and J. Park, "Joining OSCORE groups in ACE", Tiloca, M., Park, J., and F. Palombini, "Key Management
draft-tiloca-ace-oscoap-joining-03 (work in progress), for OSCORE Groups in ACE", draft-tiloca-ace-oscoap-
March 2018. joining-05 (work in progress), October 2018.
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093,
DOI 10.17487/RFC2093, July 1997,
<https://www.rfc-editor.org/info/rfc2093>.
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094,
DOI 10.17487/RFC2094, July 1997,
<https://www.rfc-editor.org/info/rfc2094>.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627,
DOI 10.17487/RFC2627, June 1999,
<https://www.rfc-editor.org/info/rfc2627>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004,
<https://www.rfc-editor.org/info/rfc3740>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005,
<https://www.rfc-editor.org/info/rfc4046>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, DOI 10.17487/RFC4535, June 2006,
<https://www.rfc-editor.org/info/rfc4535>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[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",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[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>.
skipping to change at page 19, line 18 skipping to change at page 21, line 5
able to adequately support different and possibly large groups. able to adequately support different and possibly large groups.
The group size is the current number of members in a group. In The group size is the current number of members in a group. In
the use cases mentioned in this document, the number of clients the use cases mentioned in this document, the number of clients
(normally the controlling devices) is expected to be much smaller (normally the controlling devices) is expected to be much smaller
than the number of servers (i.e. the controlled devices). A than the number of servers (i.e. the controlled devices). A
security solution for group communication that supports 1 to 50 security solution for group communication that supports 1 to 50
clients would be able to properly cover the group sizes required clients would be able to properly cover the group sizes required
for most use cases that are relevant for this document. The for most use cases that are relevant for this document. The
maximum group size is expected to be in the range of 2 to 100 maximum group size is expected to be in the range of 2 to 100
devices. Groups larger than that should be divided into smaller devices. Groups larger than that should be divided into smaller
independent groups, e.g. by grouping lights in a building on a per independent groups.
floor basis.
o Communication with the Group Manager: an endpoint must use a o Communication with the Group Manager: an endpoint must use a
secure dedicated channel when communicating with the Group secure dedicated channel when communicating with the Group
Manager, even when not registered as group member. In particular, Manager, also when not registered as group member.
communications with the Group Manager occuring during the join
process to become a group member must also be secured.
o Establishment and management of Security Contexts: an OSCORE o Provisioning and management of Security Contexts: an OSCORE
Security Context must be established among the group members. In Security Context must be established among the group members. A
particular, a Common Context must be provided to a new joining secure mechanism must be used to generate, revoke and
endpoint together with a corresponding Sender Context. On the (re-)distribute keying material, multicast security policies and
other hand, Recipient Contexts are locally and individually security parameters in the group. The actual provisioning and
derived by each group member. A secure mechanism must be used to management of the Security Context is out of the scope of this
generate, revoke and (re-)distribute keying material, multicast document.
security policies and security parameters in the group. The
actual establishment and management of the Security Context is out
of the scope of this document, and it is anticipated that an
activity in IETF dedicated to the design of a generic key
management scheme will include this feature, preferably based on
[RFC3740][RFC4046][RFC4535].
o Multicast data security ciphersuite: all group members must agree o Multicast data security ciphersuite: all group members must agree
on a ciphersuite to provide authenticity, integrity and on a ciphersuite to provide authenticity, integrity and
confidentiality of messages in the group. The ciphersuite is confidentiality of messages in the group. The ciphersuite is
specified as part of the Security Context. specified as part of the Security Context.
o Backward security: a new device joining the group should not have o Backward security: a new device joining the group should not have
access to any old Security Contexts used before its joining. This access to any old Security Contexts used before its joining. This
ensures that a new group member is not able to decrypt ensures that a new group member is not able to decrypt
confidential data sent before it has joined the group. The confidential data sent before it has joined the group. The
skipping to change at page 20, line 45 skipping to change at page 22, line 24
authenticated. That is, it is essential to ensure that a message authenticated. That is, it is essential to ensure that a message
is originated by a member of the group in the first place, and in is originated by a member of the group in the first place, and in
particular by a specific member of the group. particular by a specific member of the group.
o Message integrity: messages sent within the group shall be o Message integrity: messages sent within the group shall be
integrity protected. That is, it is essential to ensure that a integrity protected. That is, it is essential to ensure that a
message has not been tampered with by an external adversary or message has not been tampered with by an external adversary or
other external entities which are not group members. other external entities which are not group members.
o Message ordering: it must be possible to determine the ordering of o Message ordering: it must be possible to determine the ordering of
messages coming from a single sender endpoint. In accordance with messages coming from a single sender. In accordance with OSCORE
OSCORE [I-D.ietf-core-object-security], this results in providing [I-D.ietf-core-object-security], this results in providing
relative freshness of group requests and absolute freshness of relative freshness of group requests and absolute freshness of
responses. It is not required to determine ordering of messages responses. It is not required to determine ordering of messages
from different sender endpoints. from different senders.
Appendix B. List of Use Cases Appendix B. List of Use Cases
Group Communication for CoAP [RFC7390] provides the necessary Group Communication for CoAP [RFC7390] provides the necessary
background for multicast-based CoAP communication, with particular background for multicast-based CoAP communication, with particular
reference to low-power and lossy networks (LLNs) and resource reference to low-power and lossy networks (LLNs) and resource
constrained environments. The interested reader is encouraged to constrained environments. The interested reader is encouraged to
first read [RFC7390] to understand the non-security related details. first read [RFC7390] to understand the non-security related details.
This section discusses a number of use cases that benefit from secure This section discusses a number of use cases that benefit from secure
group communication. Specific security requirements for these use group communication. Specific security requirements for these use
skipping to change at page 23, line 42 skipping to change at page 25, line 19
group members increment by 1 the Group Epoch in the Group Identifier group members increment by 1 the Group Epoch in the Group Identifier
of that group. of that group.
As an example, a 3-byte Group Identifier can be composed of: i) a As an example, a 3-byte Group Identifier can be composed of: i) a
1-byte Group Prefix '0xb1' interpreted as a raw byte string; and ii) 1-byte Group Prefix '0xb1' interpreted as a raw byte string; and ii)
a 2-byte Group Epoch interpreted as an unsigned integer ranging from a 2-byte Group Epoch interpreted as an unsigned integer ranging from
0 to 65535. Then, after having established the Security Common 0 to 65535. Then, after having established the Security Common
Context 61532 times in the group, its Group Identifier will assume Context 61532 times in the group, its Group Identifier will assume
value '0xb1f05c'. value '0xb1f05c'.
As discussed in Section 7.3, if endpoints are deployed in multiple Using an immutable Group Prefix for a group assumes that enough time
elapses between two consecutive usages of the same Group Epoch value
in that group. This ensures that the Gid value is temporally unique
during the lifetime of a given message. Thus, the expected highest
rate for addition/removal of group members and consequent group
rekeying should be taken into account for a proper dimensioning of
the Group Epoch size.
As discussed in Section 8.5, if endpoints are deployed in multiple
groups managed by different non-synchronized Group Managers, it is groups managed by different non-synchronized Group Managers, it is
possible that Group Identifiers of different groups coincide at some possible that Group Identifiers of different groups coincide at some
point in time. In this case, a recipient endpoint has to handle point in time. In this case, a recipient has to handle coinciding
coinciding Group Identifiers, and has to try using different OSCORE Group Identifiers, and has to try using different OSCORE Security
Security Contexts to process an incoming message, until the right one Contexts to process an incoming message, until the right one is found
is found and the message is correctly verified. Therefore, it is and the message is correctly verified. Therefore, it is favourable
favourable that Group Idenfiers from different Group Managers have a that Group Identifiers from different Group Managers have a size that
size that result in a small probability of collision. How small this result in a small probability of collision. How small this
probability should be is up to system designers. probability should be is up to system designers.
Appendix D. Set-up of New Endpoints Appendix D. Set-up of New Endpoints
An endpoint joins a group by explicitly interacting with the An endpoint joins a group by explicitly interacting with the
responsible Group Manager. Communications between a joining endpoint responsible Group Manager. When becoming members of a group,
and the Group Manager rely on the CoAP protocol and must be secured. endpoints are not required to know how many and what endpoints are in
Specific details on how to secure communications between joining the same group.
endpoints and a Group Manager are out of scope.
In order to receive multicast messages sent to the group, a joining
endpoint has to register with a network router device
[RFC3376][RFC3810], signaling its intent to receive packets sent to
the multicast IP address of that group. As a particular case, the
Group Manager can also act as such a network router device. Upon
joining the group, endpoints are not required to know how many and
what endpoints are active in the same group.
Furthermore, in order to participate in the secure group
communication, an endpoint needs to be properly initialized upon
joining the group. In particular, the Group Manager provides keying
material and parameters to a joining endpoint, which can then
initialize its own Security Context (see Section 2).
The following Appendix D.1 provides an example describing how such
information can be provided to an endpoint upon joining a group
through the responsible Group Manager. Then, Appendix D.2 discusses
how public keys of group members can be handled and made available to
group members. Finally, Appendix D.3 overviews how the ACE framework
for Authentication and Authorization in constrained environments
[I-D.ietf-ace-oauth-authz] can be possibly used to support such a
join process.
D.1. Join Process
An endpoint requests to join a group by sending a confirmable CoAP
POST request to the Group Manager responsible for that group. This
join request can reflect the format of the Key Distribution Request
message defined in Section 4.1 of [I-D.palombini-ace-key-groupcomm].
Besides, it can be addressed to a CoAP resource associated to that
group and carries the following information.
o Group identifier: the Group Identifier (Gid) of the group, as
known to the joining endpoint at this point in time. This may not
fully coincide with the Gid currently associated to the group,
e.g. if it includes a dynamic component. This information can be
mapped to the first element of the 'scope' parameter of the Key
Distribution Request message defined in Section 4.1 of
[I-D.palombini-ace-key-groupcomm].
o Role: the exact role of the joining endpoint in the group.
Possible values are: "client", "server", "silent server", "client
and server", or "client and silent server". This information can
be mapped to the second element of the 'scope' parameter of the
Key Distribution Request message defined in Section 4.1 of
[I-D.palombini-ace-key-groupcomm].
o Retrieval flag: indication of interest to receive the public keys
of the endpoints currently in the group, as included in the
following join response. This flag must not be present if the
Group Manager is not configured to store the public keys of group
members, or if the joining endpoint is configured exclusively as
silent server for the group to join. This information can be
mapped to the 'get_pub_keys' parameter of the Key Distribution
Request message defined in Section 4.1 of
[I-D.palombini-ace-key-groupcomm].
o Identity credentials: information elements to enforce source Communications between a joining endpoint and the Group Manager rely
authentication of group messages from the joining endpoint, such on the CoAP protocol and must be secured. Specific details on how to
as its public key. The exact content depends on whether the Group secure communications between joining endpoints and a Group Manager
Manager is configured to store the public keys of group members. are out of the scope of this document.
If this is the case, this information is omitted if it has been
provided to the same Group Manager upon previously joining the
same or a different group under its control. This information is
also omitted if the joining endpoint is configured exclusively as
silent server for the joined group. Appendix D.2 discusses
additional details on provisioning of public keys and other
information to enforce source authentication of joining
endpoints's messages. This information can be mapped to the
'client_cred' parameter of the Key Distribution Request message
defined in Section 4.1 of [I-D.palombini-ace-key-groupcomm].
The Group Manager must be able to verify that the joining endpoint is The Group Manager must verify that the joining endpoint is authorized
authorized to become a member of the group. To this end, the Group to join the group. To this end, the Group Manager can directly
Manager can directly authorize the joining endpoint, or expect it to authorize the joining endpoint, or expect it to provide authorization
provide authorization evidence previously obtained from a trusted evidence previously obtained from a trusted entity. Further details
entity. Appendix D.3 describes how this can be achieved by about the authorization of joining endpoints are out of scope.
leveraging the ACE framework for Authentication and Authorization in
constrained environments [I-D.ietf-ace-oauth-authz].
In case of successful authorization check, the Group Manager In case of successful authorization check, the Group Manager
generates an Endpoint ID assigned to the joining endpoint, before generates a Sender ID assigned to the joining endpoint, before
proceeding with the rest of the join process. Instead, in case the proceeding with the rest of the join process. That is, the Group
authorization check fails, the Group Manager aborts the join process. Manager provides the joining endpoint with the keying material and
Further details about the authorization of joining endpoint are out parameters to initialize the OSCORE Security Context (see Section 2).
of scope. The actual provisioning of keying material and parameters to the
joining endpoint is out of the scope of this document.
As discussed in Section 2.1, it is recommended that the Security
Context is renewed before the joining endpoint receives the group
keying material and becomes a new active member of the group. This
is achieved by securely distributing a new Master Secret and a new
Group Identifier to the endpoints currently present in the same
group.
Once renewed the Security Context in the group, the Group Manager
replies to the joining endpoint with a CoAP response carrying the
following information. This join response can reflect the format of
the Key Distribution Response message defined in Section 4.2 of
[I-D.palombini-ace-key-groupcomm].
o Security Common Context: the OSCORE Security Common Context
associated to the joined group (see Section 2). This information
can be mapped to the 'key' parameter of the Key Distribution
Response message defined in Section 4.2 of
[I-D.palombini-ace-key-groupcomm].
o Endpoint ID: the Endpoint ID associated to the joining endpoint.
This information is not included in case 'Role' in the join
request is equal to "silent server". This information can be
mapped to the 'clientID' parameter within the 'key' parameter of
the Key Distribution Response message defined in Section 4.2 of
[I-D.palombini-ace-key-groupcomm].
o Member public keys: the public keys of the endpoints currently
present in the group. This includes: the public keys of the non-
silent servers currently in the group, if the joining endpoint is
configured (also) as client; and the public keys of the clients
currently in the group, if the joining endpoint is configured
(also) as server or silent server. This information is omitted in
case the Group Manager is not configured to store the public keys
of group members or if the 'Retrieval flag' was not present in the
join request. Appendix D.2 discusses additional details on
provisioning public keys upon joining the group and on retrieving
public keys of group members. This information can be mapped to
the 'pub_keys' parameter of the Key Distribution Response message
defined in Section 4.2 of [I-D.palombini-ace-key-groupcomm].
o Group policies: a list of key words indicating the particular
policies enforced in the group. This includes, for instance, the
method to achieve synchronization of sequence numbers among group
members (see Appendix E), as well as the rekeying protocol used to
renew the keying material in the group (see Section 2.1). This
information can be mapped to the 'group_policies' parameter of the
Key Distribution Response message defined in Section 4.2 of
[I-D.palombini-ace-key-groupcomm].
o Management keying material: the set of administrative keying
material used to participate in the group rekeying process run by
the Group Manager (see Section 2.1). The specific elements of
this management keying material depend on the group rekeying
protocol used in the group. For instance, this can simply consist
in a group key encryption key and a pairwise symmetric key shared
between the joining endpoint and the Group Manager, in case GKMP
[RFC2093][RFC2094] is used. Instead, if key-tree based rekeying
protocols like LKH [RFC2627] are used, it can consist in the set
of symmetric keys associated to the key-tree leaf representing the
group member up to the key-tree root representing the group key
encryption key. This information can be mapped to the
'mgt_key_material' parameter of the Key Distribution Response
message defined in Section 4.2 of
[I-D.palombini-ace-key-groupcomm].
D.2. Provisioning and Retrieval of Public Keys
As mentioned in Section 6, it is recommended that the Group Manager
acts as trusted key repository, so storing public keys of group
members and providing them to other members of the same group upon
request. In such a case, a joining endpoint provides its own public
key to the Group Manager, as 'Identity credentials' of the join
request, when joining the group (see Appendix D.1).
After that, the Group Manager should verify that the joining endpoint
actually owns the associated private key, for instance by performing
a proof-of-possession challenge-response, whose details are out of
scope. In case of failure, the Group Manager performs up to a pre-
defined maximum number of retries, after which it aborts the join
process.
In case of successful challenge-response, the Group Manager stores
the received public key as associated to the joining endpoint and its
Endpoint ID. From then on, that public key will be available for
secure and trusted delivery to other endpoints in the group. A
possible approach for a group member to retrieve the public key of
other group members is described in Section 7 of
[I-D.palombini-ace-key-groupcomm].
Finally, the Group Manager sends the join response to the joining
endpoint, as described in Appendix D.1.
The joining endpoint does not have to provide its own public key if
that already occurred upon previously joining the same or a different
group under the same Group Manager. However, separately for each
group under its control, the Group Manager maintains an updated list
of active Endpoint IDs associated to the respective endpoint's public
key.
Instead, in case the Group Manager does not act as trusted key
repository, the following exchange with the Group Manager can occur
during the join process.
1. The joining endpoint signs its own certificate by using its own
private key. The certificate includes also the identifier of the
issuer Certification Authority (CA). There is no restriction on
the Certificate Subject included in the joining endpoint's
certificate.
2. The joining endpoint specifies the signed certificate as
'Identity credentials' in the join request (Appendix D.1). The
joining endpoint can optionally specify also a list of public key
repositories storing its own certificate. In such a case, this
information can be mapped to the 'pub_keys_repos' parameter of
the Key Distribution Request message defined in Section 4.1 of
[I-D.palombini-ace-key-groupcomm].
3. When processing the join request, the Group Manager first
validates the certificate by verifying the signature of the
issuer CA, and then verifies the signature of the joining
endpoint.
4. The Group Manager stores the association between the Certificate
Subject of the joining endpoint's certificate and the pair {Group
ID, Endpoint ID of the joining endpoint}. If received from the
joining endpoint, the Group Manager also stores the list of
public key repositories storing the certificate of the joining
endpoint.
When a group member X wants to retrieve the public key of another
group member Y in the same group, the endpoint X proceeds as follows.
1. The endpoint X contacts the Group Manager, specifying the pair
{Group ID, Endpoint ID of the endpoint Y}.
2. The Group Manager provides the endpoint X with the Certificate
Subject CS from the certificate of endpoint Y. If available, the
Group Manager provides the endpoint X also with the list of
public key repositories storing the certificate of the endpoint
Y.
3. The endpoint X retrieves the certificate of the endpoint X from a
key repository storing it, by using the Certificate Subject CS.
D.3. Group Joining Based on the ACE Framework
The join process to register an endpoint as a new member of a group
can be based on the ACE framework for Authentication and
Authorization in constrained environments [I-D.ietf-ace-oauth-authz],
built on re-use of OAuth 2.0 [RFC6749].
In particular, the approach described in
[I-D.tiloca-ace-oscoap-joining] uses the ACE framework to delegate
the authentication and authorization of joining endpoints to an
Authorization Server in a trust relation with the Group Manager. At
the same time, it allows a joining endpoint to establish a secure
channel with the Group Manager, by leveraging protocol-specific
profiles of ACE, such as [I-D.ietf-ace-oscore-profile] and
[I-D.ietf-ace-dtls-authorize], to achieve communication security,
proof-of-possession and server authentication.
More specifically and with reference to the terminology defined in
OAuth 2.0:
o The joining endpoint acts as ACE Client;
o The Group Manager acts as ACE Resource Server, with different CoAP
resources for different groups it is responsible for;
o An Authorization Server enables and enforces authorized access of
the joining endpoint to the Group Manager and its CoAP resources
paired with groups to join.
Messages exchanged among the participants follow the formats defined It is RECOMMENDED that the join process adopts the approach described
in [I-D.palombini-ace-key-groupcomm]. Both the joining endpoint and in [I-D.tiloca-ace-oscoap-joining] and based on the ACE framework for
the Group Manager have to adopt secure communication also for any Authentication and Authorization in constrained environments
message exchange with the Authorization Server. To this end, [I-D.ietf-ace-oauth-authz].
different alternatives are possible, such as OSCORE, DTLS [RFC6347]
or IPsec [RFC4301].
Appendix E. Examples of Synchronization Approaches Appendix E. Examples of Synchronization Approaches
This section describes three possible approaches that can be This section describes three possible approaches that can be
considered by server endpoints to synchronize with sequence numbers considered by server endpoints to synchronize with sender sequence
of client endpoints sending group requests. numbers of client endpoints sending group requests.
E.1. Best-Effort Synchronization E.1. Best-Effort Synchronization
Upon receiving a group request from a client, a server does not take Upon receiving a group request from a client, a server does not take
any action to synchonize with the sequence number of that client. any action to synchonize with the sender sequence number of that
This provides no assurance at all as to message freshness, which can client. This provides no assurance at all as to message freshness,
be acceptable in non-critical use cases. which can be acceptable in non-critical use cases.
E.2. Baseline Synchronization E.2. Baseline Synchronization
Upon receiving a group request from a given client for the first Upon receiving a group request from a given client for the first
time, a server initializes its last-seen sequence number in its time, a server initializes its last-seen sender sequence number in
Recipient Context associated to that client. However, the server its Recipient Context associated to that client. However, the server
drops the group request without delivering it to the application drops the group request without delivering it to the application
layer. This provides a reference point to identify if future group layer. This provides a reference point to identify if future group
requests from the same client are fresher than the last one received. requests from the same client are fresher than the last one received.
A replay time interval exists, between when a possibly replayed A replay time interval exists, between when a possibly replayed or
message is originally transmitted by a given client and the first delayed message is originally transmitted by a given client and the
authentic fresh message from that same client is received. This can first authentic fresh message from that same client is received.
be acceptable for use cases where servers admit such a trade-off This can be acceptable for use cases where servers admit such a
between performance and assurance of message freshness. trade-off between performance and assurance of message freshness.
E.3. Challenge-Response Synchronization E.3. Challenge-Response Synchronization
A server performs a challenge-response exchange with a client, by A server performs a challenge-response exchange with a client, by
using the Echo Option for CoAP described in Section 2 of using the Echo Option for CoAP described in Section 2 of
[I-D.ietf-core-echo-request-tag] and consistently with what specified [I-D.ietf-core-echo-request-tag] and according to Section 7.5.2 of
in Section 7.5.2 of [I-D.ietf-core-object-security]. [I-D.ietf-core-object-security].
That is, upon receiving a group request from a particular client for That is, upon receiving a group request from a particular client for
the first time, the server processes the message as described in the first time, the server processes the message as described in
Section 4.2 of this specification, but, even if valid, does not Section 6.2 of this specification, but, even if valid, does not
deliver it to the application. Instead, the server replies to the deliver it to the application. Instead, the server replies to the
client with a 4.03 Forbidden response message including an Echo client with a 4.03 Forbidden response message including an Echo
Option, and stores the option value included therein. Option, and stores the option value included therein.
Upon receiving a 4.03 Forbidden response that includes an Echo Option Upon receiving a 4.03 Forbidden response that includes an Echo Option
and originates from a verified group member, a client sends a request and originates from a verified group member, a client sends a request
as a unicast message addressed to the same server, echoing the Echo as a unicast message addressed to the same server, echoing the Echo
Option value. In particular, the client does not necessarily resend Option value. In particular, the client does not necessarily resend
the same group request, but can instead send a more recent one, if the same group request, but can instead send a more recent one, if
the application permits it. This makes it possible for the client to the application permits it. This makes it possible for the client to
not retain previously sent group requests for full retransmission, not retain previously sent group requests for full retransmission,
unless the application explicitly requires otherwise. In either unless the application explicitly requires otherwise. In either
case, the client uses the sequence number value currently stored in case, the client uses the sender sequence number value currently
its own Sender Context. If the client stores group requests for stored in its own Sender Context. If the client stores group
possible retransmission with the Echo Option, it should not store a requests for possible retransmission with the Echo Option, it should
given request for longer than a pre-configured time interval. Note not store a given request for longer than a pre-configured time
that the unicast request echoing the Echo Option is correctly treated interval. Note that the unicast request echoing the Echo Option is
and processed as a group message, since the 'kid context' field correctly treated and processed as a message, since the 'kid context'
including the Group Identifier of the OSCORE group is still present field including the Group Identifier of the OSCORE group is still
in the OSCORE Option as part of the COSE object (see Section 3). present in the OSCORE Option as part of the COSE object (see
Section 3).
Upon receiving the unicast request including the Echo Option, the Upon receiving the unicast request including the Echo Option, the
server verifies that the option value equals the stored and server verifies that the option value equals the stored and
previously sent value; otherwise, the request is silently discarded. previously sent value; otherwise, the request is silently discarded.
Then, the server verifies that the unicast request has been received Then, the server verifies that the unicast request has been received
within a pre-configured time interval, as described in within a pre-configured time interval, as described in
[I-D.ietf-core-echo-request-tag]. In such a case, the request is [I-D.ietf-core-echo-request-tag]. In such a case, the request is
further processed and verified; otherwise, it is silently discarded. further processed and verified; otherwise, it is silently discarded.
Finally, the server updates the Recipient Context associated to that Finally, the server updates the Recipient Context associated to that
client, by setting the Replay Window according to the Sequence Number client, by setting the Replay Window according to the Sequence Number
skipping to change at page 31, line 28 skipping to change at page 28, line 15
In case it does not receive a valid unicast request including the In case it does not receive a valid unicast request including the
Echo Option within the configured time interval, the server endpoint Echo Option within the configured time interval, the server endpoint
should perform the same challenge-response upon receiving the next should perform the same challenge-response upon receiving the next
group request from that same client. group request from that same client.
A server should not deliver group requests from a given client to the A server should not deliver group requests from a given client to the
application until one valid request from that same client has been application until one valid request from that same client has been
verified as fresh, as conveying an echoed Echo Option verified as fresh, as conveying an echoed Echo Option
[I-D.ietf-core-echo-request-tag]. Also, a server may perform the [I-D.ietf-core-echo-request-tag]. Also, a server may perform the
challenge-response described above at any time, if synchronization challenge-response described above at any time, if synchronization
with sequence numbers of clients is (believed to be) lost, for with sender sequence numbers of clients is (believed to be) lost, for
instance after a device reboot. It is the role of the application to instance after a device reboot. It is the role of the application to
define under what circumstances sequence numbers lose define under what circumstances sender sequence numbers lose
synchronization. This can include a minimum gap between the sequence synchronization. This can include a minimum gap between the sender
number of the latest accepted group request from a client and the sequence number of the latest accepted group request from a client
sequence number of a group request just received from the same and the sender sequence number of a group request just received from
client. A client has to be always ready to perform the challenge- the same client. A client has to be always ready to perform the
response based on the Echo Option in case a server starts it. challenge-response based on the Echo Option in case a server starts
it.
Note that endpoints configured as silent servers are not able to Note that endpoints configured as silent servers are not able to
perform the challenge-response described above, as they do not store perform the challenge-response described above, as they do not store
a Sender Context to secure the 4.03 Forbidden response to the client. a Sender Context to secure the 4.03 Forbidden response to the client.
Therefore, silent servers should adopt alternative approaches to Therefore, silent servers should adopt alternative approaches to
achieve and maintain synchronization with sequence numbers of achieve and maintain synchronization with sender sequence numbers of
clients. clients.
This approach provides an assurance of absolute message freshness. This approach provides an assurance of absolute message freshness.
However, it can result in an impact on performance which is However, it can result in an impact on performance which is
undesirable or unbearable, especially in large groups where many undesirable or unbearable, especially in large groups where many
endpoints at the same time might join as new members or lose endpoints at the same time might join as new members or lose
synchronization. synchronization.
Appendix F. No Verification of Signatures Appendix F. No Verification of Signatures
There are some application scenarios using group communication that There are some application scenarios using group communication that
have particularly strict requirements. One example of this is the have particularly strict requirements. One example of this is the
requirement of low message latency in non-emergency lighting requirement of low message latency in non-emergency lighting
applications [I-D.somaraju-ace-multicast]. For those applications applications [I-D.somaraju-ace-multicast]. For those applications
which have tight performance constraints and relaxed security which have tight performance constraints and relaxed security
requirements, it can be inconvenient for some endpoints to verify requirements, it can be inconvenient for some endpoints to verify
digital signatures in order to assert source authenticity of received digital signatures in order to assert source authenticity of received
group messages. In other cases, the signature verification can be messages. In other cases, the signature verification can be deferred
deferred or only checked for specific actions. For instance, a or only checked for specific actions. For instance, a command to
command to turn a bulb on where the bulb is already on does not need turn a bulb on where the bulb is already on does not need the
the signature to be checked. In such situations, the counter signature to be checked. In such situations, the counter signature
signature needs to be included anyway as part of the group message, needs to be included anyway as part of the message, so that an
so that an endpoint that needs to validate the signature for any endpoint that needs to validate the signature for any reason has the
reason has the ability to do so. ability to do so.
In this specification, it is NOT RECOMMENDED that endpoints do not In this specification, it is NOT RECOMMENDED that endpoints do not
verify the counter signature of received group messages. However, it verify the counter signature of received messages. However, it is
is recognized that there may be situations where it is not always recognized that there may be situations where it is not always
required. The consequence of not doing the signature validation is required. The consequence of not doing the signature validation is
that security in the group is based only on the group-authenticity of that security in the group is based only on the group-authenticity of
the shared keying material used for encryption. That is, endpoints the shared keying material used for encryption. That is, endpoints
in the group have evidence that a received message has been in the group have evidence that a received message has been
originated by a group member, although not specifically identifiable originated by a group member, although not specifically identifiable
in a secure way. This can violate a number of security requirements, in a secure way. This can violate a number of security requirements,
as the compromise of any element in the group means that the attacker as the compromise of any element in the group means that the attacker
has the ability to control the entire group. Even worse, the group has the ability to control the entire group. Even worse, the group
may not be limited in scope, and hence the same keying material might may not be limited in scope, and hence the same keying material might
be used not only for light bulbs but for locks as well. Therefore, be used not only for light bulbs but for locks as well. Therefore,
extreme care must be taken in situations where the security extreme care must be taken in situations where the security
requirements are relaxed, so that deployment of the system will requirements are relaxed, so that deployment of the system will
always be done safely. always be done safely.
Appendix G. Document Updates Appendix G. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
G.1. Version -01 to -02 G.1. Version -02 to -03
o Revised structure and phrasing for improved readability and better
alignment with draft-ietf-core-object-security.
o Added discussion on wrap-Around of Partial IVs (see Section 2.2).
o Separate sections for the COSE Object (Section 3) and the OSCORE
Header Compression (Section 4).
o The countersignature is now appended to the encrypted payload of
the OSCORE message, rather than included in the OSCORE Option (see
Section 4).
o Extended scope of Section 5, now titled " Message Binding,
Sequence Numbers, Freshness and Replay Protection".
o Clarifications about Non-Confirmable messages in Section 5.1
"Synchronization of Sender Sequence Numbers".
o Clarifications about error handling in Section 6 "Message
Processing".
o Compacted list of responsibilities of the Group Manager in
Section 7.
o Revised and extended security considerations in Section 8.
o Added IANA considerations for the OSCORE Flag Bits Registry in
Section 9.
o Revised Appendix D, now giving a short high-level description of a
new endpoint set-up.
G.2. Version -01 to -02
o Terminology has been made more aligned with RFC7252 and draft- o Terminology has been made more aligned with RFC7252 and draft-
ietf-core-object-security: i) "client" and "server" replace the ietf-core-object-security: i) "client" and "server" replace the
old "multicaster" and "listener", respectively; ii) "silent old "multicaster" and "listener", respectively; ii) "silent
server" replaces the old "pure listener". server" replaces the old "pure listener".
o Section 2 has been updated to have the Group Identifier stored in o Section 2 has been updated to have the Group Identifier stored in
the 'ID Context' parameter defined in draft-ietf-core-object- the 'ID Context' parameter defined in draft-ietf-core-object-
security. security.
skipping to change at page 33, line 29 skipping to change at page 31, line 5
implications of possible collisions of group identifiers. implications of possible collisions of group identifiers.
o Updated Appendix D.2, adding a pointer to draft-palombini-ace-key- o Updated Appendix D.2, adding a pointer to draft-palombini-ace-key-
groupcomm about retrieval of nodes' public keys through the Group groupcomm about retrieval of nodes' public keys through the Group
Manager. Manager.
o Minor updates to Appendix E.3 about Challenge-Response o Minor updates to Appendix E.3 about Challenge-Response
synchronization of sequence numbers based on the Echo option from synchronization of sequence numbers based on the Echo option from
draft-ietf-core-echo-request-tag. draft-ietf-core-echo-request-tag.
G.2. Version -00 to -01 G.3. Version -00 to -01
o Section 1.1 has been updated with the definition of group as o Section 1.1 has been updated with the definition of group as
"security group". "security group".
o Section 2 has been updated with: o Section 2 has been updated with:
* Clarifications on etablishment/derivation of security contexts. * Clarifications on etablishment/derivation of security contexts.
* A table summarizing the the additional context elements * A table summarizing the the additional context elements
compared to OSCORE. compared to OSCORE.
skipping to change at page 34, line 15 skipping to change at page 31, line 39
o Added Appendix A (former section), including assumptions and o Added Appendix A (former section), including assumptions and
security objectives. security objectives.
o Appendix B has been updated with more details on the use cases. o Appendix B has been updated with more details on the use cases.
o Added Appendix C, providing an example of Group Identifier format. o Added Appendix C, providing an example of Group Identifier format.
o Appendix D has been updated to be aligned with draft-palombini- o Appendix D has been updated to be aligned with draft-palombini-
ace-key-groupcomm. ace-key-groupcomm.
Acknowledgments
The authors sincerely thank Stefan Beck, Rolf Blom, Carsten Bormann,
Esko Dijk, Klaus Hartke, Rikard Hoeglund, Richard Kelsey, John
Mattsson, Jim Schaad, Ludwig Seitz and Peter van der Stok for their
feedback and comments.
The work on this document has been partly supported by the EIT-
Digital High Impact Initiative ACTIVE.
Authors' Addresses Authors' Addresses
Marco Tiloca Marco Tiloca
RISE SICS RISE AB
Isafjordsgatan 22 Isafjordsgatan 22
Kista SE-16440 Stockholm Kista SE-16440 Stockholm
Sweden Sweden
Email: marco.tiloca@ri.se Email: marco.tiloca@ri.se
Goeran Selander Goeran Selander
Ericsson AB Ericsson AB
Torshamnsgatan 23 Torshamnsgatan 23
Kista SE-16440 Stockholm Kista SE-16440 Stockholm
 End of changes. 128 change blocks. 
785 lines changed or deleted 665 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/