draft-ietf-core-oscore-groupcomm-03.txt   draft-ietf-core-oscore-groupcomm-04.txt 
CoRE Working Group M. Tiloca CoRE Working Group M. Tiloca
Internet-Draft RISE AB Internet-Draft RISE AB
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: April 25, 2019 F. Palombini Expires: September 9, 2019 F. Palombini
Ericsson AB Ericsson AB
J. Park J. Park
Universitaet Duisburg-Essen Universitaet Duisburg-Essen
October 22, 2018 March 08, 2019
Group OSCORE - Secure Group Communication for CoAP Group OSCORE - Secure Group Communication for CoAP
draft-ietf-core-oscore-groupcomm-03 draft-ietf-core-oscore-groupcomm-04
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 defines how OSCORE is used in a group communication In particular, it defines how OSCORE is used in a group communication
setting, while fulfilling the same security requirements for group setting, while fulfilling the same security requirements for group
requests and responses. Source authentication of all messages requests and responses. Source authentication of all messages
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 April 25, 2019. This Internet-Draft will expire on September 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 8
2.2. Wrap-Around of Partial IVs . . . . . . . . . . . . . . . 8 2.2. Wrap-Around of Partial IVs . . . . . . . . . . . . . . . 9
3. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 8 3. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 9
4. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 9 3.1. Updated external_aad . . . . . . . . . . . . . . . . . . 9
4.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 9 3.2. Use of the 'kid' Parameter . . . . . . . . . . . . . . . 10
4.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 10 3.3. Updated 'unprotected' Field . . . . . . . . . . . . . . . 10
4.3. Examples of Compressed COSE Objects . . . . . . . . . . . 10 4. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 10
4.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 11
4.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 12
4.3. Examples of Compressed COSE Objects . . . . . . . . . . . 12
5. Message Binding, Sequence Numbers, Freshness and Replay 5. Message Binding, Sequence Numbers, Freshness and Replay
Protection . . . . . . . . . . . . . . . . . . . . . . . . . 11 Protection . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Synchronization of Sender Sequence Numbers . . . . . . . 12 5.1. Synchronization of Sender Sequence Numbers . . . . . . . 13
6. Message Processing . . . . . . . . . . . . . . . . . . . . . 12 6. Message Processing . . . . . . . . . . . . . . . . . . . . . 14
6.1. Protecting the Request . . . . . . . . . . . . . . . . . 13 6.1. Protecting the Request . . . . . . . . . . . . . . . . . 14
6.2. Verifying the Request . . . . . . . . . . . . . . . . . . 13 6.2. Verifying the Request . . . . . . . . . . . . . . . . . . 15
6.3. Protecting the Response . . . . . . . . . . . . . . . . . 13 6.3. Protecting the Response . . . . . . . . . . . . . . . . . 15
6.4. Verifying the Response . . . . . . . . . . . . . . . . . 14 6.4. Verifying the Response . . . . . . . . . . . . . . . . . 16
7. Responsibilities of the Group Manager . . . . . . . . . . . . 14 7. Responsibilities of the Group Manager . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Group-level Security . . . . . . . . . . . . . . . . . . 15 8.1. Group-level Security . . . . . . . . . . . . . . . . . . 18
8.2. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 16 8.2. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 18
8.3. Management of Group Keying Material . . . . . . . . . . . 16 8.3. Management of Group Keying Material . . . . . . . . . . . 19
8.4. Update of Security Context and Key Rotation . . . . . . . 17 8.4. Update of Security Context and Key Rotation . . . . . . . 19
8.5. Collision of Group Identifiers . . . . . . . . . . . . . 17 8.5. Collision of Group Identifiers . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . . 18 9.1. Counter Signature Parameters Registry . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Expert Review Instructions . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Assumptions and Security Objectives . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 23
A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Assumptions and Security Objectives . . . . . . . . 25
A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 21 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 22 A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 26
Appendix C. Example of Group Identifier Format . . . . . . . . . 24 Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 27
Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 25 Appendix C. Example of Group Identifier Format . . . . . . . . . 29
Appendix E. Examples of Synchronization Approaches . . . . . . . 26 Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 30
E.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 26 Appendix E. Examples of Synchronization Approaches . . . . . . . 31
E.2. Baseline Synchronization . . . . . . . . . . . . . . . . 26 E.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 31
E.3. Challenge-Response Synchronization . . . . . . . . . . . 27 E.2. Baseline Synchronization . . . . . . . . . . . . . . . . 31
Appendix F. No Verification of Signatures . . . . . . . . . . . 28 E.3. Challenge-Response Synchronization . . . . . . . . . . . 32
Appendix G. Document Updates . . . . . . . . . . . . . . . . . . 29 Appendix F. No Verification of Signatures . . . . . . . . . . . 33
G.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 29 Appendix G. Document Updates . . . . . . . . . . . . . . . . . . 34
G.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 30 G.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 34
G.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 31 G.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 G.3. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 G.4. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 36
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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, improve performance and reduce bandwidth example to reduce latencies, improve performance and reduce bandwidth
skipping to change at page 4, line 47 skipping to change at page 5, line 5
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
security parameters (Common Context, see Section 2). The term security parameters (Common Context, see Section 2). The term
group used in this specification refers thus to a "security group used in this specification refers thus to a "security
group", not to be confused with network/multicast group or group", not to be confused with network/multicast group or
application group. application group.
o Group Manager (GM): entity responsible for a group. Each endpoint o Group Manager: entity responsible for a group. Each endpoint in a
in a group communicates securely with the respective GM, which is group communicates securely with the respective Group Manager,
neither required to be an actual group member nor to take part in which is neither required to be an actual group member nor to take
the group communication. The full list of responsibilities of the part in the group communication. The full list of
Group Manager is provided in Section 7. responsibilities of the Group Manager is provided in Section 7.
o Silent server: member of a group that never responds to requests. o Silent server: member of a group that never responds to requests.
Note that a silent server can act as a client, the two roles are Note that a silent server can act as a client, the two roles are
independent. independent.
o Group Identifier (Gid): identifier assigned to the group. Group o Group Identifier (Gid): identifier assigned to the group. Group
Identifiers should be unique within the set of groups of a given Identifiers should be unique within the set of groups of a given
Group Manager, in order to avoid collisions. In case they are Group Manager, in order to avoid collisions. In case they are
not, the considerations in Section 8.5 apply. not, the considerations in Section 8.5 apply.
skipping to change at page 5, line 46 skipping to change at page 5, line 52
Section 6). The choice of the Gid is application specific. Section 6). The choice of the Gid is application specific.
An example of specific formatting of the Gid is given in An example of specific formatting of the Gid is given in
Appendix C. The application needs to specify how to handle Appendix C. The application needs to specify how to handle
possible collisions between Gids, see Section 8.5. possible collisions between Gids, see Section 8.5.
* A new parameter Counter Signature Algorithm is included. Its * A new parameter Counter Signature Algorithm is included. Its
value identifies the digital signature algorithm used to value identifies the digital signature algorithm used to
compute a counter signature on the COSE object (see compute a counter signature on the COSE object (see
Section 4.5 of [RFC8152]) which provides source authentication Section 4.5 of [RFC8152]) which provides source authentication
within the group. Its value is immutable once the Common within the group. Its value is immutable once the Common
Context is established. The EdDSA signature algorithm ed25519 Context is established. The used Counter Signature Algorithm
[RFC8032] is mandatory to implement. MUST be selected among the signing ones defined in the COSE
Algorithms Registry (see section 16.4 of [RFC8152]). The
EdDSA signature algorithm ed25519 [RFC8032] is mandatory to
implement. If Elliptic Curve Digital Signature Algorithm
(ECDSA) is used, it is RECOMMENDED that implementations
implement "deterministic ECDSA" as specified in [RFC6979].
* A new parameter Counter Signature Parameters is included.
This parameter identifies the parameters associated to the
digital signature algorithm specified in the Counter Signature
Algorithm. This parameter MAY be empty and is immutable once
the Common Context is established. The exact structure of
this parameter depends on the value of Counter Signature
Algorithm, and is defined in the Counter Signature Parameters
Registry (see Section 9.1), where each entry indicates a
specified structure of the Counter Signature Parameters.
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
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. The Sender Context of a given endpoint matches the group. The Sender Context of a given endpoint matches the
corresponding Recipient Context in all the endpoints receiving a corresponding Recipient Context in all the endpoints receiving a
protected message from that endpoint. Besides, in addition to protected message from that endpoint. Besides, in addition to
what is defined in [I-D.ietf-core-object-security], the Sender what is defined in [I-D.ietf-core-object-security], the Sender
Context stores also the endpoint's private key. Context stores also the endpoint's private key.
skipping to change at page 6, line 25 skipping to change at page 7, line 5
matches the Sender Context of the endpoint from which protected matches the Sender Context of the endpoint from which protected
messages are received. Besides, in addition to what is defined messages are received. Besides, in addition to what is defined
in [I-D.ietf-core-object-security], each Recipient Context stores 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
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 | | Common Context | Counter signature parameters |
| | | | | |
| Each Recipient Context | Public key of the | | Sender Context | Endpoint's own private key |
| | associated other endpoint | | | |
| | | | Each Recipient Context | Public key of the |
+---------------------------+-----------------------------+ | | 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 uses the sender's Upon receiving a secure CoAP message, a recipient uses the sender's
public key, in order to verify the counter signature of the COSE public key, in order to verify the counter signature of the COSE
Object (see Section 3). 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, the recipient retrieves the public key from the Group sender, the recipient retrieves the sender's public key from the
Manager, which collects public keys upon endpoints' joining, acts as Group Manager, which collects public keys upon endpoints' joining the
trusted key repository and ensures the correct association between group, acts as trusted key repository and ensures the correct
the public key and the identifier of the sender, for instance by association between the public key and the identifier of the sender,
means of public key certificates. for instance by means of public key certificates.
Note that a group member can retrieve public keys from the Group
Manager and generate the Recipient Context associated to another
group member at any point in time, as long as this is done before
verifying a received secure CoAP message. The exact configuration is
application dependent. For example, an application can configure a
group member to retrieve all the required information and to create
the Recipient Context exactly upon receiving a message from another
group member for the first time. As an alternative, the application
can configure a group member to asynchronously retrieve the required
information and update its list of Recipient Contexts well before
receiving any message, e.g. by Observing [RFC7641] the Group Manager
to get updates on the group membership.
It is RECOMMENDED that the Group Manager collects public keys and It is RECOMMENDED that the Group Manager collects public keys and
provides them to group members upon request as described in provides them to group members upon request as described in
[I-D.tiloca-ace-oscoap-joining], where the join process is based on [I-D.ietf-ace-key-groupcomm-oscore], where the join process is based
the ACE framework for Authentication and Authorization in constrained on the ACE framework for Authentication and Authorization in
environments [I-D.ietf-ace-oauth-authz]. Further details about how constrained environments [I-D.ietf-ace-oauth-authz]. Further details
public keys can be handled and retrieved in the group is out of the about how public keys can be handled and retrieved in the group is
scope of this document. out of the scope of this document.
An endpoint receives its own Sender ID from the Group Manager upon An endpoint receives its own Sender ID from the Group Manager upon
joining the group. That Sender ID is valid only within that group, 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 and is unique within the group. An endpoint uses its own Sender ID
(together with other data) to generate unique AEAD nonces for (together with other data) to generate unique AEAD nonces for
outgoing messages, as in [I-D.ietf-core-object-security]. Endpoints outgoing messages, as in [I-D.ietf-core-object-security]. Endpoints
which are configured only as silent servers do not have a Sender ID. 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 Sender/Recipient Keys and the Common IV are derived according to
the same scheme defined in Sections 3.2 and 5.2 of the same scheme defined in Section 3.2 of
[I-D.ietf-core-object-security]. The mandatory-to-implement HKDF and [I-D.ietf-core-object-security]. The mandatory-to-implement HKDF and
AEAD algorithms for Group OSCORE are the same as in 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
In order to establish a new Security Context in a group, a new Group In order to establish a new Security Context in a group, a new Group
Identifier (Gid) for that group and a new value for the Master Secret Identifier (Gid) for that group and a new value for the Master Secret
parameter MUST be distributed. An example of Gid format supporting parameter MUST be distributed. An example of Gid format supporting
this operation is provided in Appendix C. Then, each group member this operation is provided in Appendix C. Then, each group member
re-derives the keying material stored in its own Sender Context and re-derives the keying material stored in its own Sender Context and
Recipient Contexts as described in Section 2, using the updated Gid. Recipient Contexts as described in Section 2, using the updated Gid.
Consistently with the security assumptions in Appendix A.1, it is After a new Gid has been distributed, a same Recipient ID ('kid')
RECOMMENDED to adopt a group key management scheme, and securely should not be considered as a persistent and reliable indicator of
distribute a new value for the Gid and for the Master Secret the same group member. Such an indication can be actually achieved
parameter of the group's Security Context, before a new joining only by verifying countersignatures of received messages.
endpoint is added to the group or after a currently present endpoint
leaves the group. This is necessary to preserve backward security As a consequence, group members may end up retaining stale Recipient
and forward security in the group, if the application requires it. Contexts, that are no longer useful to verify incoming secure
messages. Applications may define policies to delete (long-)unused
Recipient Contexts and reduce the impact on storage space.
If the application requires so (see Appendix A.1), it is RECOMMENDED
to adopt a group key management scheme, and securely distribute a new
value for the Gid and for the Master Secret parameter of the group's
Security Context, before a new joining endpoint is added to the group
or after a currently present endpoint leaves the group. This is
necessary to preserve backward security and forward security in the
group, if the application requires it.
The specific approach used to distribute the new Gid and Master The specific approach used to distribute the new Gid and Master
Secret parameter to the group is out of the scope of this document. Secret parameter to the group is out of the scope of this document.
However, it is RECOMMENDED that the Group Manager supports the However, it is RECOMMENDED that the Group Manager supports the
distribution of the new Gid and Master Secret parameter to the group distribution of the new Gid and Master Secret parameter to the group
according to the Group Rekeying Process described in according to the Group Rekeying Process described in
[I-D.tiloca-ace-oscoap-joining]. [I-D.ietf-ace-key-groupcomm-oscore].
2.2. Wrap-Around of Partial IVs 2.2. Wrap-Around of Partial IVs
A client can eventually experience a wrap-around of its own Sender A client can eventually experience a wrap-around of its own Sender
Sequence Number, which is used as Partial IV in outgoing requests and Sequence Number, which is used as Partial IV in outgoing requests and
incremented after each request. When this happens, the OSCORE incremented after each request.
Security Context MUST be renewed in the group, in order to avoid
When this happens, the endpoint MUST NOT transmit further group
requests until it has derived a new Sender Context, in order to avoid
reusing nonces with the same keys. reusing nonces with the same keys.
Therefore, when experiencing a wrap-around of its own Sender Sequence Furthermore, the endpoint SHOULD inform the Group Manager, that can
Number, a group member MUST NOT transmit further group requests until take one of the following actions:
a new OSCORE Security Context has been derived. In particular, the
endpoint SHOULD inform the Group Manager of the occurred wrap-around, o The Group Manager renews the OSCORE Security Context in the group
in order to trigger a prompt renewal of the OSCORE Security Context. (see Section 2.1).
o The Group Manager provides a new Sender ID value to the endpoint
that has experienced the wrap-around. Then, the endpoint derives
a new Sender Context using the new Sender ID, as described in
Section 3.2 of [I-D.ietf-core-object-security].
Either case, same considerations from Section 2.1 hold about possible
retaining of stale Recipient Contexts.
3. The COSE Object 3. The COSE Object
Building on Section 5 of [I-D.ietf-core-object-security], this Building on Section 5 of [I-D.ietf-core-object-security], this
section defines how to use COSE [RFC8152] to wrap and protect data in section defines how to use COSE [RFC8152] to wrap and protect data in
the original message. OSCORE uses the untagged COSE_Encrypt0 the original message. OSCORE uses the untagged COSE_Encrypt0
structure with an Authenticated Encryption with Additional Data structure with an Authenticated Encryption with Additional Data
(AEAD) algorithm. For Group OSCORE, the following modifications (AEAD) algorithm. For Group OSCORE, the following modifications
apply: apply.
o The external_aad in the Additional Authenticated Data (AAD) is 3.1. Updated external_aad
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 The external_aad in the Additional Authenticated Data (AAD) is
extended with the counter signature algorithm and related parameters
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:
aad_array = [ o 'alg_countersign', which contains the Counter Signature Algorithm
oscore_version : uint, from the Common Context (see Section 2). This parameter has the
algorithms : [alg_aead : int / tstr , alg_countersign : int / tstr], value specified in the "Value" field of the Counter Signature
request_kid : bstr, Parameters Registry (see Section 9.1) for this counter signature
request_piv : bstr, algorithm.
options : bstr
]
o The value of the 'kid' parameter in the 'unprotected' field of The 'algorithms' array in the aad_array MAY also include:
response messages MUST be set to the Sender ID of the endpoint
transmitting the message. That is, unlike in
[I-D.ietf-core-object-security], the 'kid' parameter is always o 'par_countersign', which contains the Counter Signature Parameters
present in all messages, i.e. both requests and responses. from the Common Context (see Section 2). This parameter contains
the counter signature parameters encoded as specified in the
"Parameters" field of the Counter Signature Parameters Registry
(see Section 9.1), for the used counter signature algorithm. Note
that if the Counter Signature Parameters in the Common Context is
empty, 'par_countersign' is not present.
o The 'unprotected' field MUST additionally include the following This external_aad structure is used both for the encryption process
parameter: producing the ciphertext (see Section 5.3 of [RFC8152]) and for the
signing process producing the counter signature, as defined below.
* CounterSignature0 : its value is set to the counter signature external_aad = bstr .cbor aad_array
of the COSE object, computed by the sender using its own
private key as described in Appendix A.2 of [RFC8152]. In aad_array = [
particular, the Sig_structure contains the external_aad as oscore_version : uint,
defined above and the ciphertext of the COSE_Encrypt0 object as algorithms : [alg_aead : int / tstr ,
payload. alg_countersign : int / tstr ,
? par_countersign : any],
request_kid : bstr,
request_piv : bstr,
options : bstr
]
3.2. Use of the 'kid' Parameter
The value of the 'kid' parameter in the 'unprotected' field of
response messages MUST be set to the Sender ID of the endpoint
transmitting the message. That is, unlike in
[I-D.ietf-core-object-security], the 'kid' parameter is always
present in all messages, i.e. both requests and responses.
3.3. Updated 'unprotected' Field
The 'unprotected' field MUST additionally include the following
parameter:
o CounterSignature0 : its value is set to the counter signature of
the COSE object, computed by the sender using its own private key
as described in Appendix A.2 of [RFC8152]. In particular, the
Sig_structure contains the external_aad as defined above and the
ciphertext of the COSE_Encrypt0 object as payload.
4. OSCORE Header Compression 4. OSCORE Header Compression
The OSCORE compression defined in Section 6 of The OSCORE compression defined in Section 6 of
[I-D.ietf-core-object-security] is used, with the following additions [I-D.ietf-core-object-security] is used, with the following additions
for the encoding of the OSCORE Option and the OSCORE Payload. for the encoding of the OSCORE Option and the OSCORE Payload.
4.1. Encoding of the OSCORE Option Value 4.1. Encoding of the OSCORE Option Value
Analogously to [I-D.ietf-core-object-security], the value of the Analogously to [I-D.ietf-core-object-security], the value of the
skipping to change at page 9, line 46 skipping to change at page 11, line 27
all group requests and responses. That is, unlike in all group requests and responses. That is, unlike in
[I-D.ietf-core-object-security], the 'kid' parameter is always [I-D.ietf-core-object-security], the 'kid' parameter is always
present in all messages. present in all messages.
* The fifth least significant bit MUST be set to 1 for group * The fifth least significant bit MUST be set to 1 for group
requests, to indicate the presence of the 'kid context' requests, to indicate the presence of the 'kid context'
parameter in the compressed COSE object. The 'kid context' MAY parameter in the compressed COSE object. The 'kid context' MAY
be present in responses if the application requires it. In be present in responses if the application requires it. In
such a case, the kid context flag MUST be set to 1. 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.
In order to ensure source authentication of messages as
described in this specification, this bit MUST be set to 1.
The flag bits are registered in the OSCORE Flag Bits registry The flag bits are registered in the OSCORE Flag Bits registry
specified in Section 13.7 of [I-D.ietf-core-object-security] and in specified in Section 13.7 of [I-D.ietf-core-object-security].
Section 9.1 of this Specification.
o The 'kid context' value encodes the Group Identifier value (Gid) o The 'kid context' value encodes the Group Identifier value (Gid)
of the group's Security Context. of the group's Security Context.
o The remaining bytes in the OSCORE Option value encode the value of o The remaining bytes in the OSCORE Option value encode the value 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 ------------> 0 1 2 3 4 5 6 7 <------------ n bytes ------------>
+-+-+-+-+-+-+-+-+----------------------------------+ +-+-+-+-+-+-+-+-+-----------------------------------+
|0 0|1|h|1| n | Partial IV (if any) | |0 0|0|h|1| n | Partial IV (if any) |
+-+-+-+-+-+-+-+-+----------------------------------+ +-+-+-+-+-+-+-+-+-----------------------------------+
<-- 1 byte --> <------ s bytes ------> <-- 1 byte ---> <------ s bytes ------>
+--------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
| s (if any) | kid context = Gid | kid | | s (if any) | kid context = Gid | kid |
+--------------+-----------------------+-----------+ +---------------+-----------------------+-----------+
Figure 2: OSCORE Option Value Figure 2: OSCORE Option Value
4.2. Encoding of the OSCORE Payload 4.2. Encoding of the OSCORE Payload
The payload of the OSCORE message SHALL encode the ciphertext of the The payload of the OSCORE message SHALL encode the ciphertext of the
COSE object concatenated with the value of the CounterSignature0 (if COSE object concatenated with the value of the CounterSignature0 of
present) of the COSE object, computed as in Appendix A.2 of the COSE object, computed as in Appendix A.2 of [RFC8152] according
[RFC8152]. to the Counter Signature Algorithm and Counter Signature Parameters
in the Security Context.
4.3. Examples of Compressed COSE Objects 4.3. Examples of Compressed COSE Objects
This section covers a list of OSCORE Header Compression examples for This section covers a list of OSCORE Header Compression examples for
group requests and responses. The examples assume that the group requests and responses. The examples assume that the
COSE_Encrypt0 object is set (which means the CoAP message and COSE_Encrypt0 object is set (which means the CoAP message and
cryptographic material is known). Note that the examples do not cryptographic material is known). Note that the examples do not
include the full CoAP unprotected message or the full security include the full CoAP unprotected message or the full security
context, but only the input necessary to the compression mechanism, context, but only the input necessary to the compression mechanism,
i.e. the COSE_Encrypt0 object. The output is the compressed COSE i.e. the COSE_Encrypt0 object. The output is the compressed COSE
skipping to change at page 11, line 18 skipping to change at page 12, line 43
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: 0b00011001 = 0x19
Option Value: 39 05 03 44 61 6c 25 (7 bytes) Option Value: 19 05 03 44 61 6c 25 (7 bytes)
Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 COUNTERSIGN Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 COUNTERSIGN
(14 bytes + size of COUNTERSIGN) (14 bytes + size of COUNTERSIGN)
1. Response with ciphertext = 60b035059d9ef5667c5a0710823b, kid = 1. Response with ciphertext = 60b035059d9ef5667c5a0710823b, kid =
0x52 and no Partial IV. 0x52 and no Partial IV.
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: 0b00001000 = 0x08
Option Value: 28 52 (2 bytes) Option Value: 08 52 (2 bytes)
Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b COUNTERSIGN Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b COUNTERSIGN
(14 bytes + size of COUNTERSIGN) (14 bytes + size of COUNTERSIGN)
5. Message Binding, Sequence Numbers, Freshness and Replay Protection 5. Message Binding, Sequence Numbers, Freshness and Replay Protection
The requirements and properties described in Section 7 of The requirements and properties described in Section 7 of
[I-D.ietf-core-object-security] also apply to OSCORE used in group [I-D.ietf-core-object-security] also apply to OSCORE used in group
communication. In particular, group OSCORE provides message binding communication. In particular, group OSCORE provides message binding
of responses to requests, which provides relative freshness of of responses to requests, which provides relative freshness of
responses, and replay protection of requests. More details about responses, and replay protection of requests.
error processing for replay detection in group OSCORE are specified
in Section 6 of this specification. The mechanisms describing replay Besides, group OSCORE provides additional assurances on the client
protection and freshness of Observe notifications do not apply to side, upon receiving responses bound to a same request. That is, as
group OSCORE, as Observe is not defined for group settings. long as the client retains the CoAP Token used in a request (see
Section 2.5 of [RFC7390]), group OSCORE ensures that: any possible
response sent to that request is not a replay; and at most one
response to that request from a given server is accepted, if required
by the application.
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 5.1. Synchronization of Sender Sequence Numbers
Upon joining the group, new servers are not aware of the Sender Upon joining the group, new servers are not aware of the Sender
Sequence Number values currently used by different clients to Sequence Number values currently used by different clients to
transmit group requests. This means that, when such servers receive transmit group requests. This means that, when such servers receive
a secure group request from a given client for the first time, they 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 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 replayed or (purposely) delayed. The same holds when a server loses
synchronization with Sender Sequence Numbers of clients, for instance synchronization with Sender Sequence Numbers of clients, for instance
after a device reboot. after a device reboot.
The exact way to address this issue is application specific, and The exact way to address this issue is application specific, and
depends on the particular use case and its synchronization depends on the particular use case and its synchronization
requirements. The list of methods to handle synchronization of requirements. The list of methods to handle synchronization of
Sender Sequence Numbers is part of the group communication policy, Sender Sequence Numbers is part of the group communication policy,
and different servers can use different methods. 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 Appendix E describes three possible approaches that can be considered
for synchronization of sequence numbers. for synchronization of sequence numbers.
6. Message Processing 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.
message ordering.
As per [RFC7252][RFC7390], group requests sent over multicast MUST be
Non-Confirmable. Thus, senders should store their outgoing messages
for an amount of time defined by the application and sufficient to
correctly handle possible retransmissions. However, this does not
prevent the acknowledgment of Confirmable group requests in non-
multicast environments. Besides, according to Section 5.2.3 of
[RFC7252], responses to Non-Confirmable group requests SHOULD be also
Non-Confirmable. However, endpoints MUST be prepared to receive
Confirmable responses in reply to a Non-Confirmable group request.
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 recipient adopted in [I-D.ietf-core-object-security]. However, a recipient
MUST stop processing and silently reject any message which is MUST stop processing and silently reject any message which is
malformed and does not follow the format specified in Section 3, or malformed and does not follow the format specified in Section 3, or
which is not cryptographically validated in a successful way. Either which is not cryptographically validated in a successful way. Either
case, the recipient MUST NOT send back any error message. This case, it is RECOMMENDED that the recipient does not send back any
prevents servers from replying with multiple error messages to a error message. This prevents servers from replying with multiple
client sending a group request, so avoiding the risk of flooding and error messages to a client sending a group request, so avoiding the
possibly congesting the group. risk of flooding and possibly congesting the group.
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 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 encryption of the COSE object is modified as o In step 4, the encryption of the COSE object is modified as
described in Section 3. The encoding of the compressed COSE described in Section 3. The encoding of the compressed COSE
object is modified as described in Section 4. object is modified as described in Section 4.
o In step 5, the counter signature is computed and the format of the
OSCORE mesage is modified as described in Section 4.2. In
particular, the payload of the OSCORE message includes also the
counter signature.
6.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 follows o In step 2, the decoding of the compressed COSE object follows
Section 4. If the received Recipient ID ('kid') does not match Section 4. If the received Recipient ID ('kid') does not match
with any Recipient Context for the retrieved Gid ('kid context'), with any Recipient Context for the retrieved Gid ('kid context'),
then the server creates a new Recipient Context, initializes it then the server creates a new Recipient Context, initializes it
according to Section 3 of [I-D.ietf-core-object-security], also according to Section 3 of [I-D.ietf-core-object-security], also
retrieving the client's public key. retrieving the client's public 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.
o Additionally, if the used Recipient Context was created upon
receiving this group request and the message is not verified
successfully, the server MAY delete that Recipient Context. Such
a configuration, which is specified by the application, would
prevent attackers from overloading the server's storage and
creating processing overhead on the server.
6.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 encryption of the COSE object is modified as o In step 4, the encryption of the COSE object is modified as
described in Section 3. The encoding of the compressed COSE described in Section 3. The encoding of the compressed COSE
object is modified as described in Section 4. object is modified as described in Section 4.
o In step 5, the counter signature is computed and the format of the
OSCORE mesage is modified as described in Section 4.2. In
particular, the payload of the OSCORE message includes also the
counter signature.
6.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. The client also checks whether it
does not match with any Recipient Context for the retrieved Gid previously received a secure response to this request, such that
('kid context'), then the client creates a new Recipient Context, it was successfully verified and included the same Recipient ID
initializes it according to Section 3 of ('kid') of the just received response. In case of positive match
the client SHALL stop processing the response. If the received
Recipient ID ('kid') does not match with any Recipient Context for
the retrieved Gid ('kid context'), then the client creates a new
Recipient Context, initializes it according to Section 3 of
[I-D.ietf-core-object-security], also retrieving the server's [I-D.ietf-core-object-security], also retrieving the server's
public 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. In case of success, the client also records the received
Recipient ID ('kid') as included in a successfully verified
response to the request.
o Additionally, if the used Recipient Context was created upon
receiving this response and the message is not verified
successfully, the client MAY delete that Recipient Context. Such
a configuration, which is specified by the application, would
prevent attackers from overloading the client's storage and
creating processing overhead on the client.
Upon freeing up the Token value of a secure group request for
possible reuse [RFC7390], the client MUST delete the list of recorded
Recipient IDs associated to that request (see step 5 above).
7. Responsibilities of the Group Manager 7. 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:
1. Creating and managing OSCORE groups. This includes the 1. Creating and managing OSCORE groups. This includes the
assignment of a Gid to every newly created group, as well as assignment of a Gid to every newly created group, as well as
ensuring uniqueness of Gids within the set of its OSCORE groups. ensuring uniqueness of Gids within the set of its OSCORE groups.
2. Defining policies for authorizing the joining of its OSCORE 2. Defining policies for authorizing the joining of its OSCORE
skipping to change at page 18, line 7 skipping to change at page 20, line 33
given Group Manager. However, this does not impair the security of given Group Manager. However, this does not impair the security of
the AEAD algorithm. 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, AEAD keys are different among IDs within a group are unique, AEAD keys are different among
different groups. different groups.
9. IANA Considerations 9. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "[[this Note to RFC Editor: Please replace all occurrences of "[This
document]]" with the RFC number of this specification. Document]" with the RFC number of this specification and delete this
paragraph.
9.1. OSCORE Flag Bits Registry This document has the following actions for IANA.
The entry with Bit Position TBD is added to the "OSCORE Flag Bits" 9.1. Counter Signature Parameters Registry
registry.
+--------------+-------------+---------------------+-------------------+ This specification establishes the IANA "Counter Signature
| Bit Position | Name | Description | Specification | Parameters" Registry. The Registry has been created to use the
+--------------+-------------+---------------------+-------------------+ "Expert Review Required" registration procedure [RFC8126]. Expert
| TBD | Counter | Set to 1 if counter | [[this document]] | review guidelines are provided in Section 9.2.
| | Signature | signature present | |
| | | in the compressed | | The columns of this table are:
| | | COSE object | |
+--------------+-------------+---------------------+-------------------+ o Name: A value that can be used to identify an algorithm in
documents for easier comprehension. Its value is taken from the
'Name' column of the "COSE Algorithms" Registry.
o Value: The value to be used to identify this algorithm. Its
content is taken from the 'Value' column of the "COSE Algorithms"
Registry. The value MUST be the same one used in the "COSE
Algorithms" Registry for the entry with the same 'Name' field.
o Parameters: This indicates the CBOR encoding of the parameters (if
any) for the counter signature algorithm indicated by the 'Value'
field.
o Description: A short description of the parameters encoded in the
'Parameters' field (if any).
o Reference: This contains a pointer to the public specification for
the field, if one exists.
Initial entries in the registry are as follows.
+-------------+-------+-------------+-----------------+-----------+
| Name | Value | Parameters | Description | Reference |
+-------------+-------+-------------+-----------------+-----------+
| | | | | |
| EdDSA | -8 | crv : int | crv value taken | [This |
| | | | from the COSE | Document] |
| | | | Elliptic Curve | |
| | | | Registry | |
| | | | | |
+-------------+-------+-------------+-----------------+-----------+
| | | | | |
| ES256 | -7 | crv : int | crv value taken | [This |
| | | | from the COSE | Document] |
| | | | Elliptic Curve | |
| | | | Registry | |
| | | | | |
+-------------+-------+-------------+-----------------+-----------+
| | | | | |
| ES384 | -35 | crv : int | crv value taken | [This |
| | | | from the COSE | Document] |
| | | | Elliptic Curve | |
| | | | Registry | |
| | | | | |
+-------------+-------+-------------+-----------------+-----------+
| | | | | |
| ES512 | -36 | crv : int | crv value taken | [This |
| | | | from the COSE | Document] |
| | | | Elliptic Curve | |
| | | | Registry | |
| | | | | |
+-------------+-------+-------------+-----------------+-----------+
| | | | | |
| PS256 | -37 | | Parameters not | [This |
| | | | present | Document] |
| | | | | |
+-------------+-------+-------------+-----------------+-----------+
| | | | | |
| PS384 | -38 | | Parameters not | [This |
| | | | present | Document] |
| | | | | |
+-------------+-------+-------------+-----------------+-----------+
| | | | | |
| PS512 | -39 | | Parameters not | [This |
| | | | present | Document] |
| | | | | |
+-------------+-------+-------------+-----------------+-----------+
| | | | | |
| RSAES-OAEP | -40 | | Parameters not | [This |
| w/ RFC 8017 | | | present | Document] |
| default | | | | |
| parameters | | | | |
| | | | | |
+-------------+-------+-------------+-----------------+-----------+
| | | | | |
| RSAES-OAEP | -41 | | Parameters not | [This |
| w/ SHA-256 | | | present | Document] |
| | | | | |
+-------------+-------+-------------+-----------------+-----------+
| | | | | |
| RSAES-OAEP | -42 | | Parameters not | [This |
| w/ SHA-512 | | | present | Document] |
| | | | | |
+-------------+-------+-------------+-----------------+-----------+
9.2. Expert Review Instructions
The IANA Registry established in this document is defined as expert
review. This section gives some general guidelines for what the
experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points:
TBD
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-15 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), August 2018. progress), March 2019.
[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>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
[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>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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-key-groupcomm-oscore]
Tiloca, M., Park, J., and F. Palombini, "Key Management
for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-
oscore-00 (work in progress), December 2018.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22
(work in progress), October 2018. (work in progress), March 2019.
[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-02 (work in Request-Tag", draft-ietf-core-echo-request-tag-03 (work in
progress), June 2018. progress), October 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]
Tiloca, M., Park, J., and F. Palombini, "Key Management
for OSCORE Groups in ACE", draft-tiloca-ace-oscoap-
joining-05 (work in progress), October 2018.
[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
skipping to change at page 20, line 15 skipping to change at page 25, line 10
[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>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
Appendix A. Assumptions and Security Objectives Appendix A. Assumptions and Security Objectives
This section presents a set of assumptions and security objectives This section presents a set of assumptions and security objectives
for the approach described in this document. for the approach described in this document.
A.1. Assumptions A.1. Assumptions
The following assumptions are assumed to be already addressed and are The following assumptions are assumed to be already addressed and are
out of the scope of this document. out of the scope of this document.
skipping to change at page 26, line 16 skipping to change at page 31, line 16
In case of successful authorization check, the Group Manager In case of successful authorization check, the Group Manager
generates a Sender 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. That is, the Group proceeding with the rest of the join process. That is, the Group
Manager provides the joining endpoint with the keying material and Manager provides the joining endpoint with the keying material and
parameters to initialize the OSCORE Security Context (see Section 2). parameters to initialize the OSCORE Security Context (see Section 2).
The actual provisioning of keying material and parameters to the The actual provisioning of keying material and parameters to the
joining endpoint is out of the scope of this document. joining endpoint is out of the scope of this document.
It is RECOMMENDED that the join process adopts the approach described It is RECOMMENDED that the join process adopts the approach described
in [I-D.tiloca-ace-oscoap-joining] and based on the ACE framework for in [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework
Authentication and Authorization in constrained environments for Authentication and Authorization in constrained environments
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
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 sender sequence considered by server endpoints to synchronize with sender sequence
numbers of client endpoints sending group requests. numbers of client endpoints sending group requests.
E.1. Best-Effort Synchronization E.1. Best-Effort Synchronization
skipping to change at page 29, line 28 skipping to change at page 34, line 28
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 -02 to -03 G.1. Version -03 to -04
o Added the new "Counter Signature Parameters" in the Security
Common Context (see Section 2).
o Added recommendation on using "deterministic ECDSA" if ECDSA is
used as counter signature algorithm (see Section 2).
o Clarified possible asynchronous retrieval of key material from the
Group Manager, in order to process incoming messages (see
Section 2).
o Structured Section 3 into subsections.
o Added the new 'par_countersign' to the aad_array of the
external_aad (see Section 3.1).
o Clarified non reliability of 'kid' as identity indicator for a
group member (see Section 2.1).
o Described possible provisioning of new Sender ID in case of
Partial IV wrap-around (see Section 2.2).
o The former signature bit in the Flag Byte of the OSCORE option
value is reverted to reserved (see Section 4.1).
o Updated examples of compressed COSE object, now with the sixth
less significant bit in the Flag Byte of the OSCORE option value
set to 0 (see Section 4.3).
o Relaxed statements on sending error messages (see Section 6).
o Added explicit step on computing the counter signature for
outgoing messages (see Setions 6.1 and 6.3).
o Handling of just created Recipient Contexts in case of
unsuccessful message verification (see Sections 6.2 and 6.4).
o Handling of replied/repeated responses on the client (see
Section 6.4).
o New IANA Registry "Counter Signature Parameters" (see
Section 9.1).
G.2. Version -02 to -03
o Revised structure and phrasing for improved readability and better o Revised structure and phrasing for improved readability and better
alignment with draft-ietf-core-object-security. alignment with draft-ietf-core-object-security.
o Added discussion on wrap-Around of Partial IVs (see Section 2.2). 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 o Separate sections for the COSE Object (Section 3) and the OSCORE
Header Compression (Section 4). Header Compression (Section 4).
o The countersignature is now appended to the encrypted payload of o The countersignature is now appended to the encrypted payload of
skipping to change at page 30, line 16 skipping to change at page 36, line 11
Section 7. Section 7.
o Revised and extended security considerations in Section 8. o Revised and extended security considerations in Section 8.
o Added IANA considerations for the OSCORE Flag Bits Registry in o Added IANA considerations for the OSCORE Flag Bits Registry in
Section 9. Section 9.
o Revised Appendix D, now giving a short high-level description of a o Revised Appendix D, now giving a short high-level description of a
new endpoint set-up. new endpoint set-up.
G.2. Version -01 to -02 G.3. 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 31, line 5 skipping to change at page 36, line 46
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.3. Version -00 to -01 G.4. 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 31, line 46 skipping to change at page 37, line 39
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 Acknowledgments
The authors sincerely thank Stefan Beck, Rolf Blom, Carsten Bormann, The authors sincerely thank Stefan Beck, Rolf Blom, Carsten Bormann,
Esko Dijk, Klaus Hartke, Rikard Hoeglund, Richard Kelsey, John Esko Dijk, Klaus Hartke, Rikard Hoeglund, Richard Kelsey, John
Mattsson, Jim Schaad, Ludwig Seitz and Peter van der Stok for their Mattsson, Jim Schaad, Ludwig Seitz and Peter van der Stok for their
feedback and comments. feedback and comments.
The work on this document has been partly supported by the EIT- The work on this document has been partly supported by VINNOVA and
Digital High Impact Initiative ACTIVE. the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact
Initiative ACTIVE.
Authors' Addresses Authors' Addresses
Marco Tiloca Marco Tiloca
RISE AB RISE AB
Isafjordsgatan 22 Isafjordsgatan 22
Kista SE-16440 Stockholm Kista SE-16440 Stockholm
Sweden Sweden
Email: marco.tiloca@ri.se Email: marco.tiloca@ri.se
 End of changes. 60 change blocks. 
204 lines changed or deleted 472 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/